Модуль кеширования алиасов путей (новая версия)

Главные вкладки

Аватар пользователя seaji seaji 29 сентября 2008 в 0:53

Привет всем.
Прошу прощения за то, что я так долго не выкладывал новую версию модуля кеширования алиасов путей.
Моя первая попытка http://drupal.ru/node/19369 оказалась немного глючной и я решил не торопиться и протестировать все хорошенько.
Новая версия кеша сделана как отдельный модуль. Но хакать path.inc все равно придется, но только в трех местах функцию drupal_lookup_path(). Не пугайтесь, хакать "ручками" ничего не придется. Уже хакнутый файл path.inc включен в архив и вам остается его только скопировать в папку includes. Хакнутый файл path.inc защищен от зависимости включения/выключения модуля. Если вы выключаете мой модуль, то path.inc работает ровно так, как работает системный модуль.

Особенности работы модуля
Все данные статически кешируются внутри функции url_alias_cache().
У нее есть три режима работы: 1 - получение кеша, 2 - установка кеша, 3 - сохранение кеша.
1 - получение кеша происходит при первых запросах на получение алиасов. если кеш не получен, то идет запрос к базе, если кеш получен, то данные берутся из кеша.
2 - установка кеша, если алиаса нет в кеше, то после запроса в базу нам нужно добавить его в общий массив кеша, который после этого будет сохранен в базу.
3 - сохранение кеша, запись обновленного массива с алиасами в таблицу кеша алиасов
В модуль добавлена специальный пункт меню admin/settings/url_alias_cache_flush, он позволяет сбросить весь кеш алиасов одним кликом.
Еще сброс кеша прописан в крон, при условии, что таблица кеша алиасов содержит больше 3000 записей.
Так же сброс данных происходит если количество обновлений кеша для данной страницы превышает 7 обновлений.

В таблице кеша алиасов используется двойной индекс, это cid = $_GET['q'] и page = $_GET['page'].
Эта система нужна для вариантов страниц с пейджингом, например списки документов в категории и пр.

ВложениеРазмер
Иконка пакета url_alias_cache.zip4.5 КБ

Комментарии

Аватар пользователя seaji seaji 29 сентября 2008 в 20:16

Про цифры.
Проблема с алиасами путей давно известна. И другие варианы уже предлагались.
Например здесь: http://drupal.ru/node/19163 автор говорит об увеличении производительность в 60 раз.
Мои замеры показали экономию в 47 запросов к базе на главной форума (be-in.ru/forum).
А вообще все зависит от того, сколько у вас ссылок на странице.
Если ссылок 40, то вместо 40 запросов будет всего пара, если ссылок 100, то считайте, что минус 100 запросов к базе.
Запросы к таблице алиасов, конечно, легковесные, но все же. Лучше один запрос на 10 мс. чем 50 запросов на 5 мс.

Аватар пользователя Sky Cat Sky Cat 1 октября 2008 в 1:01

Спасибо за отличный модуль.
Несколько вопросов:
1. Кэшируются алиасы и для анонимов и для залогиненных пользователей?
2. Можно ли перевести таблицу url_alias_cache в InnoDB и будет ли это эффективнее?

Аватар пользователя seaji seaji 1 октября 2008 в 3:24

1. Алиасы кешируются независимо от того аноним это или залогиненный пользователь.
2. Переводить в InnoDB нет никакого смысла. Операций записи этой таблицы достаточно мало, только первый просмотр страницы. А вот операций чтения достаточно много. А на чтении InnoDB тормозит.

Аватар пользователя seaji seaji 1 октября 2008 в 3:26

Да, кстати. Не забывайте об одном условии.
Если вы переназначаете алиас при изменении ноды или из админки, напрямую, то не забудьте, что кеш алиасов должен быть скинут полностью. Иначе старая url-ка останется в кеше.

Аватар пользователя neochief neochief 1 октября 2008 в 14:11

Подкину все же немного цифр. Пробовал модуль на живом сайте, а именно на zoochel.ru.

Морда сайта (довольно загруженная часть, было более всего интересно):
Средние значения до запуска модуля:
593 queries in 606.7 milliseconds.
После:
355 queries in 526.33 milliseconds.
Разница: 250 запросов (46%) и 80 миллисекунд (13%)

Страница сайта (например эта):
До:
369 queries in 360.67 milliseconds
После:
210 queries in 302.45 milliseconds.
Разница: 150 запросов (40%) и 60 миллисекунд (16%)

Итого, выигрыш в количестве запросов значительный, хотя и реальный прирост производительности не такой большой. Но все же, прирост в 15% это тоже хорошо.
Вероятно, на сайте с меньшим количеством фишек, процент улучшения будет больше, но абсолютные значения остануться такими же.

Тестировалось все на локали, под виндой и денвером при включенном стандартном кеше Дру. Как бы то ни было, я думаю динамика везде будет одинаковая.

Аватар пользователя neochief neochief 10 ноября 2015 в 11:45

Отрефакторил модуль и привел его к "товарному виду".

Изменения:
0. Обозвал модуль и таблицу немного благозвучне и универсальнее (касается таблицы).
1. Теперь при обновлениях нодов кеш будет сбрасываться автоматически.
2. При включенном кешировании, модуль не мог работать (исправил, прописав при инстале bootstrap = 1)
3. Поправил несколько недочетов в запросах
4. Добавил дополнительный хук для очистки кеша через Devel
5. Сделал локализацию в стиле Друпала
6. Переместил пункт меню под ветку меню Производительность
7. Добавил патч на path.inc для любителей патчей
8. Добавил README.TXT и LICENSE.txt
9. Добавил недостающие комменты к коду, где смог

Перед установкой данной версии, стоит произвести uninstall старого модуля, дабы потереть старую таблицу. После чего можно спокойно удалить старую версию с диска и поставить эту.

З.Ы. Вячеслав, надеюсь вы не против появления данной ревизии Smile

Аватар пользователя Sannis Sannis 14 декабря 2008 в 17:04

<a href="mailto:andypost@drupal.org">andypost@drupal.org</a> wrote:
Может кто-нить зальет его на d.o - пусть еще погоняют не русские пользователи, на выходных попробую портировать на 6ку

Есть такие планы у уважаемых авторов? Smile

Аватар пользователя seaji seaji 16 декабря 2008 в 0:21

А куда заливать, не подскажете. В модули (это же модуль) или в патчи ядра (есть патч)???
И как это сделать?

Аватар пользователя Sky Cat Sky Cat 1 октября 2008 в 22:04

Кто-нибудь пробовал этот модуль в связке с Nofollow list?
У меня стало жутко тормозить при добавлении/изменении нодов и комментариев. От 30 секунд и выше.
После отключения модуля стало все нормально.

Аватар пользователя seaji seaji 2 октября 2008 в 0:32

Этот модуль является просто фильтром и используется в форматах ввода.
Не думаю, что у них может быть конфликт.
А какие еще, "нетрадиционные" модули у Вас установлены.
Традиционные, это те, что установлены у большинства пользователей, views, CCK и пр.

Аватар пользователя Sky Cat Sky Cat 2 октября 2008 в 1:03

"seaji" wrote:
А какие еще, "нетрадиционные" модули у Вас установлены.
Традиционные, это те, что установлены у большинства пользователей, views, CCK и пр.

Из нетрадиционных разве что Block Cache. Он при обновлении/правке нод кэш обновляет. Может с ним конфликтует.

Аватар пользователя olk olk 10 ноября 2015 в 11:45

Ну раз пошла такая пъянка Smile выкладываю модуль для 6.х
За основу взят модуль neochief
Изменения по сравнению с пятой версией:
1. Изменен файл cache_url_alias.install (применена схема установки таблицы принятая в 6.х, и соответственно модуль теперь может работать и на PostgreSql)
2. Убран пункт меню для очистки кэша
3. Добавлен хук cache_url_alias_flush_caches, для очистки кэша по кнопке «Очистить кэш данных» в перфомансе
4. Ну и потправлены path.inc и path.inc.patch - приминительно к 6-ой версии

Аватар пользователя neochief neochief 10 ноября 2015 в 11:45

Исправил отсутствие обновления кеша при прямом редактировании алисов (drupal_clear_path_cache() - да, есть такая функция в Друпале Wink

Исправил в обеих версиях. Для обновления нужно перезалить файл path.inc в директорию includes

Аватар пользователя Izem Izem 3 октября 2008 в 20:11

Попробовал модуль для D6 на заполненном информацией сайте, расположенном на хостинге с очень медленной базой (HTML и PHP там "летают", однако, что непонятно). На сайте установлен Pathauto и на страницы выводится довольно много заголовков разных нод. Т.е., как раз по теме. Smile

Так вот, и на залогиненном юзере, и на анонимусе стало грузиться заметно (~30%) быстрее.

В общем, за модуль ОГРОМНОЕ спасибо.

PS: Devel почему-то показывает то же количество запросов, что и было. Наверно, он не считает количество запросов непосредственно к базе? Кстати, а как их правильно посчитать тогда?

PPS: А этот модуль как-нибудь настраивается?

Аватар пользователя seaji seaji 3 октября 2008 в 23:24

"Izem" wrote:
А этот модуль как-нибудь настраивается?

Изначально настройки не предусмотрены т.к. там собственно нечего настраивать.
Но вот я бы ввел в настройки опцию выбора сбрасывать кеш или нет при редактировании страницы. Т.к. сбрасывать кеш в этом случае имеет смысл только если меняется алиас. А свободное изменение алиасов это зло, т.к. многие будут тыкаться по старому алиасу и получать ошибку 404.

Аватар пользователя Sky Cat Sky Cat 4 октября 2008 в 0:51

Включено нормальное кэширование для гостей + BlockCache
Пользователь (после сброса кэша): Executed 198 queries in 168.66 milliseconds. Page execution time was 7139.15 ms.
Пользователь (с кэшем): Executed 118 queries in 93.84 milliseconds. Page execution time was 495.64 ms.

Гость (после сброса кэша): Executed 159 queries in 129.16 milliseconds. Page execution time was 702.33 ms.
Гость (с кэшем): Executed 123 queries in 91.33 milliseconds. Page execution time was 456.98 ms.

cache_url_alias + "нормальное" кеширование друпала
Пользователь (после сброса кэша cache_url_alias и "нормального" кэширования друпала): Executed 406 queries in 207.55 milliseconds. Page execution time was 6283.43 ms.
Пользователь (после многократного рефреша одной страницы, с кешем cache_url_alias и "нормальным" кэшированием друпала): Executed 102 queries in 43.39 milliseconds. Page execution time was 6361.62 ms.

Гость (после сброса кэша cache_url_alias и "нормального" кэширования друпала): Executed 107 queries in 41.76 milliseconds. Page execution time was 5624.46 ms.
Гость (после многократного рефреша одной страницы, с кешем cache_url_alias и "нормальным" кэшированием друпала): не получилось проверить - devel статистику под гостем выводит после сброса кэша. На субъективный взгляд - так же, как в первой конфигурации, т. е. практически мгновенно.

Тестирование проводилось для главной страницы моего сайта (http://www.yarcom.ru).
И в первом (BlockCache) и во втором (cache_url_alias) случае все страницы кроме главной летают. Цифры приводить не буду, но практически одинаково быстро.
Однако, главная страница заметно медленнее других открывается. Но в первом случае, при использовании BlockCache тормозила только первая загрузка главной страницы. После того, как обновился кэш - так же быстро, как и все другие страницы.
С модулем cache_url_alias такого не произошло. Сколько не обновляй страницу, стабильно 6-7 секунд.
Естественно, это для залогиненных пользователей.

Отдельно хочу описать странное поведение модуля при изменении любой информации (ноды, комментарии и т. д.). После начала выполнения действия удаления или изменения, сайт зависает. Страница может не обновляться и 20 и 30 секунд. Хотя, если тут же зайти гостем в тот материал, откуда удаляли комментарий, оказывается, что комментария уже нет. А под юзером так страница так и не обновилась. Висит, типа какие-то действия выполняются.

В общем, не хочу никого переубеждать, но я пока для себя выбрал BlockCache.

Аватар пользователя demarko demarko 21 ноября 2008 в 17:08

СООБЩЕНИЕ ДЛЯ - Sky Cat

Позвольте спросить, Ваш сайт находится на собственном сервере, VPS или публичном хостинге??? Какие модули использовлись и сколько? Какие одули для оптимизации/кеширования применялись??? У нас по функциональности сайт в половину Вашего висит на VPS и несчадно вываливают ошибки в отказе MySQL говорят что сайт тяжелый много запросов...

Ответьте пожалуйста на вопросы. Заранее спасибо!

Аватар пользователя Sky Cat Sky Cat 15 декабря 2008 в 4:20

>СООБЩЕНИЕ ДЛЯ - Sky Cat
>
>Позвольте спросить, Ваш сайт находится на собственном сервере, VPS или публичном хостинге??? Какие модули использовлись
>и сколько? Какие одули для оптимизации/кеширования применялись??? У нас по функциональности сайт в половину Вашего висит
>на VPS и несчадно вываливают ошибки в отказе MySQL говорят что сайт тяжелый много запросов...
>
>Ответьте пожалуйста на вопросы. Заранее спасибо!
Прощу прощения за столько долгое молчание.
Если еще актуально:
1. Тарифный план Standart: http://masterhost.ru/service/hosting/vps/unix/
2. Модулей куча, есть самописные, есть из общего репозитария: CCK, Category, Panels, CAPTCHA, Syndication, JQuery, XML Sitemap, Autolocale, Block Cache, Classified Ads, Click2bookmark, Custom Error, Excerpt, FCKeditor, Longer Node Titles, Meta tags, Modr8, nofollowlist, Page Title, Pathauto, Poormanscron, Search config, Site map, Support file Cache (рекомендую всем пользователям пятерки), Token, Tracker 2, Transliteration, Update status.
3. Количество нод - 11,178
4. На хостинге стоит XCache, включено сжатие gzip
5. Суточная посещаемость ~ 3.200 уников, просмотры ~ 14.000
6. Использовались техники с сайта webo.in (minify, кэширование картинок, скриптов и css на 10 лет в будущее, оптимизация кода и картинок и т.п.)
7. Часть таблиц в InnoDB, часть в MyISAM

В принципе, на данный момент производительность чтения страниц меня устаивает. Единственный минус (скорее всего, из-за BlockCache) - любое добавление/изменение информации выполняется от 10 секунд и выше. Эту проблему пока не смог решить.

Аватар пользователя andypost@drupal.org andypost@drupal.org 5 октября 2008 в 0:54

Может всё же посмотреть на адаптивное кеширование? Есть большая вероятность, что оно будет включено в ядро!
Идея проста:
Сбор статистики альясов для каждой из страниц и на основании этой статистики кешировать наиболее часто используемые альясы. Причем, этот режим отключаем!

Quote:
The patch collects a statistics of what aliases appear on a page. If an alias appears frequently enough (60% but overrideable) then that alias is decided to be constant and these are written into a table and then later cached per $_GET['q'] . Testing the patch is not trivial as merely setting the path strategy will not show or change much as the path_alias_map table will be empty. You can, however, generate content, load a few pages, run cron and see that path_alias_map is populated and once that is true, benchmarking would make sense.

Аватар пользователя OnlyKaramba OnlyKaramba 10 ноября 2015 в 11:45

Огромное спасибо seaji и neochief за этот модуль!

Поставил на сайт бисер инфо, это 240 000 посещений и 3 800 000 просмотров страниц за последние 30 дней.

Тестирование модуля проводил при: Сейчас на сайте 133 пользователя и 111 гостей.

Для большей объктивности перезагружал главнуй страницу по 10 раз до влючения модуля и после. Потом псчитал среднее значение.

Результат превзошел все мой ожидания:
- количество запросов снизилось о 31%
- время, необходимое для проведения запросов снизлось о 75% !!!

Загруженость сервера можно помотреть на http://biser.info/munin/info/biser.info.html

Следующим этапом будет включение memcache

Аватар пользователя Dimm Dimm 24 ноября 2008 в 21:19

Так Вы кэшируете список алиасов отдельно для каждой конкретной страницы!
Почему?
Не лучше ли создать список алиасов для всего сайта?

Аватар пользователя seaji seaji 25 ноября 2008 в 12:58

Этот вопрос уже обсуждался на этом сайте.
Такой подход является тупиковым.
При разрастании таблицы алиасов у Вас загрузка кеша выжрет всю память.

Аватар пользователя Dimm Dimm 24 ноября 2008 в 21:46

Отслеживаю запрос
$result = db_query("SELECT data, count FROM {cache_url_alias} WHERE cid = '%s' AND page = %d", $_GET['q'], $_GET['page']);
он выполняется раз 30 на одной странице.
довавил $data_empty = TRUE;
<?php
else {
$map = unserialize($alias_result['data']);
$count = $alias_result['count'];
$data_empty = TRUE;
return $map;
}
?>
Запрос стал выполняться всего 1 раз.
У меня PHP5.

Аватар пользователя Dimm Dimm 24 ноября 2008 в 23:58

Исправил (count($map_path) ==2) на >0 - т.к. возможен алиас и для 1 языка
<?php
switch ($op) {
case 'get':
// if ((count($map_path) ==2) && !($data_empty)) {
if ((count($map_path) > 0) && !($data_empty)) {
?>

Аватар пользователя seaji seaji 25 ноября 2008 в 12:56

Дело в том, что первый запрос в таблицу алиасов должен проходить мимо кеша. Т.к. в первом запросе мы получаем $_GET['q'] и $_GET['page'], которые являются индексами кеша. Пока мы не получим эти данные из предъявленного алиаса мы не сможем дернуть кеш.
Поэтому я и делал (count($map_path) ==2) вызов кеша при заполнении массива $map_path в два элемента.

Аватар пользователя Dimm Dimm 28 ноября 2008 в 22:41

Здравствуйте, seaji.
Подскажите пожалуйста:
В модуле locale по умолчанию кэшируются строчки длинной менее 75 символов ...AND LENGTH(s.source) < 75...
$result = db_query("SELECT s.source, t.translation, t.language FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = '%s' WHERE s.textgroup = 'default' AND s.version = '%s' AND LENGTH(s.source) < 75", $langcode, VERSION);

Стоит ли хакнуть locale чтобы кэшировать все строки?
(...AND LENGTH(s.source) < 999...)
Я сделал так - число запросов сократилось на 10-20%.

Может ли это повлечь замедление выборки или большой расход памяти?

Аватар пользователя seaji seaji 29 ноября 2008 в 13:48

Сложно сказать. Количество переведенных строк на сайте сохраняется более менее на одном уровне. Может быть и ничего страшного в этом не будет.
Если вы так сделали и сайт стал работать быстрей, то в будущем положение врядли изменится.
А на столько быстрей стали грузиться страницы? Я имею ввиду секунды, а не запросы.

Аватар пользователя Dimm Dimm 1 декабря 2008 в 6:13

Кэширование строк длиной <75
Page execution time was 583.44 ms. Executed 167 queries in 148.53 milliseconds.
Page execution time was 534.43 ms. Executed 167 queries in 151.49 milliseconds.
Page execution time was 532.61 ms. Executed 167 queries in 146.53 milliseconds.

Кэширование всех строк
Page execution time was 534.24 ms. Executed 129 queries in 133.64 milliseconds.
Page execution time was 517.06 ms. Executed 130 queries in 123.81 milliseconds.
Page execution time was 567.35 ms. Executed 129 queries in 130.06 milliseconds.

Аватар пользователя seaji seaji 1 декабря 2008 в 12:05

Количество запросов уменьшилось на 20% (37 запросов).
Время, потраченное на эти запросы уменьшилось (в среднем) на 13% (19 мс)
Общее время генерации страницы уменьшилось на 2% (10 мс).

Видимо у Вас есть более узкое место чем база данных.

Еще есть один момент.
Общее время генерации страницы 534.24 мс, время на запросы к базе 133.64 мс.
534.24 - 133.64 = 400.6 мс
Так у меня вопрос, куда деваются эти 400 мс? На парсинг кода?

Аватар пользователя Dimm Dimm 1 декабря 2008 в 15:47

Наверно на парсинг и выполнение. APC стоит.
К тому же часть запросов идет по-очереди - по результату исполения одного запроса - выполняется другой - может плюсуется ожидание ответа сервера.

Аватар пользователя Dimm Dimm 1 декабря 2008 в 21:19

Если на хостинге nic.ru тариф 301 результаты такие:
Page execution time was 534.24 ms. Executed 129 queries in 133.64 milliseconds.

То дома на CeleronD 3.2ГГц 2Гб памяти Денвер PHP5+APC
Page execution time was 1800 ms. Executed 129 queries in 193 milliseconds.
Page execution time was 1900 ms. Executed 129 queries in 197 milliseconds.
Page execution time was 2000 ms. Executed 129 queries in 209 milliseconds.

Селерон в 4 раза проигрывает.

Аватар пользователя seaji seaji 1 декабря 2008 в 12:27

А кто знает, из профессионалов по PHP, каким образом парсятся скрипты?
Сначала происходит парсинг, а потом выполнение? Или выполнение идет вместе с парсингом?
Грубо говоря, если я замерю время в начале index.php, а затем в конце и посчитаю разницу, что это будет за время? Парсинг + выполнение или чисто выполнение?

Аватар пользователя gorr gorr 1 декабря 2008 в 12:56

Тут многое зависит от настроек сервера и php (используется ли eaccelerator, APC) и от того как используется друпал, например если в теле программы есть оператор eval, а он используется в друпале часто, например при использовании php кода внутри блоков и во многих других местах и сторонних модулях, то этот кусок кода будет анализироваться прямо во время исполнения программы, а основная масса кода анализируется до его исполнения.

Аватар пользователя seaji seaji 1 декабря 2008 в 13:55

Значит, все таки 400 мс. это время исполнения кода.
Sad печально если исполнение php занимает в 4 раза больше времени чем запросы к базе.

Аватар пользователя nleo nleo 2 декабря 2008 в 8:01

у меня на ноуте на турионе х2 1,6 ГГц

Сразу после запуска денвера первый заход на главную
Page execution time was 10266.27 ms. Executed 58 queries in 1471.59 milliseconds.
Заход в админку:
Page execution time was 7569.43 ms. Executed 170 queries in 1016.26 milliseconds.
Снова на главную:
Page execution time was 495.89 ms. Executed 57 queries in 122.5 milliseconds

Денвер в стандартной(без апс), модули стоят по минимуму самое нужное. Я думаю, что 10266.27 ms выполнялся из-за чтения с жесткого диска.

Для хостинга с еАкселератором, таже последовательность переходов:

Page execution time was 4541.67 ms. Executed 66 queries in 895.75 milliseconds.
Page execution time was 3167.27 ms. Executed 143 queries in 525.4 milliseconds.
Page execution time was 177.65 ms. Executed 65 queries in 26.25 milliseconds.

Сайт пока в тестовом состоянии я был единственным посетителем, плюс утренние часы.

Я понимаю, что это отношения к Модулю кеширования алиасов путей не имеет, я пока и алиасы не импользую, но может кому-нибудь будет интересно.

Аватар пользователя Sky Cat Sky Cat 16 декабря 2008 в 1:24

"seaji" wrote:
А куда заливать, не подскажете. В модули (это же модуль) или в патчи ядра (есть патч)???
И как это сделать?

Если вы это написали к моему комментарию, то не совсем понял ваш вопрос.

Аватар пользователя neochief neochief 10 ноября 2015 в 11:45

Мне решительно не ясно почему еще никто (кроме, видимо, Dimm), не сказал, что модуль, по крайней мере, для Д6 не работает совсем Smile
Сделал апдейт, под шестеркой и все пофиксилось. По аналогии сделал и с пятеркой, можете тестить.

Вкратце об изменениях. Таки разобрался полностью в модулем и заменил злополучное условие

if ((count($map_path) > 0) && ($data_empty)) {

на более вменяемое ну и связанные с этим изменения тоже внес. Заодно пофиксил language код для украинского перевода, оказывается он назывался не так.

Аватар пользователя seaji seaji 14 января 2009 в 17:12

Поставил себе версию модуля для D6.
При первой загрузке страницы количество запросов выросло ровно на столько, на сколько их снижает кеширование.
На некоторых страницах функция cache_url_alias дергала следующий запрос: SELECT data, count FROM cache_url_alias WHERE cid = 'photos' AND page = 0 по восемьдесят раз.
Таким образом мы выигрываем на кешированных страницах ровно столько же сколько проигрываем на не кешированных.
С этим надо что то делать.

Аватар пользователя andypost@drupal.org andypost@drupal.org 18 декабря 2008 в 4:33

Пора такие наработки собирать в отдельном разделе, что-то по типу snippets, а может и модулей - может попробовать это дело на d.o выложить? Там публика поактивней...

Аватар пользователя gorr gorr 18 декабря 2008 в 12:41

Да, Андрей, думаю давно пора такой раздельчик на др.ру сделать, а может и отдельный тип контента - сниппет или модуль(с описанием).

Аватар пользователя neochief neochief 14 января 2009 в 18:02

Кстати, я его так и оставил. Там даже если он хорошо работает, получаются глюки при сохранениях нодов, когда путь у ноды меняется. Копался-копался, но не докопался до причины, обновив железо на сервере Wink

Аватар пользователя leonidvs leonidvs 15 января 2009 в 8:03

"seaji" wrote:
При первой загрузке страницы количество запросов выросло ровно на столько, на сколько их снижает кеширование.
На некоторых страницах функция cache_url_alias дергала следующий запрос: SELECT data, count FROM cache_url_alias WHERE cid = 'photos' AND page = 0 по восемьдесят раз.
Таким образом мы выигрываем на кешированных страницах ровно столько же сколько проигрываем на не кешированных.
С этим надо что то делать.

Поставил себе модуль на 5 друпал , тоже заметил в devel что при открытии страницы первый раз запрос: SELECT data, count FROM cache_url_alias WHERE cid = 'photos' AND page = 0 по 150 раз

после кеширования запросы на 30-40% снижаются и рage execution time на 15-20% , устранить бы еще эту беду при первом открытии.

Аватар пользователя rmcippo rmcippo 22 января 2009 в 3:31

Уважаемые, установил модуль для D6, на странице запуска крона появилось предупреждение:
user warning: Unknown column 'expire' in 'where clause' query: cache_clear_all /* admin : cache_clear_all */ DELETE FROM cache_url_alias WHERE expire != 0 AND expire < 1232584126 in Z:\home\my_domain\www\includes\cache.inc on line 166.
Подскажите, пожалуйста, как это исправить? Спасибо

Аватар пользователя olk olk 22 января 2009 в 10:13

Надо в таблицу {cache_url_alias} добавить поле expire
`expire` int(11) NOT NULL DEFAULT '0' ...
ошибка известная, просто мало наверное кто использует этот модуль (так как он требует патча ядра), поэтому наверное не исправляют Wink

Аватар пользователя rmcippo rmcippo 22 января 2009 в 12:00

Большое спасибо, скажите пожалуйста, поле нужно будет добавлять при каждом добавлении Drupal? Если не исправлять, то модуль будет работать неправильно?

Аватар пользователя olk olk 22 января 2009 в 12:12

Вы наверное хотели сказать обновлении Drupal ? Ответ нет, это таблица модуля.
Что бы в дальнейшем не мучится, можете просто подправить в файлике модуля cache_url_alias.install
функцию cache_url_alias_schema, замените ее на следующую ...
Затем отключите модуль и удалите его (не физически а в интерфейсе модулей), а затем по новой включите,
в результате этих действий у вас должна образоваться правильная табличка cache_url_alias
<?php
/**
* Implementation of hook_schema().
*/
function cache_url_alias_schema() {
$schema['cache_url_alias'] = array(
'description' => t('URL Aliases Cache table.'),
'fields' => array(
'cid' => array(
'type' => 'varchar',
'not null' => TRUE,
'length' => 255,
'default' => '',
),
'page' => array(
'type' => 'int',
'not null' => TRUE,
'default' => 0,
),
'count' => array(
'type' => 'int',
'not null' => TRUE,
'size' => 'tiny',
),
'data' => array(
'type' => 'text',
'not null' => TRUE,
'size' => 'big',
),
'expire' => array(
'type' => 'int',
'not null' => TRUE,
'default' => 0,
),

),
'primary key' => array('cid','page'),
'indexes' => array(
'count' => array('count'),
'expire' => array('expire'),
),
);
return $schema;
}
?>

Аватар пользователя rmcippo rmcippo 22 января 2009 в 12:02

Большое спасибо, скажите пожалуйста, поле нужно будет добавлять при каждом добавлении Drupal? Если не исправлять, то модуль будет работать неправильно?

Аватар пользователя seaji seaji 22 января 2009 в 12:53

Да, для этого модуля требуется ревизия как для D6, так и для D5. Не расстраивайтесь, все будет, модуль не заброшен. Просто пока времени нет.
Так же этот модуль будет включен в "Fast Drupal Distribution"

Аватар пользователя Paldru Paldru 20 августа 2009 в 23:16

"seaji" wrote:
Да, для этого модуля требуется ревизия как для D6, так и для D5. Не расстраивайтесь, все будет, модуль не заброшен. Просто пока времени нет.

Для 6-го друпала стабильная версия есть?

Аватар пользователя Paldru Paldru 21 августа 2009 в 18:51

"neochief" wrote:
Прикрепленный файлРазмер
cache_url_alias-5.x-1.4.zip14.14 кб
cache_url_alias-6.x-1.2.zip14.27 кб

Поставил версия для 6го друпала. Все вроде как работает. Но при переходе по ссылкам измененным с помощью функций custom_url_rewrite_inbound и custom_url_rewrite_outbound страница зависает и не загружается. Как это исправить?

Аватар пользователя seaji seaji 29 ноября 2009 в 15:44

Если данная тема еще интересна, то тогда я займусь ее развитием.
Модуль действительно приятный. Однако, я думал, что на орге уже есть что то подобное, а дублирований они не допускают.
Если кто знает подобные модули на орге, то киньте ссылку плиззз.
Еще у меня есть несколько идей по кешированию и оптимизации.
Осуществление одной из этих идей позволит не задумываться над количеством включенных модулей. Т.е. сайты с 10 и 1000 включенных модулей будут работать одинаково быстро.

Аватар пользователя Тыдж Тыдж 29 ноября 2009 в 17:57

есть модуль Path Cache но меня несколько смущает строчка в описании:
"The patch uses Drupal's standard caching backend calls but is probably only useful if the caching backend has been replaced with memcache."
смысл - модуль полезен если вместо стандартного кеширования юзается мемкеш.
а у меня шаред хостинг... =/
seaji буду необычайно рад если тема все-таки будет развиваться и все бы хотели услышать ваши идеи! для них можно создать отдельную ветку чтобы не было каши

Аватар пользователя Ljohn Ljohn 29 ноября 2009 в 17:59

"seaji" wrote:
Осуществление одной из этих идей позволит не задумываться над количеством включенных модулей. Т.е. сайты с 10 и 1000 включенных модулей будут работать одинаково быстро.

Ждем!

Аватар пользователя Тыдж Тыдж 30 ноября 2009 в 0:38

я проапдейтил свои проэкты до pressflow, но я не гуру и не вижу отличий в кешировании кроме функции внешнего кеширования, а так ничего нового не увидел. тестировал так же утилитой apache bench - практически нету разницы.

посоветуйте что-нибудь на тему: кеширование авторизированных пользователей. из опкод модулей на хостинге установлен xcache. модуль authcache 6.x-1.0-rc1 работает у меня только для анонимов, ломаю голову...

Аватар пользователя petrovnn petrovnn 8 ноября 2010 в 21:58

Вижу что прошел почти год с момента последнего сообщения в этой теме, и еще больше с того момента когда neochief выложил последнюю версию этого модуля.

А проблема до сих пор актуальна.

Вопрос - модуль жив, поддерживается?
Есть-ли он на d.org? я что-то не нашел.

И еще - за год-полтора друпаловский файл patch.inc теоретически мог поменяться (по факту я не знаю поменялся-ли он), так вот, данный файл, который идет в комплекте с этим модулем актуален-ли для последней версии друпала?

Аватар пользователя cosmos cosmos 15 ноября 2010 в 12:56

Хотелось бы узнать как поживает данные модуль
1) Идет ли его доработка?
2) Есть ли стабильная версия для 6ки?
3) Есть ли у разработчиков желание его довести до ума?