* обработчиком для второго локейшена может быть маленький и, по возможности, быстрый модуль nginx на перле (ngx_http_perl_module), чтобы не проваливаться в медленный бекенд. Быстро сходили в мемкеш, сгенерировали ответ и сразу отпустили процесс nginx.
Это можно сделать проще, используя две особенности nginx.
Первая: закрываем прямой доступ к локейшену (/images/*) с помощью директивы internal.
Вторая: с другого локейшена (/{{ SECRET }}/images/*) возвращаем ответ c заголовком X-Accel-Redirect в котором указываем путь к первому локейшену — это отменяет ограничение, заданное директивой internal и nginx проксирует нужную нам картинку.
Более подробно можно гуглить по ключевым словам «X-Accel-Redirect internal».
Вверху страницы делается одна ssi-вставка типа /usersettings/, которая кешируется по сессионной куке uid.
Эта вставка выдет список из set var с id постов (последних N постов) юзера (и любых других его данных).
Ниже, при выводе списка для каждого поста с помошью ssi if проверяем существование переменной с id поста среди списка постов юзера. Внутри каждого if — кнопка.
И не забываем про internal для локейшена /usersettings/ и параметр wait для его вставки.
Еще можно для него указать таймаут в несколько секунд, чтобы все хоть как-то работало, когда база сдохнет.
Предположим, что у вас крутой фотохостинг со средним числом аплоадов = 100 в секунду.
После аплоада картинка ресайзится один раз, чтоб показаться залившему ее автору автору и попадает в дисковый кеш фронтенда.
Получается в среднем на бекенде стораджа выделяется 100 x 2Мб = аж 200 Мб ОЗУ.
Ужасная цифра для фотохостинга :)
Далее:
При таких параметрах у нас на диск сваливается 8 640 000 картинок в сутки, 3 153 600 000 картинок в год.
6 307 200 000 Мб в год только на оригиналы.
Даже если все необходимые превьюшки весят 20% от оригинала, все равно получается недешевый у нас мусорник.
Преимущества этого способа:
— Дизайнер при разработке дизайна сайта не ограничен в размерах превьюшек, а также от используемого движка или лени разрботчиков.
— При редизайне не надо перегенерять в новые размеры все существующие картинки, большая часть из которых к тому же больше никогда не будет запрошена.
— В основном сторадже хранятся только оригиналы, это удобно и эффективно (кеш превьюшек лучше выносить на отдельное железо, а если все сурово — даже на кластер)
— Очень простой код приложения, нужно только уметь сохранять файлы при заливке и генерить разные урлы при отдаче.
— В случаях, когда исходные картинки вообще не хранятся на сервере (аггрегаторы, поисковики, партнерские блоки от тормозных источников) это лучший вариант.
— У редкого разработчика самописный ресайзер будет эффективней написанного автором nginx :)
Прегенерация до выдачи клиенту (если сильно хочется, хотя необходимости не вижу) тоже не проблема — достаточно в админке после сабмита картинки рисовать ее же в нужных размерах — они отресайзятся и попадут в кеш.
Nginx не выполняет сам скрипты, он только проксирует запросы к бекенду по какому-нибудь протоколу, типа HTTP или FastCGI. Задача спаунера — запуск (spawn) параллельных процессов, обрабатывающих эти запросы.
Обычно спаунер — это простая библиотека на том же языке, что и бекенд (у нее в названии обычно упоминается протокол), и весь его интеллект заключается в нафоркивании при запуске заданного количества чайлдов и периодического их пристреливания с форканием новых.
Это хорошо только в простейшем случае — когда все ресурсы сервера отданы одному проекту — можно запустить 100 процессов и пусть работают себе. Но когда на сервере одновременно крутятся десятки проектов с недетерминированной нагрузкой, то становится крайне важным грамотное распределение ресурсов между ними.
В апаче для этого есть штука под названием worker. Принцип ее работы — тема отдельной книги. Можете погуглить что-то типа apache mpm prefork.
У lighttpd, есть свой собственный spawn-fcgi и многие используют его, даже без самого lighttpd.
Мемкеш гоняет данные по сети (loopback тоже сеть и тоже ест CPU ПЭВМ), а значит есть накладные расходы.
Nginx отдает статику из локальной fs. А часто отдаваемые данные из fs вообще попадают в active область памяти и отдаются так быстро, что слышно свист.
Истина посередине: кешировать в бекенде (php, perl, python) тяжело доставаемые данные мемкешем, например, на «минуты», а уже фронтендом (nginx) кешировать всю выдачу бекенда на «секунды».
Это решает вопрос смены имени юзера:
— инвалидация кеша мемкеша проще реализуется на уровне бизнес-логики (php,perl,python)
— бекенд (php, perl, python) делает трудоемкие вычисления для этого юзера всего раз в «минуты» (но при смене имени кеш дропается мгновенно)
— фронтенд (nginx) сделает из 100 запросов в «секунды» всего один-единственный инвалидирующий запрос к бекенду
Я, конечно, не разбираюсь в математике и компюторах, но кажется последние два пункта говорят о снижении нагрузки на два порядка.
Первая: закрываем прямой доступ к локейшену (/images/*) с помощью директивы internal.
Вторая: с другого локейшена (/{{ SECRET }}/images/*) возвращаем ответ c заголовком X-Accel-Redirect в котором указываем путь к первому локейшену — это отменяет ограничение, заданное директивой internal и nginx проксирует нужную нам картинку.
Более подробно можно гуглить по ключевым словам «X-Accel-Redirect internal».
Эта вставка выдет список из set var с id постов (последних N постов) юзера (и любых других его данных).
Ниже, при выводе списка для каждого поста с помошью ssi if проверяем существование переменной с id поста среди списка постов юзера. Внутри каждого if — кнопка.
И не забываем про internal для локейшена /usersettings/ и параметр wait для его вставки.
Еще можно для него указать таймаут в несколько секунд, чтобы все хоть как-то работало, когда база сдохнет.
Нужно ставить www.google.com/chrome/intl/en/eula_dev.html?dl=mac
Должно быть 4.0.302.2 dev.
dev.chromium.org/getting-involved/dev-channel
От валяющегося сайта больший ущерб, я считаю )
Ну, то есть шейпинг, а не шардинг, конечно — понапридумывали слов, а нам вот мучайся.
После аплоада картинка ресайзится один раз, чтоб показаться залившему ее автору автору и попадает в дисковый кеш фронтенда.
Получается в среднем на бекенде стораджа выделяется 100 x 2Мб = аж 200 Мб ОЗУ.
Ужасная цифра для фотохостинга :)
Далее:
При таких параметрах у нас на диск сваливается 8 640 000 картинок в сутки, 3 153 600 000 картинок в год.
6 307 200 000 Мб в год только на оригиналы.
Даже если все необходимые превьюшки весят 20% от оригинала, все равно получается недешевый у нас мусорник.
— Дизайнер при разработке дизайна сайта не ограничен в размерах превьюшек, а также от используемого движка или лени разрботчиков.
— При редизайне не надо перегенерять в новые размеры все существующие картинки, большая часть из которых к тому же больше никогда не будет запрошена.
— В основном сторадже хранятся только оригиналы, это удобно и эффективно (кеш превьюшек лучше выносить на отдельное железо, а если все сурово — даже на кластер)
— Очень простой код приложения, нужно только уметь сохранять файлы при заливке и генерить разные урлы при отдаче.
— В случаях, когда исходные картинки вообще не хранятся на сервере (аггрегаторы, поисковики, партнерские блоки от тормозных источников) это лучший вариант.
— У редкого разработчика самописный ресайзер будет эффективней написанного автором nginx :)
Прегенерация до выдачи клиенту (если сильно хочется, хотя необходимости не вижу) тоже не проблема — достаточно в админке после сабмита картинки рисовать ее же в нужных размерах — они отресайзятся и попадут в кеш.
Обычно спаунер — это простая библиотека на том же языке, что и бекенд (у нее в названии обычно упоминается протокол), и весь его интеллект заключается в нафоркивании при запуске заданного количества чайлдов и периодического их пристреливания с форканием новых.
Это хорошо только в простейшем случае — когда все ресурсы сервера отданы одному проекту — можно запустить 100 процессов и пусть работают себе. Но когда на сервере одновременно крутятся десятки проектов с недетерминированной нагрузкой, то становится крайне важным грамотное распределение ресурсов между ними.
В апаче для этого есть штука под названием worker. Принцип ее работы — тема отдельной книги. Можете погуглить что-то типа apache mpm prefork.
У lighttpd, есть свой собственный spawn-fcgi и многие используют его, даже без самого lighttpd.
Мемкеш гоняет данные по сети (loopback тоже сеть и тоже ест CPU ПЭВМ), а значит есть накладные расходы.
Nginx отдает статику из локальной fs. А часто отдаваемые данные из fs вообще попадают в active область памяти и отдаются так быстро, что слышно свист.
Истина посередине: кешировать в бекенде (php, perl, python) тяжело доставаемые данные мемкешем, например, на «минуты», а уже фронтендом (nginx) кешировать всю выдачу бекенда на «секунды».
Это решает вопрос смены имени юзера:
— инвалидация кеша мемкеша проще реализуется на уровне бизнес-логики (php,perl,python)
— бекенд (php, perl, python) делает трудоемкие вычисления для этого юзера всего раз в «минуты» (но при смене имени кеш дропается мгновенно)
— фронтенд (nginx) сделает из 100 запросов в «секунды» всего один-единственный инвалидирующий запрос к бекенду
Я, конечно, не разбираюсь в математике и компюторах, но кажется последние два пункта говорят о снижении нагрузки на два порядка.