На хабре недавно была опубликована статья под названием "Кэширование на Drupal". Хотелось бы добавить несколько соображений по теме.
Ни для кого не секрет, что Drupal голоден до ресурсов, а кэширование это чуть ли не первое что приходит в голову. Расскажу как выстроена общая схема кэширования на нашем сайте.
Первая линия обороны — мы используем CDN (Content Delivery Network), в нашем случае это AKAMAI. AKAMAI настроен на кэширование всего. Картинки, CSS, JavaScript, ответы на все GET запросы, все это кешируется в не зависимости от того аноним пользователь или зарегистрирован. Интервал кэширования от 1 до 5 минут для страниц, 45 минут для CSS и JavaScript, и час для остальных ресурсов. Такое распределение позволяет существенно уменьшить нагрузку на сервера.
Лирическое отступление, для тех кто не имеет опыта работы с CDN. Грубо говоря, все запросы произведенные по адресу сайта, сначала попадают на сервера CDN, при условии, что запрошенная страница существует в кэше CDN, ответ сразу направляется запрашивающему клиенту с сервера CDN. В случае когда ресурс еще не закэширован в CDN, или время кэширования истекло, CDN направляет запрос на наш сервер, кэширует ответ, и выдает его пользователю. В связи с такой схемой возникает несколько проблем, которые впрочем достаточно легко решаемы.
Рассмотрим проблемы по порядку. Проблема номер один, связанна с тем, что в Drupal'е формы снабжены form-token'ами которые Drupal использует в целях безопасности. Решается проблема двумя способами, более безопасный (но увеличивающий нагрузку на сервер), и более кэшируемый способ. Более безопасным является AJAX запрос самой формы, после того как страница отобразилась. Фишка в том что CDN отдаст страницу со своих серверов, а вот AJAX запрос (это должен быть POST, GET'ы кешируются) на свой сервер сгенерирует форму, которую мы потом впишем в нужное место по средством JS. Проблема с form-token'ом решена, так как Drupal генерирует форму, и знает правильное значение ее токена. При таком подходе мы гарантированно имеем один запрос на наш сервер. Что в принципе не страшно, однако, что делать когда даже этот один запрос сильно портит жизнь? Ответ — пожертвовать безопасностью, просто убрав form-token обыкновенным unset'om. Вуаля, можно кешировать форму вместе со страницей в CDN. Хотелось бы напомнить, что перед тем как идти вторым путем, хорошенько взвесьте — а так ли вам облегчит жизнь этот один запрос, или его отсутствие? Пример ситуации когда этот один запрос может сыграть с вами злую шутку — ваш сайт оказался на первой странице yahoo.com с прямым линком обратно на ваш материал (20000+ пользователей одновременно на вашем сайте в течении нескольких часов). Кстати, этим методом можно пользоваться по необходимости, вовсе не обязательно делать это «постоянным решением».
Проблема номер два, связанна с тем что кэширование комментариев чревато возмущенными пользователями которые будут писать письма с содержанием на-вроде «Я тут коммент оставил, где он?!». Решения опять же два: AJAX запрос за свежими комментариями при каждой загрузке страницы, или добавление cache buster параметра к адресу по которому вы возвращаете пользователя на страницу с комментарием (что-то вроде www.spin.com/articles/premiere-crystal-method-remix-daft-punks-tron?cb=cdninvalidate#comment-85251). Параметр cb=cdninvalidate настраивается в CDN, и дает знать CDN что время кэширования страницы истекло. Таким образом, пользователь который только что оставил комментарий обновит кэш для всех остальных (ведь CDN отправит запрос на наши сервера, и закэширует новую версию с новым комментарием).
Третья проблема решается совсем просто: редакторскому составу выделяется отдельный subdomain, например edit.mysite.com который не кэшируется CDN'ом.
CDN не панацея, и следующий этап кэширования о котором хотелось бы сказать пару слов, это кэширование на своих серверах. Дело в том, что несмотря на то, что CDN существенно снижает нагрузки на сервера, при большом единовременном наплыве посетителей, одного CDN'a недостаточно. На наших серверах установлен memcache, APC, включено родное Drupal'овское кэширование. Особое внимание стоит уделить кэшированию блоков, это позволит еще больше облегчить работу вашим серверам.
Кроме всего выше сказанного, не забывайте о простых вещах:
— Старайтесь минимизировать число запросов к вашим серверам.
— Объединяйте, где возможно, картинки в CSS sprites.
— Продумывайте расположение JavaScriptьa в вашем коде.
— Рекламу, и прочие штучки, которые требуют ответа от сторонних серверов, энкапсулируйте в AJAX или iFrame.
— Не кормите PHP лишней памятью, пользуйтесь, например php-fpm.
— Следите за вашими MySQL логами, и оптимизируйте долго исполняемые запросы.
— Рассмотрите возможность чтения из двух баз данных при высоких нагрузках на сайт.
Вот пожалуй и все, что мне хотелось добавить к теме кэширования и скорости Drupal сегодня. Спасибо!
Ни для кого не секрет, что Drupal голоден до ресурсов, а кэширование это чуть ли не первое что приходит в голову. Расскажу как выстроена общая схема кэширования на нашем сайте.
Первая линия обороны — мы используем CDN (Content Delivery Network), в нашем случае это AKAMAI. AKAMAI настроен на кэширование всего. Картинки, CSS, JavaScript, ответы на все GET запросы, все это кешируется в не зависимости от того аноним пользователь или зарегистрирован. Интервал кэширования от 1 до 5 минут для страниц, 45 минут для CSS и JavaScript, и час для остальных ресурсов. Такое распределение позволяет существенно уменьшить нагрузку на сервера.
Лирическое отступление, для тех кто не имеет опыта работы с CDN. Грубо говоря, все запросы произведенные по адресу сайта, сначала попадают на сервера CDN, при условии, что запрошенная страница существует в кэше CDN, ответ сразу направляется запрашивающему клиенту с сервера CDN. В случае когда ресурс еще не закэширован в CDN, или время кэширования истекло, CDN направляет запрос на наш сервер, кэширует ответ, и выдает его пользователю. В связи с такой схемой возникает несколько проблем, которые впрочем достаточно легко решаемы.
- Как кэшировать формы (например формы комментариев)?
- Как кэшировать комментарии?
- Как редактировать контент?
Рассмотрим проблемы по порядку. Проблема номер один, связанна с тем, что в Drupal'е формы снабжены form-token'ами которые Drupal использует в целях безопасности. Решается проблема двумя способами, более безопасный (но увеличивающий нагрузку на сервер), и более кэшируемый способ. Более безопасным является AJAX запрос самой формы, после того как страница отобразилась. Фишка в том что CDN отдаст страницу со своих серверов, а вот AJAX запрос (это должен быть POST, GET'ы кешируются) на свой сервер сгенерирует форму, которую мы потом впишем в нужное место по средством JS. Проблема с form-token'ом решена, так как Drupal генерирует форму, и знает правильное значение ее токена. При таком подходе мы гарантированно имеем один запрос на наш сервер. Что в принципе не страшно, однако, что делать когда даже этот один запрос сильно портит жизнь? Ответ — пожертвовать безопасностью, просто убрав form-token обыкновенным unset'om. Вуаля, можно кешировать форму вместе со страницей в CDN. Хотелось бы напомнить, что перед тем как идти вторым путем, хорошенько взвесьте — а так ли вам облегчит жизнь этот один запрос, или его отсутствие? Пример ситуации когда этот один запрос может сыграть с вами злую шутку — ваш сайт оказался на первой странице yahoo.com с прямым линком обратно на ваш материал (20000+ пользователей одновременно на вашем сайте в течении нескольких часов). Кстати, этим методом можно пользоваться по необходимости, вовсе не обязательно делать это «постоянным решением».
Проблема номер два, связанна с тем что кэширование комментариев чревато возмущенными пользователями которые будут писать письма с содержанием на-вроде «Я тут коммент оставил, где он?!». Решения опять же два: AJAX запрос за свежими комментариями при каждой загрузке страницы, или добавление cache buster параметра к адресу по которому вы возвращаете пользователя на страницу с комментарием (что-то вроде www.spin.com/articles/premiere-crystal-method-remix-daft-punks-tron?cb=cdninvalidate#comment-85251). Параметр cb=cdninvalidate настраивается в CDN, и дает знать CDN что время кэширования страницы истекло. Таким образом, пользователь который только что оставил комментарий обновит кэш для всех остальных (ведь CDN отправит запрос на наши сервера, и закэширует новую версию с новым комментарием).
Третья проблема решается совсем просто: редакторскому составу выделяется отдельный subdomain, например edit.mysite.com который не кэшируется CDN'ом.
CDN не панацея, и следующий этап кэширования о котором хотелось бы сказать пару слов, это кэширование на своих серверах. Дело в том, что несмотря на то, что CDN существенно снижает нагрузки на сервера, при большом единовременном наплыве посетителей, одного CDN'a недостаточно. На наших серверах установлен memcache, APC, включено родное Drupal'овское кэширование. Особое внимание стоит уделить кэшированию блоков, это позволит еще больше облегчить работу вашим серверам.
Кроме всего выше сказанного, не забывайте о простых вещах:
— Старайтесь минимизировать число запросов к вашим серверам.
— Объединяйте, где возможно, картинки в CSS sprites.
— Продумывайте расположение JavaScriptьa в вашем коде.
— Рекламу, и прочие штучки, которые требуют ответа от сторонних серверов, энкапсулируйте в AJAX или iFrame.
— Не кормите PHP лишней памятью, пользуйтесь, например php-fpm.
— Следите за вашими MySQL логами, и оптимизируйте долго исполняемые запросы.
— Рассмотрите возможность чтения из двух баз данных при высоких нагрузках на сайт.
Вот пожалуй и все, что мне хотелось добавить к теме кэширования и скорости Drupal сегодня. Спасибо!