Re: ssi

[Ihalainen Nickolay <ihanick@xxxxxxxxx>]

2009/12/20 Nikolay Grebnev <nick@xxxxxxxxxxxx>:
>
>
> 2009/12/20 Peter Leonov <gojpeg@xxxxxxxxx>
>>
>> On 20.12.2009, at 1:34, Nikolay Grebnev wrote:
>>
>> Здавствуйте, Николай.
>>
>> > Добрый день.
>> > Задумался об использовании у нас ssi. Кроме документации
>> > http://sysoev.ru/nginx/docs/http/ngx_http_ssi_module.html  нашел еще на
>> > http://www.profyclub.org/articles/299/3036
>> > SSI -- это моя гордость. Ее необходимость была понятна с самого начала.
>> > Фильтр позволяет вставлять запросы с локального диска и удаленных серверов.
>> > Например, один из них (показывает на <<.. ..#include
>> > virtual="/perl/one.html"-->) и уходит на один сервер, второй (показывает на
>> > <<.. ..#include virtual="/perl/two.php"-->) -- на FastCGI. При этом ответ 
>> > от
>> > Apache может еще раз пройти через этот фильтр, еще раз сходить к десяти
>> > серверам, получить от каждого ответ и снова пропустить через фильтр.
>> > Получается очень сложно устроенная рекурсивная вещь. Я иногда сам забываю
>> > некоторые моменты того, как она устроена. Она работает нормально (есть
>> > только один известный баг, который я скоро исправлю). Почти везде, где в
>> > Рамблере есть nginx, используется SSI.
>> >
>> > Вопрос - а есть ли какие-то примеры реальных ситуаций (архитектурных
>> > решений), как это можно использовать?
>> SSI он для того, чтобы собирать страничку по кусочкам, а еще и асинхронно.
>> Каждый кусочек можно настраивать по-разному: кешировать, ротировать,
>> генерировать на лету встроенным перлом, выкачивать с сервера из Африки или
>> из пула мемкешей в соседней стойке. SSI в nginx, и вправду, невероятно
>> мощная вещь. Тут миллион ситуаций можно придумать...
>>
>
> а что будет если сервер в Африке сдох? Тайм-ауты будут отрабатывать?
>> Мы, вот, сайт построили целиком на SSI :)))

> Это здорово. Вот  как раз об этом я и спрашивал :)
> 1 Почему именно ssi, в чем реальные плюсы в использовании на архитектурном
> уровне
> 2 А как конкретно? На этот вопрос думаю отвечать тут тяжко - фактически тема
> статьи... Поэтому нет ли ссылок на статьи где описываются примеры? (это
> вопрос к общественности)
1) есть бекенд который генерит ключи в memcache, содержащие блоки
страниц с определённым временем инвалидации, блоки, это: последние
новости/коментарии, хитрая навигация, которая меняется в зависимости
от раздела.
2) есть шаблон в который проиводятся include: это может быть статика,
или тоже ответ от бекенда
3) и есть nginx, который может собрат страничку исходя из шаблона,
ответов бекенда и memcached.

Какие преимущества? тяжёлый бекенд (php,j2ee) во время создания
сложной страницы может даже не дёрнуться, хотя страница будет
сгенерена уникальная для данного пользователя.
архитектура проекта изначально учитывает разноуровневое кеширование и
инвалидацию кешей, что позволяет достигать высокой масштабируемости.
архитектура кешей более бережно использует место в памяти под кеши,
потому что кастомизированная под каждого страница состоит из большого
количества общих блоков.
сборка ssi происходит ассинхронно, поэтому страница может состоять и
из быстрого контента (memcached, local file cache) и из медленного
(ответ бекенда) при этом медленные ответы будут генериться параллельно
(уменьшаем время ответа)
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru