- PVSM.RU - https://www.pvsm.ru -
Бесплатная CMS это всегда компромисс, компромисс между целым рядом очевидных факторов, перечислять которые в рамках данного ресурса смысла пожалуй нет, т.к. они всем давно известны. Безусловно, среди всего разнообразия бесплатных СМS можно выделить некоторые, которые будут лучше или хуже в каких-то отдельных номинациях, вроде скорости работы, простоты освоения новичком и т.п. Но в данной статье речь не об этом. Я просто хочу поделиться опытом успешного решения проблемы скорости генерации страниц в Joomla с помощью кеширования. Причём кеширования очень радикального, на «уровне» index.php.
Хочу сразу отметить, что сие повествование не является каким-то принципиальным новшеством, и я не претендую на какие-либо лавры. Надеюсь, моё решение поможет хотя бы кому-то продлить «малой кровью» жизнь старого проекта на Joomla.
Сразу хочу упредить критику в свой адрес и прошу некоторой снисходительности. Дело в том, что я не являюсь профессиональным программером ни в каком виде. Я технический директор маленькой типографии. Все мои старания в области программирования это всего лишь попытки снизить затраты на IT в компании.
Как мне кажется, достаточно типичной (во всяком случае, в среде программистов-любителей, к коим я себя причисляю) является следующая ситуация. В своё время, начав писать для себя сайт, я выбрал Joomla, т.к. это было очевидное, хоть и не очень дальновидное, решение. Со временем, я столкнулся с некоторыми ограничениями Joomla, одним из которых стало время генерации страниц.
Для тех, кто в теме, наверное не секрет, что из-за загрузки тяжеловесного фреймворка, плагинов и модулей, ну и как плата за универсальность CMS в целом, типовое время генерации страницы может составлять порядка 1-2 секунд. Использование более мощного железа проблему особо не решает, т.к. если на один запрос CMS делает несколько десятков (а то и под сотню) обращений к БД, потребуется увеличение производительности железа (и всех его компонентов) на порядок, что очень дорого, мягко говоря.
Надо сказать, что сама joomla 1.5 тоже что-то умеет в плане кеширования. К своему стыду, уже точно не помню что, т.к. давно в это вникал. Но точно помню, что толку от этого кеширования практически нет.
Первой попыткой оптимизации и ускорения было написание костыля для кеширования компонента Joomla Virtuemart. Virtuemart это известный (можно сказать «классика жанра») компонент интернет-магазина для Joomla. Конечно же, можно много нелестных слов о нём сказать и прочитать, т.к. он имеет массу недостатков, продиктованных целым рядом причин, начиная от почтенного возраста, отсутствия всяких там рефакторингов, заканчивая открытостью и универсальностью, которые, как правило, ходят рядом с громоздкостью. Тем не менее, он (Virtuemart) есть, работает, и для многих является простой точкой входа в «мир электронного бизнеса», если так можно выразиться. Да и вообще, я хотел бы сделать акцент не на том, как «правильно готовить» Joomla, какие и как компоненты использовать. Наоборот, я хотел бы поделиться рецептом, что делать, если она уже приготовлена неправильно. Решение, которое можно кратко охарактеризовать как «Ничего не трогай, ничего не меняй, только сделай быстрее, чтобы работало быстрее!»
В моём случае Virtuemart используется в режиме каталога, что несколько упростило задачу написания костыля кеширования. Описывать, как я это делал смысла нет, т.к. полученный прирост существенного влияния на скорость загрузки не оказал. Ведь у меня в Joomla есть ещё компоненты, любящие ресурсы, например JoomFish. Кроме того, чтобы Virtuemart отдал свой кеш, всёравно нужно загрузить весь фреймворк Joomla, что само по себе требует времени.
Я начал искать решение, как бы ещё ускорить загрузку. Ситуация усугублялась проблемами на виртуальном
Поразмыслив, пришёл к выводу, что никакая оптимизация joomla, по крайней мере в разумных приделах — после которой joomla останется joomla, не даст ускорения в разы, а именно эта цель стояла передо мной. Поэтому было решено рассмотреть вопрос написания фронтенда. Я сразу отбросил и не рассматривал варианты с готовыми решениями (даже не знаю есть ли они), т.к. не имел на это ни желания, ни времени. Кроме того, мой экземпляр joomla прилично допилен местами и типовые (типовые для Joomla) решения не факт, что заработали бы из коробки.
Что получилось в результате:
Рассмотрим реализацию
$fe_disalolwed_urls_array = array(
"/index"
);
.........................
if (fe_check_url($fe_disalolwed_urls_array,$fe_uri_cp1251)) {}
.........................
function fe_check_url($a, $i)
{
foreach ($a as $aa)
{
if (substr($i,0,strlen($aa)) == $aa)
{
return false;
}
}
return true;
}
Для этой оперции не требуется обращение к БД, всё происходит в файле index.php.
Если кеширование страницы запрещено, уходим на штатную генерацию страницы с загрузкой фремворка и т.д. и т.п.
Если находим такую куку, так же передаём управление «великой и ужасной» — пусть пробует по остальным зашифрованным кукам установить, кого она должна «вспомнить».
Для этой операции так же не требуется доступ к БД и файловой системе, мы всё ещё в index.php.
Обратите внимание, что это первое обращение к БД.
По результатам проверки, решаем что делать дальше. Если такой сесси нету (а так же в случае, если такая сессия есть и она не принадлежит зарегистрированному пользователю), переходим к следующему пункту, где будем определять возможность чтения страницы из кеша. В случае, если сессия принадлежит зарегистрированному пользователю, «уходим» на стандартную генерацию. В принципе в этом месте можно было бы «копать» дальше — кешировать страницы для авторизированных пользователей, но я в это углубляться не стал, т.к. специфика моего сайта такова, что ливьную долю посещений составляют незарегистрированные пользователи, при том, что размер фронтенда, который кешировал бы страницы зарегистрированных пользователей значительно возрос бы. Кроме того, на данный момент, мы переехали на новых
Так же, в случае если «отдаём кеш» и сессии с таким именем в joomla нету, важно добавить сессию в таблицу сессий joomla. Это нужно для обеспечения корректной работы самой joomla, если пользователь перейдёт из кешируемой в зоны в некешируемую, для работы AJAX-модулей и т.п. Кроме того, нужно выполнить обработку кеша на предмет динамических модулей перед отправкой клиенту, об этом ниже.
В этом месте есть ряд нюансов связанных с динамическими модулями.
В моём случае это следующие модули:
Для обеспечения их корректной работы, было сделано следующее:
Собственно на этом всё. В итоге я получил ускорение почти на порядок (почти в десять раз).
Результаты host-tracker [2]
Физически
Оценить скорость работы сайта можно на нём самом: link [3]
На картинке ниже — скрин из Google Webmasters Tools
Всплеск в феврале вызван одной проблемкой, для решения которой мне приходилось на протяжении всего месяца раз в 2-3 дня удалять весь кеш фронтенда. Но сама эта проблема, к фронтенду отношения не имела.
Очищается кеш фронтенда из админки joomla, для этого ничего не пришлось делать, кроме как сложить сам кеш в папочку /cache/FrontEnd — joomla сама его увидела и предоставила возможность очищать…
PS: уверен, что такой подход может быть применён не только в рамках Joomla 1.5 и не только в рамках Joomla. Конечно это потребует некоторых навыков, но, в то же время, это может расширить область применения простых в изучении бесплатных CMS.
Спасибо за внимание.
Автор: dtgeorge
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/keshirovanie/2785
Ссылки в тексте:
[1] хостинге: https://www.reg.ru/?rlink=reflink-717
[2] Результаты host-tracker: http://host-tracker.com/check_res_ajx/9898030-0/
[3] link: http://www.fastprint.ua/
Нажмите здесь для печати.