В том, что ZF - большой фреймворк, нет ничего страшного. Никто ведь не заставляет использовать абсолютно все классы, которые в него входят, причем одновременно :)
Тот же Zend View отлично живёт своей жизнью.
Другое дело, что есть куча плюшек в виде интеграции разных компонентов вместе, что дает синергетический эффект. Но это уже немного оффтопик.
По-моему вы сделали поспешный и безосновательный вывод :)
Просто я считаю, что за каждой технологией должен стоять авторитет, который будет показывать типичные способы применения этой технологии. Чтобы девелоперы не писали собственные шаблонизаторы, если они сами того не хотят. Чтобы был какой-то мейнстрим, а не каша из говнокода, который копипейстится по всему инету.
Будет ли это Smarty или Zend_View - это уже не так принципиально, лишь бы был какой-то индустриальный стандарт. Именно в этом успех Джавы и Дотнета - за ними стоят крупные компании, которые учат разработчиков грамотно реализовывать типичные решения, не изобретая велосипедов.
Zend упустил этот момент в отношении PHP и теперь пытается исправить свою ошибку при помощи Zend Framework. Жаль, конечно, что они взялись за это важное дело так поздно, но лично меня очень радует, что они наконец таки взялись за него. И пусть в некоторых местах ZF пока ещё кривоват, а архитектурные решения - не совсем очевидны, прогресс идёт, шестеренки закрутились :)
Всё равно не вижу проблемы.
При первом обращении к example.com клиент в любом случае делает DNS-запрос.
Сделать ещё один для img.example.com - не такая уж и проблема, учитывая что это просиходит всего один раз, зато даёт много вкусных плюшек в перспективе :)
Да-да, мне это тоже знакомо :)
Просто вот взять ту же ленту "Прямого эфира" с Хабра... на скольких страницах она есть?
Имеет ли смысл перегенерять все эти страницы (фактически, все страницы Хабра) каждый раз, когда эта лента меняется? По-моему, тут как раз больше подойдет моё решение.
Каюсь, как я ниже уже писал, недостаточно хорошо подготовился к данной теме.
Есть один важный момент, который упустил я, но озвучили мейлрушники - эти SSI-инклюды не обязательно должен обрабатывать один сервер. Нагрузку можно разделить на кластер, в котором один сервер отдает первый блок, второй сервер - второй блок и т.д.
Кроме того, данный подход дает большую гибкость при управлении устареванием кэшированных блоков. Например, У нас есть страница хабрастатьи. Саму статью можно закэшировать "навсегда", но слева от неё есть блок "Прямой эфир", которую можно кэшировать только на одну минуту, например. Вынеся "Прямой эфир" в отдельный инклюд, мы можем установить у него собственный лайфтайм, по истечению которого он будет абсолютно прозрачно перегенерирован. При этом сама страница статьи в мемкэше вообще не изменится.
Угу, паранойя. Но паранойя - наш друг :)
Вообще согласен с djem, при обновлении данных программа сама сбрасывает кэш. Тут тоже не всё так просто, кто-то должен знать, по каким урлам кэшируется какой контент. Но это тема для отдельной статьи.
Боюсь, что на по-настоящему динамических сайтах (например, напичканных ajax'ом) нельзя кэшировать не только блок авторизации, но и почти все элементы страницы - кнопочки с числом комментариев, "добавить в избранное", "присоединиться к блогу" и т.д. Если же сайт состоит почти только из статических элементов, то писать контент в мемкэш или на жёсткий диск - разница невелика (да-да, я знаю, что ОП работает быстрее, но я думаю, что в данном случае разница будет ничтожной).
Вы правы, данный подход применим для "не очень динамических" сайтов.
Но идея здесь не в том, чтобы всеми силами записать данные в мемкеш непонятно зачем.
Идея в том, чтобы nginx максимально справлялся с обработкой запросов сам, дергая Apache только тогда, когда другого выхода не будет.
А потом: а Вы уверены, что последовательность SSI-запросов к нескольким блокам на странице будет работать быстрее, чем один цикл отработки кода, генерящего все эти блоки разом? Несколько SSI-запросов - это, как минимум, несколько одинаковых циклов инициализации кода, т.е., например, выгрузка сессии из базы, авторизация пользователя и тому подобные вещи, которые для 10 SSI-блоков будут вызваны 10 раз. Ох не факт, что это будет эффективнее...
Не уверен. Более того, я уверен, что 10 SSI-инклюдов будут работать медленнее одного самого обыкновенного запроса к Apache при прочих равных условиях. Что же делать? Не использовать данный подход бездумно. Если на странице такое кол-во динамических блоков, то её не имеет смысла кэшировать вообще, либо стоит использовать более сложные алгоритмы кэширования, но всегда отдавать контент через Apache/PHP.
К тому же шаблонизаторы в нормальных ЯП работают по производительности не хуже, чем nginx в обработке SSI-шаблонов, а то и лучше, потому что шаблоны можно кэшировать на уровне кода.
А вот тут мне тяжело согласиться. Реальных цифр у меня на руках нет, но что-то подсказывает мне, что реализация SSI в nginx утрет нос любому шаблонизатору в плане производительности. Особенно это касается шаблонизаторов на PHP, которые будут работать по определению значительно медленнее, даже при включенном кэшировании байткода.
Так что, ИМХО, Вы переизобретаете колесо с одним лишь изменением: оно немного квадратное :).
Вполне возможно... Утешает только, что, оказывается, не один я такой наивный - ребята из мейл.ру были раньше ;)
На хайлоаде не был, к сожалению. Идея у меня родилась "изолированно", но на оригинальность я не претендовал. Просто на хабре ничего на эту тему не нашел, вот и решил статью набросать.
Основные примеры уже назвали - это Firefox, Thunderbird, Komodo... но это всё - обычный (application XUL), а примеров именно remote XUL под веб - не так уж и много.
Самый известный - это Mozilla Amazon Browser, ссылку на него я уже привел выше.
Кроме того, можно взглянуть на пример использования практически всех XUL'овских контролов вот тут:
http://www.hevanet.com/acorbin/xul/top.xul
Само собой, контролы выглядят по-разному в зависимости от ОС и настроек "темы" пользователя.
По поводу "серости" - XUL берет её из настроек ОС точно так же, как это делают остальные десктопные приложения. А "убогость" - тут с вами не соглашусь. Это не убогость, это аскетичность. Любой контрол XUL'а можно разукрасить как угодно при помощи обыкновенных CSS. Только тогда основной смысл XUL'а теряется - не будет никакой адаптации под настройки и ОС пользователя. Контролы на WinXP будут выглядеть так же, как и на Маке и т.д.
Тот же Zend View отлично живёт своей жизнью.
Другое дело, что есть куча плюшек в виде интеграции разных компонентов вместе, что дает синергетический эффект. Но это уже немного оффтопик.
Дело ведь не в "скобочках", вопрос намного шире.
Просто я считаю, что за каждой технологией должен стоять авторитет, который будет показывать типичные способы применения этой технологии. Чтобы девелоперы не писали собственные шаблонизаторы, если они сами того не хотят. Чтобы был какой-то мейнстрим, а не каша из говнокода, который копипейстится по всему инету.
Будет ли это Smarty или Zend_View - это уже не так принципиально, лишь бы был какой-то индустриальный стандарт. Именно в этом успех Джавы и Дотнета - за ними стоят крупные компании, которые учат разработчиков грамотно реализовывать типичные решения, не изобретая велосипедов.
Zend упустил этот момент в отношении PHP и теперь пытается исправить свою ошибку при помощи Zend Framework. Жаль, конечно, что они взялись за это важное дело так поздно, но лично меня очень радует, что они наконец таки взялись за него. И пусть в некоторых местах ZF пока ещё кривоват, а архитектурные решения - не совсем очевидны, прогресс идёт, шестеренки закрутились :)
По-моему уж лучше такой авторитет, чем вообще никакого.
При первом обращении к example.com клиент в любом случае делает DNS-запрос.
Сделать ещё один для img.example.com - не такая уж и проблема, учитывая что это просиходит всего один раз, зато даёт много вкусных плюшек в перспективе :)
Просто вот взять ту же ленту "Прямого эфира" с Хабра... на скольких страницах она есть?
Имеет ли смысл перегенерять все эти страницы (фактически, все страницы Хабра) каждый раз, когда эта лента меняется? По-моему, тут как раз больше подойдет моё решение.
А вообще, Хабр таким способом кэшировать сложно - у него всякие "галочки" и "рейтинги" напротив каждого комментария есть, их особо не закэшируешь...
Пардон, справа.
Есть один важный момент, который упустил я, но озвучили мейлрушники - эти SSI-инклюды не обязательно должен обрабатывать один сервер. Нагрузку можно разделить на кластер, в котором один сервер отдает первый блок, второй сервер - второй блок и т.д.
Кроме того, данный подход дает большую гибкость при управлении устареванием кэшированных блоков. Например, У нас есть страница хабрастатьи. Саму статью можно закэшировать "навсегда", но слева от неё есть блок "Прямой эфир", которую можно кэшировать только на одну минуту, например. Вынеся "Прямой эфир" в отдельный инклюд, мы можем установить у него собственный лайфтайм, по истечению которого он будет абсолютно прозрачно перегенерирован. При этом сама страница статьи в мемкэше вообще не изменится.
Только одна мелочь - по-моему
можно заменить на просто
А nginx отдает только определенный набор картинок?
Чего всю статику через него не отдаете?
Вообще согласен с
Вы правы, данный подход применим для "не очень динамических" сайтов.
Но идея здесь не в том, чтобы всеми силами записать данные в мемкеш непонятно зачем.
Идея в том, чтобы nginx максимально справлялся с обработкой запросов сам, дергая Apache только тогда, когда другого выхода не будет.
Не уверен. Более того, я уверен, что 10 SSI-инклюдов будут работать медленнее одного самого обыкновенного запроса к Apache при прочих равных условиях. Что же делать? Не использовать данный подход бездумно. Если на странице такое кол-во динамических блоков, то её не имеет смысла кэшировать вообще, либо стоит использовать более сложные алгоритмы кэширования, но всегда отдавать контент через Apache/PHP.
А вот тут мне тяжело согласиться. Реальных цифр у меня на руках нет, но что-то подсказывает мне, что реализация SSI в nginx утрет нос любому шаблонизатору в плане производительности. Особенно это касается шаблонизаторов на PHP, которые будут работать по определению значительно медленнее, даже при включенном кэшировании байткода.
Вполне возможно... Утешает только, что, оказывается, не один я такой наивный - ребята из мейл.ру были раньше ;)
Вот результат :)
Самый известный - это Mozilla Amazon Browser, ссылку на него я уже привел выше.
Кроме того, можно взглянуть на пример использования практически всех XUL'овских контролов вот тут:
http://www.hevanet.com/acorbin/xul/top.xul
Само собой, контролы выглядят по-разному в зависимости от ОС и настроек "темы" пользователя.
По поводу "серости" - XUL берет её из настроек ОС точно так же, как это делают остальные десктопные приложения. А "убогость" - тут с вами не соглашусь. Это не убогость, это аскетичность. Любой контрол XUL'а можно разукрасить как угодно при помощи обыкновенных CSS. Только тогда основной смысл XUL'а теряется - не будет никакой адаптации под настройки и ОС пользователя. Контролы на WinXP будут выглядеть так же, как и на Маке и т.д.