Хочу лучшие примеры кратких учебников по любым фреймворкам.

>Это по Вашим сайтам или глобальная статистика? Если глобальная, то где ее можно посмотреть?

Это по моим сайтам. Гугль и Яндекс - имеется в виду их статистика по отказам при обращении к страницам.

>Если не секрет, какая пиковая дневная посещаемость?

Где-то до 700-1000 посетителей в пике.

Покупать более дорогой сервер с большим количеством памяти/быстрым процессором было лень, я решил проблему путем патча пхп.

Пока у меня были тормозные сервера, я тупо почти всё перевёл на статику. Древний 2xXeon-1800 с 2,5Гб памяти на указанной нагрузке едва ли процентов на 30-40 загружался.

...

Сейчас проапгрейдился так, что статику всюду поотключал, и без того загрузка маленькая. Но если что - всегда можно будет снова включить :)

> В принципе, первое тоже возможно, только придется писать свое расширение PHP для начальной подгрузки всех требуемых классов на стадии MODULE INIT. Либо Zend-расширение, которое сохраняет классы после первой их компиляции.

Что либо готове из этого имеется? Что за расширение?

> Что за расширение?

Я писал подобное для WordPress (PHP-расширение, не Zend), поэтому знаю, что это возможно. Но увы, код выложить не могу, ибо NDA :-( В любом случае, подобное расширение будет писаться под конкретный проект, и вряд ли получится создать что-то обобщенное.

> Это как? Наборы FastCGI-серверов не зависят от наборов web-серверов и СУБД. Сдохнет один пул — останется другой, не вижу проблемы.

По отдельности то они жить будут, а работать не смогут, я про это.

Почему не знает? ... Ну или самый простой вариант — сессию можно хранить в БД.

См. выше про отказ СУБД (как и любого промежуточного хранилища без репликации)

сессия пользователя за это время истечет.

реплей должен быть на момент поста, т.е. если юзер отправил сообщение в 8 утра, а процессить начали в 7 вечера, то вместе с заморозкой запросов морозим все окружение, включая сессии и даже время запросов, как результат - сообщение будет датировано 8 утра.

Но: мне не совсем понятно, как это делать без взаимодействия с пользователем. Например, если сессия истекла, и пользователь должен авторизоваться. Как сообщить об этом пользователю, если такая досылка запросов осуществляется где-то в фоне?

Точно также, как э то происходит в десктопном софте: создается систрей (область уведомлений на сайте), приложения добавляют туда свои объекты и модифицируют статусы по мере надобности. Кстате, эта штука будет много где полезна, можно хоть видео в фоне процессить, хоть большие картинки без проблем ресайзить. Получил запрос, сказал юзеру «извините, произошел таймаут, смотрите статус в шапке сайту»

> реплей должен быть на момент поста, т.е. если юзер отправил сообщение в 8 утра, а процессить начали в 7 вечера, то вместе с заморозкой запросов морозим все окружение, включая сессии

Это далеко не всегда реально — web-сервер отдельно, fastcgi отдельно. Сессия живет не на стороне веб-сервера, а на стороне бэкэнда. И сессии вообще могут кроном чиститься (как в случае пыха и делается). Получается, что нужно делать полный снимок состояния, но это трудноосуществимо.

По отдельности то они жить будут, а работать не смогут, я про это.

Если всеми силами избавляемся от SPoF, то настраиваем репликацию. А вообще поднимаем monit и сводим даунтайм к минимуму.

ЗЫ: база настраивается при разработке, максимальный объем потребляемой памяти рассчитывается по формуле (что позволяет исключить OOM — кстати, фцги люблю и из-за этого тоже). При использовании стабильных версий софта падение сервера БД — что-то очень малореальное. В любом случае, ставим monit и, если СУБД способна запуститься, то жить будет :-)

Точно также, как э то происходит в десктопном софте

Да, но вот если сессия истекла, то непонятно, к кому этот объект привязывать. Я не вижу нормального решения по сохранению/восстановлению состояния всей среды.

См. выше про отказ СУБД

Мы для этого используем разделяемую файловую систему + write-through caching на уровне приложения.

> Это далеко не всегда реально — web-сервер отдельно, fastcgi отдельно. Сессия живет не на стороне веб-сервера, а на стороне бэкэнда.

Ну и правильно, я тоже об этом.

И сессии вообще могут кроном чиститься (как в случае пыха и делается).

Если мы делаем устойчивую систему, то крон и отключить можно (по крайней мере в момент ахтунга - падение субд, ддос)

Получается, что нужно делать полный снимок состояния, но это трудноосуществимо.

А что надо то еще?

если СУБД способна запуститься, то жить будет :-)

Угу, с ответом по 30 секунд на страницу при больших нагрузках. А можно выставить флаг «ахтунг», сохранять данные, а странички показывать только из кеша.

Да, но вот если сессия истекла, то непонятно, к кому этот объект привязывать. Я не вижу нормального решения по сохранению/восстановлению состояния всей среды.

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

http://www.swa.hpi.uni-potsdam.de/seaside/tutorial

Мне этот особенно нравится. Практичный, разобраные основные концепты - сессии, ORM, ajax, даже метадескрипторы.

> А можно выставить флаг «ахтунг», сохранять данные, а странички показывать только из кеша.

Можно, но к web-серверу это уже не относится.

Ну зачем все в сессию пихать, это скорее к юзерскому аккаунту прикручивать.

И как это будем делать, если мы говорим об отложенной отправке запроса? Бэкэнд умер, мы сохранили запрос на неопределенное время. Через пару часов повторяем запрос, сессия умерла. К кому привязываем данные?

Если мы делаем устойчивую систему, то крон и отключить можно

И пых патчить придется, ибо он тоже старые сессии грохает. Я не об этом. Как веб-серверу сохранять полное состояние окружения, чтобы была возможность повторной отправки отложенного по техническим причинам запроса?

> > А можно выставить флаг «ахтунг», сохранять данные, а странички показывать только из кеша.

Можно, но к web-серверу это уже не относится.

А к кому же? Вебсервер должен где-то контент брать, где если не из кеша в том числе? Если бекэнд отвалился, то кто же будет выставлять флаг «ахтуг, мне спрашивать некого», кто будет сохранять запросы?

Через пару часов повторяем запрос, сессия умерла. К кому привязываем данные?

Сессия не умерла, я же выше написал - все это фризится.

Как веб-серверу сохранять полное состояние окружения, чтобы была возможность повторной отправки отложенного по техническим причинам запроса?

А вот так и сохранять, в виде полного дампа запроса от пользователя (включая все http-заголовки), имени пользователя http-авторизации и всего того, что пренадлежит этому пользователю.

Вообще надо сказать, что я немного увлекся в разговоре и уже описываю несовсем похапе и его типичное окружение. Я считаю, что сервер сам должен вести сессии пользователя, сам должен уметь рестартить fcgi-сервисы, сам лазить в кеш, сам бороться с типичными проблемами обработки данных. Все это было, есть и переодически это опять изобретают. Это и всеми забытая хттп-авторизация, это и нативные функции проксирования и управления кешем, опять таки описанные в спецификации протокола хттп, это даже обработка форм (привет нгинксу и его модулю аплоада) и сессионнось (mod_usertrack), сборка страниц средствами сервера (привет из эпохи SSI) и генерация графики (опять привет нгинксу). Просто потом пришли похапешники и все изгадили, а теперь на хабре изобретают мегаинновации вроде «уникальная возможность, храним части страниц в мемкешде». А ничего изобретать не надо, в оригинальном rfc2616 есть почти все нужное, но никем не используемое. Вот у меня мысли по поводу написания своего вебсервера появляются