Я про Apache не говорил, в статье написано про Apache для WebDAV (внутренний доступ), а для отдачи контента там упоминались nginx и lighttpd.
Центральное хранилище — это полка с дисками от Dell. Вот в нём-то смысла и нет, т.к. доступ идёт к данным постоянно, это не архив, а бэкапить это чудо всё равно надо ;) Я просто хочу сказать, что полка — это круто, но, по моему мнению, для данной задачи не подходит. Можно из полок делать «статичный» бэкап, который никогда не используется для отдачи контента.
Я не очень понял, при чем тут кэширование и проксирование? Оно в данной схеме отсутствует вовсе, файловый сервер способен отдать контент самостоятельно, на скоростях (по опыту) до 600 Мбит/с, его стоимость низкая (относительно). А суммарная нагрузка распределена по отдельным серверам, имеет неограниченное масштабирование (в отличие от центрального хранилище).
А вот вероятность потери данных очень высокая в силу различных отказов как железа, так и софта. На практике отказ — 1 сервер за полгода-год, но этого вполне достаточно для больших потерь ;)
Я не админ, но эту проблему надо решать на системном уровне. Они не должны «мигать» в нормальной ситуации. Если это будет продолжаться, нормальной работы с memcached не получится.
Клиент memcached обычно обнаруживает самостоятельно и решает проблему сервера «в дауне», перераспределяя ключи. Он же через некоторый таймаут попробует включить сервер обратно в кластер (повторное подключение). Он же выдаст статистику. Он же расскажет, какие сервера работают.
Сервер memcached просто так в даун уходить не должен, это серьезные проблемы, если такая ситуация происходит «просто так».
Ну фактически то, что касается проблем с кэшированием, освещено в этой серии постов. И они в основном рассказывают о использовании memcached в highload-проектах. Думаю, проблем потенциальных гораздо больше, мне удалось лишь о части из них рассказать.
Вообще, это многослойный процесс может быть (и в самом фреймворке), просто на разных уровнях абстракции разное представление о кэше. На самый верхний уровень вылезают данные кэша, а при спуске вниз к ним дописываются тэги, время жизни и т. п.
Мне кажется, это всё-таки скорее относится к разработке в целом, чем в частности к memcached. Memcached — скорее инструмент, а подходы могут иметь более широкое применение.
Я совершенно согласен, долгие выборки должны делаться отдельно, по ним могут строиться вспомогательные таблицы или кэши в разных ситуациях.
Однако бывают иногда ситуации, когда в процессе работы БД запрос, который был раньше быстрым, становится «медленным», сама по себе это несмертельно может быть, но в сочетании с описанным эффектом может быть критично для функицонирования сервиса. Рассмотренный выше подход можно рассматривать как такой «ремень безопасности», который не позволяет ситуации выйти на критический уровень.
eAccelerator, как и любое другое локальное (по отношению к frontend) решение нельзя использоваться для «честной» блокировки, если frontendов больше одного, т. к. блокировка будет действовать на один frontend. В данном конкректном случае это может быть приемлемо, если frontendов мало, тогда вероятность одновременно несколькими мордами формировать кэш остается невысокой.
Модель можно придумать, как всегда вопрос упирается в эффективность и прочее. На самом деле, если бы обращения к memcached не были бы синхронными, можно было бы сделать асинхронную модель, когда генерация по сути идёт параллельно, и мы параллельно ждем выборок из memcached.
Моя мечта в этом плане — концпеция Deferred из Twisted, то, что я описываю, на опыте PHP, там, к сожалению, так не сделаешь.
А вообще более правильный уход от кэширования — это тот или иной Application Server, когда бы мы могли держать в памяти объекты, а не результаты выборок по их представлением в БД. Но это всё мечты в разных направлениях.
В суровой модели оптимизации кода вида БД+PHP+Memcached+что-то еще надо двигаться во всех направлениях, начиная от клиентской оптимизации заканчивая запросами из БД, кол-вом обращений в memcached, мониторингом серверов. Это такой бесконечный бой за производительность, причем memcached — далеко на самая большая проблема.
Как мониторить memcached? Я, если честно, не админ. Но это, имхо, тривиальная задача: берем любой язык программирования с клиентом Memcached, отправляем запрос статистики, получаем результат, нужные нам числа, отдаем их в мониторинг. Немного о сборе статистики будет в шестом посте, он будет опубликован в субботу.
Практическим примером могло бы быть выкладывание нашего frameworkа, но он большой, толстый, тесно связанный друг с другом, и вряд ли он был бы хорошим примером. Если будет большой интерес, можно было бы его зарефактирить, и отдельные компоненты выложить в open-soruce.
Если, конечно, к этому делу есть большой интерес.
Хотя, так или иначе, все описанные подходы реализованы описанным или похожим образом в различных framework'ах, но единого места я не знаю.
juks, я не спорю, что это можно сделать с помощью MySQL. Можно с помощью локальных файлов, можно с помощью еще чего-то. Например, если у меня одна морда, можно в shared memory хранить — будет куда проще и быстрее.
Но memcached выдержит гораздо большую нагрузку (чем MySQL), его API в данной ситуации даже проще, чем у БД. Memcached может быть полезен для проекта не только для счетчика онлайнеров, и здесь тоже его можно применить.
Согласен, что фраза «только на memcached» некорректна, будет правильнее написать «что достаточно эффективно» или «гораздо лучше, чем на MySQL».
Я бы сказал, что скорость стриминга должна еще зависеть от канала клиента.
Центральное хранилище — это полка с дисками от Dell. Вот в нём-то смысла и нет, т.к. доступ идёт к данным постоянно, это не архив, а бэкапить это чудо всё равно надо ;) Я просто хочу сказать, что полка — это круто, но, по моему мнению, для данной задачи не подходит. Можно из полок делать «статичный» бэкап, который никогда не используется для отдачи контента.
В случае падения сервера (информация мониторинга) нагрузка может быть сразу перенаправлена на сервер, где лежит бэкап.
А вот вероятность потери данных очень высокая в силу различных отказов как железа, так и софта. На практике отказ — 1 сервер за полгода-год, но этого вполне достаточно для больших потерь ;)
Я не админ, но эту проблему надо решать на системном уровне. Они не должны «мигать» в нормальной ситуации. Если это будет продолжаться, нормальной работы с memcached не получится.
Сервер memcached просто так в даун уходить не должен, это серьезные проблемы, если такая ситуация происходит «просто так».
Вообще, это многослойный процесс может быть (и в самом фреймворке), просто на разных уровнях абстракции разное представление о кэше. На самый верхний уровень вылезают данные кэша, а при спуске вниз к ним дописываются тэги, время жизни и т. п.
Однако бывают иногда ситуации, когда в процессе работы БД запрос, который был раньше быстрым, становится «медленным», сама по себе это несмертельно может быть, но в сочетании с описанным эффектом может быть критично для функицонирования сервиса. Рассмотренный выше подход можно рассматривать как такой «ремень безопасности», который не позволяет ситуации выйти на критический уровень.
Моя мечта в этом плане — концпеция Deferred из Twisted, то, что я описываю, на опыте PHP, там, к сожалению, так не сделаешь.
А вообще более правильный уход от кэширования — это тот или иной Application Server, когда бы мы могли держать в памяти объекты, а не результаты выборок по их представлением в БД. Но это всё мечты в разных направлениях.
В суровой модели оптимизации кода вида БД+PHP+Memcached+что-то еще надо двигаться во всех направлениях, начиная от клиентской оптимизации заканчивая запросами из БД, кол-вом обращений в memcached, мониторингом серверов. Это такой бесконечный бой за производительность, причем memcached — далеко на самая большая проблема.
Или я не понял процесса?
Если, конечно, к этому делу есть большой интерес.
Хотя, так или иначе, все описанные подходы реализованы описанным или похожим образом в различных framework'ах, но единого места я не знаю.
Но memcached выдержит гораздо большую нагрузку (чем MySQL), его API в данной ситуации даже проще, чем у БД. Memcached может быть полезен для проекта не только для счетчика онлайнеров, и здесь тоже его можно применить.
Согласен, что фраза «только на memcached» некорректна, будет правильнее написать «что достаточно эффективно» или «гораздо лучше, чем на MySQL».