ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: [apache-talk] nginx-0.1.0



Здравствуйте, Igor.

Вы писали 15 октября 2004 г., 16:35:27:

> SSI будет точно, причём SSI-фильтр.
Это очень хорошо!

> Скрипты и PHP - только через FastCGI,
> но это не первоочердная задача.
Это менее актуально, хотя кому как....
Пытался буквально вчера "прикрутить" PHP к lihgttpd,
работать-работает, но скорость просто кошмарная. На одну страницу
уходило порядка 1-2 секунд. Правда, это был мой первый опыт с данным
сервером, и PHP я пускал просто через CGI.

> Кэширование будет. Я планирую развитие в таком порядке - кэширование,
> а затем SSI.
Замечательно.
Игорь, заранее извиняюсь, что повторно задаю похожий вопрос только уже
про другой сервер. Не могли бы Вы рассказать вкратце про настройку
этих самых фильтров, это нечто навроде обработчика (Handler) в Апаче?
Как можно в настройках задать порядок обработки текстового (т.е. по
миме-типу, например, text/html или вооще text/*) контента перед
отдачей клиенту? Может ссылки какие есть по этому поводу?
Всплыла все та же задача: кардинальное увеличение производительности
для довольно тяжелого портала. Вариант решения: кеширование страницы
по частям с учетом авторизационной информации. А именно: страница
разбивается на части: общий блок (центральная колонка с
псевдостатической информацией), навигация, персональная колонка (имя,
фамилия, настройки сайта, избранное и т.п.).

Общий блок как правило и есть общий - значит неразумно его рендерить
каждый раз, хотелось бы его кешировать.
Далее: персональные блоки. Их тоже можно закешировать, но при этом
необходимо учесть кому они принадлжежат и тому их и отсылать, это
можно сделать, например, на основе куков, идентификаторов сессий и
т.п.
Таким образом выходит, что документ, который нельзя закешировать
целиком, можно очень успешно закешировать по частям, так что 90% будет
браться из кеша, остальное - промахи и изменения блоков.

Теперь контент обрабатывается следующим образом:
-запрос от клиента направляется в бекэнд,
-в  ответ возвращается "болванка" (страница содержащая основной блок и
SSI команды на месте песональных блоков), причем нужно учесть, что эта
болванка  также может  кешироваться.    Т.е. если какая-либо статья на
сайте  не претерпела изменений с момента последнего запроса, то бекенд
(сравнив дату в запросе и дату последнего изменения) просто возвращает
код  304 и не пытается рендерить страницу. Либо, если в кеше нет такой
страницы,  то  она  рендерится  бекендом  и  сохранятеся  в кеш в виде
полуготовой "болванки"
-"болванка" передается SSI фильтру, он ее просматривает и дает
подзапросы на вытягивание персональных блоков. Здесь также часть из
них можно закешировать, а часть отрендерить- в любом случае рендеринг
небольшого блока зайтем меньше времени, чем рендеринг целой страницы.
-полученный куски склеиваются и отправляются клиенту.

Вот такие есть соображения, как увеличить производительность портала.

Я ничуть не пытаюсь претендовать на новизну данного подхода, это все
давно разработано, и уже есть стандарт - Edge Side Includes
(www.esi.org). Проблема в том, что как это сделать? Какая open-source
софтина хорошо поддерживает эту технологию?



> Игорь Сысоев
> http://sysoev.ru



-- 
С уважением,
 Eugene                          mailto:el-spam@xxxxxxxxx



 




Copyright © Lexa Software, 1996-2009.