Кэширование в шаред-меме

Sergey Skvortsov skv at protey.ru
Wed Oct 4 00:15:46 MSD 2006


On 03.10.2006 22:35, drmarker wrote:
>> 0. Использовать memcached. Самый быстрый и результативный
>> с точки зрения разработки вариант. В 1.2.0 появилось несколько
>> улучшений (в т.ч. listening на unix socket). Вкупе с правильно
>> используемым X-Accel-Redirect, memcached даёт прекрасные
>> результаты.
> 
> А расскажите кратенько про технологию? Все запросы к BE, тот проверяет
> кеш, в случае чего наполняет и дает internal redirect на нужную
> страницу? Или как-то элегантнее?

Да, примерно так.

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

Если ответ устаревает в момент отдачи запроса, то любой кэш попросту
вреден (два копирования вместо одного). Проще - отдать ответ по
tcp-connection обратно nginx'у.

Если один раз сгенерированный контент будет использоваться в среднем раз
5-100 (числа довольно произвольные) - то memcached весьма удобен,
особенно если он обслуживает несколько машин с backend'ами, и данные
берутся из БД.

Если же контент выдается как отчеты из БД за прошлые периоды (т.е.
полагаем что эти данные не изменяемые), и отчёты эти часто запрашиваются
- то имеет смысл генерировать отчёты загодя (или по факту) и хранить в
filesystem, откуда nginx отдаст их через sendfile(2) и т.д.

Вариантов слишком много, поскольку задачи-то нет.

>> 1. Если для backend'а с forked процессами - то OSSP mm
> 
> А что про Cache::FastMmap скажете?

Это собственно последний вариант с mmap+locking. Если ограничиваем
расмотрение только использованием внутри perl'а, то Cache::FastMmap -
самый быстрый, я его довольно долго использовал.

Безусловно, всё надо мерять benchmark'ами. Иногда вещи, быстрые в теории
- на практике жутко тормозят, и наоборот бывает - самая простая
реализация оказывается самой эффективной. Уж не говоря о том, что
усилия, затрачиваемые на premature optimization лучше направить на
обдумываение как сделать architecture redesign.

Скажем, вместо размышления о выборе кэша, можно просто сократить расходы
на передачу данных между демонами. Через тот же mmap добиться
zero-copying нетрудно (вся тонкость, как обычно, в синхронизации). Опять
же, реализация mmap'а на разных платформах существенно отличается по
всяким побочным эффектам.

> В его описании про IPC::MM пишут
> 
> IPC::MM - hash implementation is broken, data is not automatically
> expired, slow
> 
> да и IPC::MM - от 2000-го года.

Насчёт broken - не смотрел, но собственно написать свой XS-модуль - не
есть сверхсложная задача, если требуется универсальность mm(3).

-- 
Sergey Skvortsov
mailto: skv at protey.ru






More information about the nginx-ru mailing list