30 апреля 2012 в 2:31
Обнаружил интересный нюанс при использовании стандартного кеширования Друпал 6.25. Страница
alma.kiev.ua/товары/короба-пластиковые/короба-по-сечениям (не кешируется)
alma.kiev.ua/товары/крепеж-монтажный/стяжки-кабельные (кешируется)
Этот феномен наблюдается и на других страницах сайта.
Предположительно проблема в длине ссылки на отображаемую страницу.
Если кто сталкивался с этим нюансом или знает в чем проблема, прошу отозваться.
Вынес решение в начало:
1. Заходим в phpMyAdmin, находим нашу базу данных и заходим в нее
2. Находим таблицу cache_page и заходим в ее структуру (кнопка "структура" в этой же строке)
3. Находим поле cid и жмем на кнопку "изменить"
4. В настройке "Сравнение" выбираем тип cp1250_general_ci или acsii_general_ci
5. В настройках "Длина/значения" ставим 1000 или меньше, больше не получится
6. Ничего больше не меняем.
Комментарии
Могу добавить, что не работа кеширования страниц с кирилицей четко связано с ограничение длины запроса
256 символами (недостаток метода GET насколько я понимаю?)в не зависимости от того на каком языке урл. Просто урл кирилицейalma.kiev.ua/товары/короба-пластиковые/короба-по-сечениям
на самом деле выглядит так
http://alma.kiev.ua/%D1%82%D0%BE%D0%B2%D0%B0%D1%80%D1%8B/%D0%BA%D0%BE%D1...
Поэтому при превышении количества символов (включая http://) числа
256стандартное кеширование Друпала перестает работать (сам проверил). Оченьнеприятная недоработка(скорее отсутствие информации о возможных нюансах) и это не связана с кирилицей. Возможно, кто нибудь знает, как это преодолеть?P.S.
1. В процессе нижеследующего разбирательства, ограничение на длину запроса перешло в ограничение на размер поля cid типа varchar в 255 символов utf8 таблицы cache_page.
2. Исходя из вышеизложенного, это скорее всего не есть неприятная недоработка системы стандартного кеширования Друпал, а недостаток связанной с этой проблемой информации по форматированию полей таблиц базы MySQL.
3. Если кому интересно решение этой проблемы - смотрите в конец блога - есть результаты.
А если использовать не коробочное кеширование? boost к примеру?
Мне кажется, что boost не работает с килилицей. Я нашел давнее сообщение, что dev версия точно не поддерживает кирилицу в урлах. Я установил последнюю версию boost 6.x-1.18 и мне не удалось заставить его кешировать страницы с кирилицей в урлах. Кешировалась только главная alma.kiev.ua.
Пробовал модули authcache и pathauto вместе и по отдельности - не работают. И меня вполне бы устраивало стандартное кеширование, если бы не этот баг. Можно конечно переделать построение пути, чтобы кирилицы стало меньше, но страниц много и не хочется терять индексирование.
Кроме того, это может коснуться и страниц с традиционными урлами, если их длина превысит 256 символов. Неужели никто до сих пор с этим не сталкивался? Уважаемое сообщество, нужна помощь, отзовитесь.
Про максимальную длину имени файла слышали?
Ограничение в 256 символов присутствует в методе GET при выводе форм. Вы это имели ввиду?
У вас буйное воображение, я про формы ни слова не сказал.
Я всего лишь имел ввиду ограничение на длину имени файла в популярных файловых системах.
А максимальная длина GET-запроса полностью зависит от ПО, которое занимается обработкой данного запроса. Это к вопросу о бусте.
Это же и касается ядрёного кеширования.
`cid` varchar(255) NOT NULL DEFAULT '',
`data` longblob,
`expire` int(11) NOT NULL DEFAULT '0',
`created` int(11) NOT NULL DEFAULT '0',
`headers` text,
`serialized` smallint(6) NOT NULL DEFAULT '0',
PRIMARY KEY (`cid`),
KEY `expire` (`expire`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Если не трудно, подскажите, где эти строки прописаны?
Лучше не надо
Надо.
Эти строки есть в phpMyAdmin SQL Dump.
varchar(255) - Это ограничение не дает кешировать страницы с длинными адресами? И что, если увеличить допустимый размер или изменить тип поля, или кодировку в cache_content или cache_page базы данных?
Уважаемые Господа, прошу просто и толково объяснить проблему со стандартным кешированием страниц с длинными урлами и можно ли ее преодолеть? Заранее благодарен.
У типа varchar, 255 - максимальная длина
У этого типа макс. длина 333 символа UTF-8 или 999 байт. Можете проверить сами.
Уважаемый RxB Вы были не правы в своем высказывании, и если Вы знаете как решить объявленную проблему, отпишитесь первым.
Если я не прав, то может стоит написать как должно быть?
Мы не в слабое звено играем, поди
MySQL 5.0.3 and later is subject to the maximum row size (65,535 bytes, which is shared among all columns) and the character set used
модуль http://drupal.org/project/transliteration приносит счастье
Решение оказалось довольно простым.
VARCHAR - это текстовое поле переменной длины и эту длину можно менять.
Поле cid в таблице cache_page имеет не только тип VARCHAR, но и статус ключевого поля. Именно статус ключевого поля наносит ограничение , но не в числе символов, а в размере поля =1000 байт на сегодняшний день.
При кодировке utf-8 ограничение наступает после 333 символов =999 байт.
При кодировке cp1250 или acsii ограничение наступает после 1000 символов =1000 байт.
А теперь подробно, что нужно изменить.
1. Заходим в phpMyAdmin, находим нашу базу данных и заходим в нее
2. Находим таблицу cache_page и заходим в ее структуру (кнопка "структура" в этой же строке)
3. Находим поле cid и жмем на кнопку "изменить"
4. В настройке "Сравнение" выбираем тип cp1250_general_ci или acsii_general_ci
5. В настройках "Длина/значения" ставим 1000 или меньше, больше не получится
6. Ничего больше не меняем.
После этих нехитрых изменений все страницы с килилицей в урлах стали кешироваться. Но, в любом случае, не следует сильно разгоняться в названиях страниц и терминов таксономии, попадающих в урл страницы. Количество видимых символов и то во что они превращаются - сильно отличаются.
Конечно, можно использовать транслитератор, но по-моему, глупо отказываться от дополнительного преимущества наличия русских ключевых слов в адресе страницы при поисковой выдаче для русскоязычной аудитории. И как по мне, адреса с кирилицей гораздо читабельнее.
За несколько дней тестирования после внесенных изменений, никаких глюков в выдаче страниц не обнаружил. При повторном обращении страницы отображаются в пределах 1с, стандартное кеширование для анонимов довольно хорошо работает.
Экспорт/импорт измененной базы проходит нормально. Вот пока и все.
Я в очередной раз разочарую, но если закешированная страница отдаётся у вас за секунду, то можно сказать, что кеширование не работает.
Хостинг видать отстой
Абсолютно не разочаровали. Без кеширования некоторые страницы отрабатываются за 5-6 секунд, а так, менее чем за одну. Поэтому кеширование таки работает и меня это пока вполне устраивает.
Меняйте лучше сейчас хостинг, 5-6 секунд это вообще ахтунг, говорит о проблемах либо с программной частью, либо о том что хоститесь вы на бухгалтерских счётах
Да бросьте вы, автор имел в виду явно то, что на загрузку страницы уходит одна секунда, а не генерация страницы. Тут может быть множество причин, может у автора интернет говно, или картинок постоянно подгружается с разных хостов на каждоый странице?
5-6 секунд для загрузки, конечно неплохо, но хотелось бы не больше 4, крутите настройки
Что такое загрузка страницы? Загрузка всех внешних ресурсов страницы? Если это так, то это только подтверждает мои слова про хостинг.
Время загрузки изображений, JS, стилей, etc, никак не зависит от включенного кеширования, а у автора разница между включённым кешированием и отключённым пять раз.
Подвожу итог 5-ти месячной работы сайта с режимом кеширования модулей Authcache и Block Cache Alter как для анонимов, так и для зарегистрированных пользователей:
1. Authcache - модуль полезный, но вряд ли подойдет для посещаемых форумов и аналогичных ресурсов, для более статичных сайтов типа каталог или интернет магазин очень даже полезный
2. Block Cache Alter - подойдет всем, поскольку кеширует блоки, которые на практике редко обновляются, в т.ч существенно ускоряет отображение страниц с динамическим меню.
3. Views - имеет встроенное кеширование как запросов, так и выводимого содержания, только нужно грамотно настроить.
4. Poormanscron - помогает обновлять закешированную информацию по заданному расписанию.
Работу модулей можно увидеть на сайте alma.kiev.ua