Результаты тестирования шести ведущих фреймворков на производительность

>Spring, Struts, JSF и тд.

дурак чтоли? сравниваются СКРИПТОВЫЕ языки.

>Форум, например, будет очень сложно закешировать :).

см forum.ixbt.com

правда, говорят, пока глючит.

> > Модули Перла тоже неплохо так пишутся на на строго типизированных языках программирования общего назначения (в основном С/C++)

> дык, речь там была о начальном ПРЕДНАЗНАЧЕНИИ ;)))

Изначальное предназначение перла - писать все, что на shell/awk слишком громоздко, а на C - бессмысленно и сложно. Когда он создавался, никакого веба еще в проекте не было ;-)

>см forum.ixbt.com правда, говорят, пока глючит.

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

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

Ну, у меня древний Xeon-1800 по 700 тыс. хитов в сутки вытягивает не просто легко, а гоняя ещё в фоне MMORPG на Java без особых лагов :) Почти все запросы - на те или иные компоненты CMS. В среднем за сутки доходило до 800 MySQL-запросов в секунду. Сейчас, правда, уменьшил, добавил больше статики. А то у юзеров MMORPG начала подлагивать :)

>Форум, например, будет очень сложно закешировать :)

Сейчас почти весь контент форумов (около полутора гигабайт, скоро перевалит за миллион постингов) в кеше лежит. Но сборка каждой страницы ещё на PHP+MySQL. Всё руки не доходят фронтенд от PunBB на свой перевести. Вот тогда будет полная статика :)

...

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

>см forum.ixbt.com

>правда, говорят, пока глючит.

Он не просто глючит. Он чудовищно неудобен :D Страдаю каждый раз, когда приходится там попостись. А уж про браузеры без JavaScript на нём сразу забыть можно.

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

Давать пользователям выбирать скин - пользователи поделятся на две категории. 90% будут использовать скин по умолчанию (если, конечно, он не самый дерьмовый, но это уже забота админа), а 90% из оставшихся 10% выберут самый неудачный скин, не замечая, как напрягают себе глаза и т.п. :)

То же самое со всяким разным числом постингов на страницы. Потом очень забавно смотреть "Я об этом писал на 15-й странице" - "Нет, не видел я там!". А всего-то делов, что один из этих умников выставил свои параметры.

...

Так что, единственное, что нужно индивидуально подсовывать - всякие там закладки, личные сообщения, отметки об оновлениях... А вот это всё уже можно на JavaScript посадить.

>Давать пользователям выбирать скин - пользователи поделятся на две категории

Я для примера привел то что поломает кэш :).

>Так что, единственное, что нужно индивидуально подсовывать - всякие там закладки, личные сообщения, отметки об оновлениях... А вот это всё уже можно на JavaScript посадить.

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

Короче проблему производительности надо решать на этапе разработки на уровне движка а не когда все пукнет или по крону делать " * * * * * wget --header="Host: site.ru" http://localhost/ -O /home/site.ru/www/index.html" :)

Думал речь идет об Open Symphony и WebWorks, а сравнение этой фигни лично мне мало интересно.

Насчет производительности. Более-менее серьезного заказчика волнует масштабируемость. Т. е. возможность закинуть это все на быстрое железо или на кластер, где приложение будет просто летать.

А низкоуровневое оптимизацией нынче мало кого привлечешь. Что толку от того, что приложение летает на музейном сервере образца 2000 года?

>Насчет производительности. Более-менее серьезного заказчика волнует масштабируемость. Т. е. возможность закинуть это все на быстрое железо или на кластер, где приложение будет просто летать.

Не видел ни одного web-движка который бы кластеризовался из коробки и который используют типичные зачазчики, по крайней мере не самописного. А заказчиков с которыми я работал волновало только чтобы а) работало б)было не сильно дорого. О кластерах они знают только по наслышке.

>А низкоуровневое оптимизацией нынче мало кого привлечешь. Что толку от того, что приложение летает на музейном сервере образца 2000 года?

Это ты так думаешь, 90% проектов что я "размазывал" по нескольким серверам отлично работали бы на одном сервере если бы не криворукие прогеры. Щас такие сервера пошли, world во бзде меньше чем за 20 минут собирают. Такие тачилы при правильном подходе стока запросов держат что access-лог больше 10гигов в сутки получается и при этом еще есть запас по производительности. Админить, бэкапить и обновлять одну железку гораздо легче чем стойку. Меньше железа-меньше вероятность отказа.

> Не видел ни одного web-движка который бы кластеризовался из коробки и который используют типичные зачазчики, по крайней мере не самописного. А заказчиков с которыми я работал волновало только чтобы а) работало б)было не сильно дорого. О кластерах они знают только по наслышке.

Бизнес логика суется в EJB, веб-фраемворк Struts, все кидается куда-нибудь на weblogic или JBoss, если денег на сервер жалко, которые пашут на кластере.

Немного не по теме. Зашел на http://udaff.com/ там на главной странице картинке с Билли, упал под стол.

>Бизнес логика суется в EJB, веб-фраемворк Struts, все кидается куда-нибудь на weblogic или JBoss, если денег на сервер жалко, которые пашут на кластере.

Я имел в виду что то с чем мне приходится работать кластеризуется через попу(php-движки всякие типа битрикса). Почему-то жабовладельцы за помощью не обращаются :).

> Сервак сейчас можно и за $1500 взять. Это ~ месяц работы одного среднего php-кодера.

А где такую работу дают?

> А где такую работу дают?

В москве разве что.

Питон рулит! Сам на нём пишу. Забудьте вы этот ПХП, как я это когда-то сделал.

>Изначальное предназначение перла - писать все, что на shell/awk слишком громоздко, а на C - бессмысленно и сложно. Когда он создавался, никакого веба еще в проекте не было ;-)

а кто спорит? ;) прочитайте еще раз и поймете :)))

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

Zope гляньте

> Ну вот, уже одно только включение eAccelerator уменьшает разрыв Django/PHP всего вдвое. И это у довольно тормозных фреймворков...

ххехе а у джанго включаем psyco. -)

>ххехе а у джанго включаем psyco. -)

И идём, читаем, что по этому поводу пишут в статье.

Там еще и апдейт теста появился http://www.alrond.com/ru/2007/feb/04/dopolnenie-k-test-mvc-frameworks/