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

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

см forum.ixbt.com

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

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

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

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

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

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

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

...

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

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

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

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

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

...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zope гляньте

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

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