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.zip | 4.5 КБ |
Комментарии
А где цифры? Что он дает?
Про цифры согласен. Вот, подкину хорошую ссылку по теме.
Про цифры.
Проблема с алиасами путей давно известна. И другие варианы уже предлагались.
Например здесь: http://drupal.ru/node/19163 автор говорит об увеличении производительность в 60 раз.
Мои замеры показали экономию в 47 запросов к базе на главной форума (be-in.ru/forum).
А вообще все зависит от того, сколько у вас ссылок на странице.
Если ссылок 40, то вместо 40 запросов будет всего пара, если ссылок 100, то считайте, что минус 100 запросов к базе.
Запросы к таблице алиасов, конечно, легковесные, но все же. Лучше один запрос на 10 мс. чем 50 запросов на 5 мс.
Спасибо за отличный модуль.
Несколько вопросов:
1. Кэшируются алиасы и для анонимов и для залогиненных пользователей?
2. Можно ли перевести таблицу url_alias_cache в InnoDB и будет ли это эффективнее?
1. Алиасы кешируются независимо от того аноним это или залогиненный пользователь.
2. Переводить в InnoDB нет никакого смысла. Операций записи этой таблицы достаточно мало, только первый просмотр страницы. А вот операций чтения достаточно много. А на чтении InnoDB тормозит.
Да, кстати. Не забывайте об одном условии.
Если вы переназначаете алиас при изменении ноды или из админки, напрямую, то не забудьте, что кеш алиасов должен быть скинут полностью. Иначе старая url-ка останется в кеше.
Спасибо. Поставил на рабочий сайт, уже сутки полет нормальный. Скорость заметно возросла.
Подкину все же немного цифр. Пробовал модуль на живом сайте, а именно на 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% это тоже хорошо.
Вероятно, на сайте с меньшим количеством фишек, процент улучшения будет больше, но абсолютные значения остануться такими же.
Тестировалось все на локали, под виндой и денвером при включенном стандартном кеше Дру. Как бы то ни было, я думаю динамика везде будет одинаковая.
Отрефакторил модуль и привел его к "товарному виду".
Изменения:
0. Обозвал модуль и таблицу немного благозвучне и универсальнее (касается таблицы).
1. Теперь при обновлениях нодов кеш будет сбрасываться автоматически.
2. При включенном кешировании, модуль не мог работать (исправил, прописав при инстале bootstrap = 1)
3. Поправил несколько недочетов в запросах
4. Добавил дополнительный хук для очистки кеша через Devel
5. Сделал локализацию в стиле Друпала
6. Переместил пункт меню под ветку меню Производительность
7. Добавил патч на path.inc для любителей патчей
8. Добавил README.TXT и LICENSE.txt
9. Добавил недостающие комменты к коду, где смог
Перед установкой данной версии, стоит произвести uninstall старого модуля, дабы потереть старую таблицу. После чего можно спокойно удалить старую версию с диска и поставить эту.
З.Ы. Вячеслав, надеюсь вы не против появления данной ревизии
Спасибо Вам огромное. Как говорится одна голова хорошо, а две еще лучше.
Может кто-нить зальет его на d.o - пусть еще погоняют не русские пользователи, на выходных попробую портировать на 6ку
Есть такие планы у уважаемых авторов?
А куда заливать, не подскажете. В модули (это же модуль) или в патчи ядра (есть патч)???
И как это сделать?
Спасибо, весьма ценно!
Кто-нибудь пробовал этот модуль в связке с Nofollow list?
У меня стало жутко тормозить при добавлении/изменении нодов и комментариев. От 30 секунд и выше.
После отключения модуля стало все нормально.
Этот модуль является просто фильтром и используется в форматах ввода.
Не думаю, что у них может быть конфликт.
А какие еще, "нетрадиционные" модули у Вас установлены.
Традиционные, это те, что установлены у большинства пользователей, views, CCK и пр.
А для друпал 6 будеть ?
Из нетрадиционных разве что Block Cache. Он при обновлении/правке нод кэш обновляет. Может с ним конфликтует.
Ну раз пошла такая пъянка
выкладываю модуль для 6.х
За основу взят модуль neochief
Изменения по сравнению с пятой версией:
1. Изменен файл cache_url_alias.install (применена схема установки таблицы принятая в 6.х, и соответственно модуль теперь может работать и на PostgreSql)
2. Убран пункт меню для очистки кэша
3. Добавлен хук cache_url_alias_flush_caches, для очистки кэша по кнопке «Очистить кэш данных» в перфомансе
4. Ну и потправлены path.inc и path.inc.patch - приминительно к 6-ой версии
olk, seagi, neochief - спасибо за труд всем Вам. Здорово!
Только в другом порядке
[size=30]seaji[/size], [size=25]neochief[/size], [size=15]olk[/size].
А я сейчас на 6-ке сайты делаю, поэтому порядок верный
Спасибо!
Исправил отсутствие обновления кеша при прямом редактировании алисов (drupal_clear_path_cache() - да, есть такая функция в Друпале
Исправил в обеих версиях. Для обновления нужно перезалить файл path.inc в директорию includes
Попробовал модуль для D6 на заполненном информацией сайте, расположенном на хостинге с очень медленной базой (HTML и PHP там "летают", однако, что непонятно). На сайте установлен Pathauto и на страницы выводится довольно много заголовков разных нод. Т.е., как раз по теме.
Так вот, и на залогиненном юзере, и на анонимусе стало грузиться заметно (~30%) быстрее.
В общем, за модуль ОГРОМНОЕ спасибо.
PS: Devel почему-то показывает то же количество запросов, что и было. Наверно, он не считает количество запросов непосредственно к базе? Кстати, а как их правильно посчитать тогда?
PPS: А этот модуль как-нибудь настраивается?
Изначально настройки не предусмотрены т.к. там собственно нечего настраивать.
Но вот я бы ввел в настройки опцию выбора сбрасывать кеш или нет при редактировании страницы. Т.к. сбрасывать кеш в этом случае имеет смысл только если меняется алиас. А свободное изменение алиасов это зло, т.к. многие будут тыкаться по старому алиасу и получать ошибку 404.
имеет смысл только если меняется алиас - логично, вот только для этого вроде делать ничего не нужно, так как path_set_alias@api сам вызывает drupal_clear_path_cache@api
Включено нормальное кэширование для гостей + 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.
Очень интересные цифры, дело видимо не в запросах, а в скорости очистки таблицы кеша.
СООБЩЕНИЕ ДЛЯ - Sky Cat
Позвольте спросить, Ваш сайт находится на собственном сервере, VPS или публичном хостинге??? Какие модули использовлись и сколько? Какие одули для оптимизации/кеширования применялись??? У нас по функциональности сайт в половину Вашего висит на VPS и несчадно вываливают ошибки в отказе MySQL говорят что сайт тяжелый много запросов...
Ответьте пожалуйста на вопросы. Заранее спасибо!
>СООБЩЕНИЕ ДЛЯ - 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 секунд и выше. Эту проблему пока не смог решить.
Да, видимо нужно убрать обновление на nodeapi
Может всё же посмотреть на адаптивное кеширование? Есть большая вероятность, что оно будет включено в ядро!
Идея проста:
Сбор статистики альясов для каждой из страниц и на основании этой статистики кешировать наиболее часто используемые альясы. Причем, этот режим отключаем!
Огромное спасибо seaji и neochief за этот модуль!
Поставил на сайт бисер инфо, это 240 000 посещений и 3 800 000 просмотров страниц за последние 30 дней.
Тестирование модуля проводил при: Сейчас на сайте 133 пользователя и 111 гостей.
Для большей объктивности перезагружал главнуй страницу по 10 раз до влючения модуля и после. Потом псчитал среднее значение.
Результат превзошел все мой ожидания:
- количество запросов снизилось о 31%
- время, необходимое для проведения запросов снизлось о 75% !!!
Загруженость сервера можно помотреть на http://biser.info/munin/info/biser.info.html
Следующим этапом будет включение memcache
Спасибо за модуль, буду тестировать.
повтор
Так Вы кэшируете список алиасов отдельно для каждой конкретной страницы!
Почему?
Не лучше ли создать список алиасов для всего сайта?
Этот вопрос уже обсуждался на этом сайте.
Такой подход является тупиковым.
При разрастании таблицы алиасов у Вас загрузка кеша выжрет всю память.
Отслеживаю запрос
$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.
Исправил (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)) {
?>
Дело в том, что первый запрос в таблицу алиасов должен проходить мимо кеша. Т.к. в первом запросе мы получаем $_GET['q'] и $_GET['page'], которые являются индексами кеша. Пока мы не получим эти данные из предъявленного алиаса мы не сможем дернуть кеш.
Поэтому я и делал (count($map_path) ==2) вызов кеша при заполнении массива $map_path в два элемента.
Удалил.
А под кэширование locale данный модуль в принципе возможно доделать/переделать?
Здравствуйте, 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%.
Может ли это повлечь замедление выборки или большой расход памяти?
Сложно сказать. Количество переведенных строк на сайте сохраняется более менее на одном уровне. Может быть и ничего страшного в этом не будет.
Если вы так сделали и сайт стал работать быстрей, то в будущем положение врядли изменится.
А на столько быстрей стали грузиться страницы? Я имею ввиду секунды, а не запросы.
Кэширование строк длиной <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.
Количество запросов уменьшилось на 20% (37 запросов).
Время, потраченное на эти запросы уменьшилось (в среднем) на 13% (19 мс)
Общее время генерации страницы уменьшилось на 2% (10 мс).
Видимо у Вас есть более узкое место чем база данных.
Еще есть один момент.
Общее время генерации страницы 534.24 мс, время на запросы к базе 133.64 мс.
534.24 - 133.64 = 400.6 мс
Так у меня вопрос, куда деваются эти 400 мс? На парсинг кода?
Наверно на парсинг и выполнение. APC стоит.
К тому же часть запросов идет по-очереди - по результату исполения одного запроса - выполняется другой - может плюсуется ожидание ответа сервера.
Если на хостинге 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 раза проигрывает.
Так что же в итоге - польза от модуля/решения есть или наоборот вред? Мнения разделяются...
У меня почему-то сразу не пошло - пришлось дорабатывать.
ага на это самое
А кто знает, из профессионалов по PHP, каким образом парсятся скрипты?
Сначала происходит парсинг, а потом выполнение? Или выполнение идет вместе с парсингом?
Грубо говоря, если я замерю время в начале index.php, а затем в конце и посчитаю разницу, что это будет за время? Парсинг + выполнение или чисто выполнение?
Тут многое зависит от настроек сервера и php (используется ли eaccelerator, APC) и от того как используется друпал, например если в теле программы есть оператор eval, а он используется в друпале часто, например при использовании php кода внутри блоков и во многих других местах и сторонних модулях, то этот кусок кода будет анализироваться прямо во время исполнения программы, а основная масса кода анализируется до его исполнения.
Значит, все таки 400 мс. это время исполнения кода.
печально если исполнение php занимает в 4 раза больше времени чем запросы к базе.
Просто нужно ставить кеш опкода, например eaccelerator, APC xcache и получите ускорение в разы!
APC уже стоит.
у меня на ноуте на турионе х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.
Сайт пока в тестовом состоянии я был единственным посетителем, плюс утренние часы.
Я понимаю, что это отношения к Модулю кеширования алиасов путей не имеет, я пока и алиасы не импользую, но может кому-нибудь будет интересно.
Если вы это написали к моему комментарию, то не совсем понял ваш вопрос.
Выберите режим просмотра комментариев "Древовидный - развернутый" и все вопросы пропадут.
Мне решительно не ясно почему еще никто (кроме, видимо, Dimm), не сказал, что модуль, по крайней мере, для Д6 не работает совсем
Сделал апдейт, под шестеркой и все пофиксилось. По аналогии сделал и с пятеркой, можете тестить.
Вкратце об изменениях. Таки разобрался полностью в модулем и заменил злополучное условие
на более вменяемое ну и связанные с этим изменения тоже внес. Заодно пофиксил language код для украинского перевода, оказывается он назывался не так.
Поставил себе версию модуля для D6.
При первой загрузке страницы количество запросов выросло ровно на столько, на сколько их снижает кеширование.
На некоторых страницах функция cache_url_alias дергала следующий запрос: SELECT data, count FROM cache_url_alias WHERE cid = 'photos' AND page = 0 по восемьдесят раз.
Таким образом мы выигрываем на кешированных страницах ровно столько же сколько проигрываем на не кешированных.
С этим надо что то делать.
+15%
Пора такие наработки собирать в отдельном разделе, что-то по типу snippets, а может и модулей - может попробовать это дело на d.o выложить? Там публика поактивней...
Да, Андрей, думаю давно пора такой раздельчик на др.ру сделать, а может и отдельный тип контента - сниппет или модуль(с описанием).
Кстати, я его так и оставил. Там даже если он хорошо работает, получаются глюки при сохранениях нодов, когда путь у ноды меняется. Копался-копался, но не докопался до причины, обновив железо на сервере
Поставил себе модуль на 5 друпал , тоже заметил в devel что при открытии страницы первый раз запрос: SELECT data, count FROM cache_url_alias WHERE cid = 'photos' AND page = 0 по 150 раз
после кеширования запросы на 30-40% снижаются и рage execution time на 15-20% , устранить бы еще эту беду при первом открытии.
Уважаемые, установил модуль для 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.
Подскажите, пожалуйста, как это исправить? Спасибо
Надо в таблицу {cache_url_alias} добавить поле expire
`expire` int(11) NOT NULL DEFAULT '0' ...
ошибка известная, просто мало наверное кто использует этот модуль (так как он требует патча ядра), поэтому наверное не исправляют
Большое спасибо, скажите пожалуйста, поле нужно будет добавлять при каждом добавлении Drupal? Если не исправлять, то модуль будет работать неправильно?
Вы наверное хотели сказать обновлении 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;
}
?>
Большое спасибо, скажите пожалуйста, поле нужно будет добавлять при каждом добавлении Drupal? Если не исправлять, то модуль будет работать неправильно?
Огромное спасибо, сейчас попробую. Да хотел сказать, при обновлении
Да, для этого модуля требуется ревизия как для D6, так и для D5. Не расстраивайтесь, все будет, модуль не заброшен. Просто пока времени нет.
Так же этот модуль будет включен в "Fast Drupal Distribution"
В 7ке взяли много наработок и вот оно кеширование в ядре http://drupal.org/node/456824
А для шестерки те наработки никак нельзя применить? Замучался уже совсем с кешировнием.
Для 6-го друпала стабильная версия есть?
Поставил версия для 6го друпала. Все вроде как работает. Но при переходе по ссылкам измененным с помощью функций custom_url_rewrite_inbound и custom_url_rewrite_outbound страница зависает и не загружается. Как это исправить?
когда модуль будет на друпал.орге? очень полезный, хочется отслеживать его дальнейшее развитие!
Если данная тема еще интересна, то тогда я займусь ее развитием.
Модуль действительно приятный. Однако, я думал, что на орге уже есть что то подобное, а дублирований они не допускают.
Если кто знает подобные модули на орге, то киньте ссылку плиззз.
Еще у меня есть несколько идей по кешированию и оптимизации.
Осуществление одной из этих идей позволит не задумываться над количеством включенных модулей. Т.е. сайты с 10 и 1000 включенных модулей будут работать одинаково быстро.
есть модуль 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 буду необычайно рад если тема все-таки будет развиваться и все бы хотели услышать ваши идеи! для них можно создать отдельную ветку чтобы не было каши
Ждем!
Рекомендую начать с pressflow, там уже много реализовано и по кешированию в частности
я проапдейтил свои проэкты до pressflow, но я не гуру и не вижу отличий в кешировании кроме функции внешнего кеширования, а так ничего нового не увидел. тестировал так же утилитой apache bench - практически нету разницы.
посоветуйте что-нибудь на тему: кеширование авторизированных пользователей. из опкод модулей на хостинге установлен xcache. модуль authcache 6.x-1.0-rc1 работает у меня только для анонимов, ломаю голову...
Вижу что прошел почти год с момента последнего сообщения в этой теме, и еще больше с того момента когда neochief выложил последнюю версию этого модуля.
А проблема до сих пор актуальна.
Вопрос - модуль жив, поддерживается?
Есть-ли он на d.org? я что-то не нашел.
И еще - за год-полтора друпаловский файл patch.inc теоретически мог поменяться (по факту я не знаю поменялся-ли он), так вот, данный файл, который идет в комплекте с этим модулем актуален-ли для последней версии друпала?
Все отлично теперь гуглится на орге.
Попробовал поставить - работает но только для одного языка.
Хотелось бы узнать как поживает данные модуль
1) Идет ли его доработка?
2) Есть ли стабильная версия для 6ки?
3) Есть ли у разработчиков желание его довести до ума?
Желание доработать есть.
Как только исправлю баги Mail.ru и Open Login, то сразу же допилю этот модуль и выложу на d.o
Посмотрел модуль. Проверил, работает на 6.19 как надо. Авторам респект!