Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

Наши друзья и партнеры

UnixForum
купить дешевый 
компьютер родом из Dhgate.com




Библиотека сайта rus-linux.net

Фреймворк Zotonic

Глава 9 из книги "Производительность приложений с открытым исходным кодом".

Оригинал: Zotonic
Авторы: Arjan Scherpenisse и Marc Worrell
Перевод: Н.Ромоданов

Решение проблемы: борьба с эффектом Slashdot

Большинство веб-сайтов живет в некоторых местах где-то в Интернете своей заурядной жизнью. То есть, до тех пор, пока какая-нибудь из их страниц не станет хитом первой страницы такого популярного сайта, как CNN, BBC или Yahoo. В этом случае трафик, поступающий на сайт, скорее всего, увеличится в самые короткие сроки до десятков, сотен или даже тысяч запросов страниц в секунду.

Такой внезапный всплеск запросов перегружает традиционный веб-сервер и делает его недоступным. Термин «эффект Slashdot» был назван по имени веб-сайта, с которого начался этот вид чрезмерных обращений. Хуже того, перегруженный сервер иногда очень трудно перезапустить. Во вновь запускаемом сервере пустая кэш-память, нет соединения с базой данных, часто не откомпилированы шаблоны и т.д.

Большинство анонимных посетителей запрашивает в одно и то же время примерно одинаковые страницы, что не должно перегружать сервер. Эта проблема легко решается с помощью кэширующего прокси-сервера, например, Varnish, который кэширует статическую копию страницы и только лишь проверяет наличие обновлений страницы.

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

Мы поняли, что большинство веб-сайтов имеют

  • только ограниченное количество очень популярным страниц,
  • длинный список гораздо менее популярных страниц и
  • много общих частей на всех страницах (меню, большая часть читаемых элементов, новости и т.д.).

и решили

  • с тем, чтобы для доступа к часто используемым данным не нужно было создавать соединение, кэшировать их в памяти,
  • и при рендеринге страниц веб-сайта использовать одни и те же шаблоны и подшаблоны для нескольких запросов и
  • спроектировать систему так, чтобы предотвращать ее перегрузку при запуске и перезапуске сервера.

Кэширование часто используемых данных

Зачем выбирать данные из внешнего источника (базы данных, кэшпамяти), когда с помощью другого запроса они уже были выбраны пару миллисекунд назад? Мы всегда кэшируем простые запросы к данным. В следующем разделе подробно обсуждается механизм кэширования.

Совместное использование шаблонов и подшаблонов при рендеринге страниц

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

Кэширование начинается с того, что мы называем функцией memo: когда происходит рендеринг шаблона и одному или нескольким процессам требуется выполнить один и тот же рендеринг, то более поздние процессы будут приостановлены. Когда рендеринг будет выполнен, всем ожидающим процессам будет отправлен результат рендеринга.

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

Предотвращение перегрузки при запуске или перезапуске сервера

В Zotonic есть несколько специальных ограничений. С помощью них ограничивается доступ к процессам, в которых используются ограниченные ресурсы или выполнение которых является дорогостоящим (в терминах использования процессора и памяти). В настоящее время ограничения настраиваются для компилятора шаблонов, процесса изменения размеров изображений и для пула соединений с базой данных.

Эти ограничения реализованы при помощи ограничивающего рабочего пула, выполняемого запрашиваемое действие. При интенсивной работе процессора или диска, например, при изменении размера изображения, имеется только один процесс, обрабатывающий запросы. Запрашивающие процессы размещают свои запросы в очередь запросов процесса языка Erlang и ожидают до тех пор, пока их запрос не будет обработан. Если наступит таймаут, запрос обрабатываться не будет. Такой невыполненный запрос вернет статус HTTP 503 Service not available (сервис недоступен).

Ожидающим процессам не требуется много ресурсов и механизм ограничений защищает от перегрузки в случае, если изменен шаблон или если заменено изображение, находящееся на странице «горячих» новостей, и его требуется его обрезать или изменить его размер.

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

Пул соединений с базой данных

Еще немного о соединениях с базой данных. В Zotonic процесс для каждого отдельного запроса или транзакции получает соединение с базой данных из пула соединений. Это позволяет многим параллельно работающим процесса одновременно пользоваться очень ограниченным количеством соединений с базой данных. Сравните с большинством систем (PHP), где каждый запрос удерживает соединение с базой данных на протяжении всего запроса.

Zotonic по истечении некоторого времени закрывает неиспользуемые соединения с базой данных в случае, если оно не используется. Одно соединение всегда остается открытым, поэтому система всегда может быстро обработать входящий запрос или выполнить фоновое действие. Для большинства веб-сайтов Zotonic динамический пул соединений резко снижает до одного или двух количество открытых соединений с базой данных.


Продолжение статьи: Слои кэширования.


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

Комментарии отсутствуют