Отказоустойчивые приложения / приложения-конструкторы

[zerkms]

Отказоустойчивые приложения / приложения-конструкторы

Посмотрел презентацию http://www.slideshare.net/vitlic/yandex-lego-oleg-obolensky, потом увидел, что вконтакте отвалились комментарии со стены... пришёл ко мнению, что нужно этот пробел знаний подтянуть.

Господа, какие есть лучшие практики для реализации таких вещей в пхп?
Подробнее на примере контакта: отвалился сервис, обрабатывающий стену - всё, сообщений стены просто нет, функционал отправки отправляет вникуда, НО, само приложение "вконтакте" живое. + в презентации аналогичные примеры.

обсуждение в аськах привело к таким вот решениям:

try{
 _$count = $helper->overallItemsCount();
} catch(listItemRepositoryException $e) {
 _$count = 0;
}

а как это делается "обычно"?

 

[fixxxer]

если юнит жизненно важен, вводится избыточность.

если что-то отвалилось, делается плавная деградация. либо вот так, как ты указал, либо условно $count = NULL и просто убирается соответствующий блок из вьюхи, типа нету такой фичи.

а если говорить про "обычно" - обычно не делается вообще никак, тупо валится 500-я ))

 

[zerkms]

ну вот ещё из элегантных решений, кстати - ssi/ajax...

 

[Alexandre]

Посмотрел презентацию http://www.slideshare.net/vitlic/ya...oleg-obolensky, потом увидел, что вконтакте отвалились комментарии со стены... пришёл ко мнению, что нужно этот пробел знаний подтянуть

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

 

[MiksIr]

есть идея написать модуль сборщик-шаблонизатор для nginx

Кто слушал mailru-шный доклад о таком модуле на основе ctpp? Очень мне идея понравилась, однако больше ни слуху - ни духу, а потом уже ctpp 2 появился, а через год mailru о своем легком вебсервере взахлеб рассказывало =) Так что, думаю, тот проект похоронен =)

 

[fixxxer]

да вроде живой и развивается, автор в жжшном ру_хайлоад отписывается

или ты про модуль? ну там да, и вообще странно пихать потенциально блокирующую хрень в nginx. уж лучше подзапросы на отдельный демон.

а вообще если брать яндекс, то там куча сервисов которые отвечают xml-ями, а вьюха через xslt генерится. так что в случае таймаута сунуть заглушку <error /> и обработать это в xslt несложно

 

[MiksIr]

Я про модуль. У них было что-то аналогичное яндексу, только не такое глобальное (т.е. без rpc) и внутри json бегал. Мне интересно было бы, ибо XSLT не нравится.
Ну потенциально блокирующих вещей и без этого хватает, начиная с перла и заканчивая диском. А тут вот еще и тот же xslt появился. Блокировка то там на время отработки шаблона только будет, а учитывая что ctpp делает прекомпиляцию - должно летать.

 

[Alexandre]

Блокировка то там на время отработки шаблона только будет, а учитывая что ctpp делает прекомпиляцию - должно летать.

сегодня анонсировали доклад Шетухина на HiLoad++

или ты про модуль? ну там да, и вообще странно пихать потенциально блокирующую хрень в nginx. уж лучше подзапросы на отдельный демон

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

Кто слушал mailru-шный доклад о таком модуле на основе ctpp? Очень мне идея понравилась, однако больше ни слуху - ни духу

разве на основе ctpp? там же С++... хотя выызывать как либу - как вариант

а исходники открыты??? если есть - ссылку в студию.

 

[MiksIr]

Ну он про ctpp уже давно рассказывает, вряд ли что-то новое будет, хе =) ctpp тут http://ctpp.havoc.ru/
А про тот модуль я больше ничего не слышал

 

[Alexandre]

Ну он про ctpp уже давно рассказывает, вряд ли что-то новое будет

мне сегодня рассылка пришла, тема называется "Секреты почты Рамблера". Шетухин там нач. отдела. может что-то новое услышим.

 

[fixxxer]

не, ну так то

location /loc {
    component "foo" http://service1/path1;
    component "bar" http://service2/path2;
    template http://collector/foo.js # spidermoney или там google v8
}

....

{
   'foo': <result-of-foo>,
   'bar': <result-of-bar>,
}

....

Response.write(...)

хехе

 

[Alexandre]

я думал компоненты включить тегами в шаблон, что то типа:
{#include $foo=http://service.1/foo }
иначе конфиг может сильно разрастить.

каждую компоненту проксировать в общий шаблон. Тут довольно-таки нестандартная задачка, хочется каждую компоненту вызывать асинхронно, распаралелить задачу, иначе он мало чем будет отличаться от другого шаблонизатора (тот же CTPP). городить свой огород с распаралеливанием не хочется, а вот как грамотно использовать средства API nginx пока не знаю. Можно пока покопать SSI

 

[MiksIr]

Думаю, что для твоих целей SSI вполне хватает.
Ковырять дальше в плане шаблонизатора можно только если есть желание оставить в nginx все представление, а бекенд - только для данных. Такой вариант уже есть - XSLT, а распараллеливание можно опять же оставить SSI-ю. Т.е. есть основа с SSI, которые ведут во внутренние локейшены, каждый из которых проксирует на нужный бекенд, получает XML с данными и ему же прописан свой XSLT.
Не очень красиво (особо для тех, кто не любит XSLT), но фактически готовое решение.

 

[Alexandre]

Ковырять дальше в плане шаблонизатора можно только если есть желание оставить в nginx все представление, а бекенд - только для данных

в этом-то и вся фишка ...
ты экономишь во первых на размере потока проксирования (только данные или полностью HTML)
во вторых - можешь распаралеливать задачи (задача или как фиксер обозвал - компонента формирует свой блок данных )
в третьих - можно часть блоков - закешировать (опционально).

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

 

[Sherman]

Автор оригинала: MiksIr
Думаю, что для твоих целей SSI вполне хватает.
Ковырять дальше в плане шаблонизатора можно только если есть желание оставить в nginx все представление, а бекенд - только для данных. Такой вариант уже есть - XSLT, а распараллеливание можно опять же оставить SSI-ю. Т.е. есть основа с SSI, которые ведут во внутренние локейшены, каждый из которых проксирует на нужный бекенд, получает XML с данными и ему же прописан свой XSLT.
Не очень красиво (особо для тех, кто не любит XSLT), но фактически готовое решение.

Только скажем получить от backend xml, затем обработать его в xslt и затем снова дернуть SSI не получиться.
SSI в этой фазе уже не отработает.

-~{}~ 06.08.09 17:28:

Автор оригинала: Alexandre
XSLT - не думаю, что быстро, хотя замеры не делал. Может предложенная тобой схема будет работать быстрее аналогичного функционала реализованного на смарти. Вообще надо будет поэксперементировать.

В рассылке где-то было сравнение с mod_xslt. Там можно глянуть порядок цифр вообще.

 

[MiksIr]

Только скажем получить от backend xml, затем обработать его в xslt и затем снова дернуть SSI не получиться.
SSI в этой фазе уже не отработает.

М.. а это не то?
0.7.59
Исправление: ответы модуля ngx_http_xslt_filter_module не обрабатывались SSI-, charset- и gzip-фильтрами.

 

[Alexandre]

Sherman тут нужно продумать тест... с бух-ты барахты не сделаешь. Как я уже пояснял, Смысл вышепредложенного - поделить WEB приложение на n-компонент ( news, weather, blogtop, vote_res, adv_top, adv_left etc) Каждая из них вызывается асинхронно и отдает свой xml / json или иной формат. Cборку производим на nginx. Какие-то результаты из вышеперечисленных можно закешировать. Облегчить ApplicationLogic (PHP ) по максимуму. Лекгие простые скрипты, все летает на ура.
Если даже у нас существует простое XML/XSLT преобразование, то по идеи тоже все должно летать на ура.

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