да ладно тебе людей пугать ;)

можно жабку как PHP использовать на крайняк ;) Model 1, все в jsp, никаких MVC и тегов. jit откомпиленые скрипты получаются ;)

Эт я так..., под конец рабочего дня :)

Можно и как пхп использовать. И скорость будет очень неплохая, как откомпилится. Если томкет не устроит, можно Resin глянуть. Там транспортный коннектор нативный как опция. Говорят, значительно шустрее томкета работал (раньше).

А чтобы 50 запросов в секунду получить в последовательном случае, надо еще время пинга от клиента учесть.

>Говорят, значительно шустрее томкета работал (раньше).

угу, он быстрее всех работал(ет) на динамике.

+ есть люди которые не стесняются Model 1 - mvnforum из к примеру[из вьетнама], в их Jsp смотреть страшно.

А что ее стесняться? Не каждый же день разрабатываешь веб-портал или магазин. Иногда надо сделать приложеньище, позволяющее редактировать три таблички удаленно. Тулзу, короче. JSP c DWR спасает бедного программера, пытающегося представить, на чем делать... В джаве однозначно не всё пушисто в плане поддержики разработки мальньких приложеньиц типа БД. RoR здесь рулит.

Мусор - он не в jsp, а в мозгах. MVC не спасет бедных веьтнамцев. Он только схавает их мозг еще больше.

>а что-ж ты весть пост не доцитировал? ;)

лень

>Последние посты в разделе Linux-org-ru только об этом. Хотя может быть просто "кто-то не умеет готовить котят"? ;)

посмотри темы, открой... тормоза были из-за сетевых проблем

ну не знаю. я всетаки сторонник завинчивания шурупов шуруповертом с электроприводом, а не отверткой.

форум это все таки не три таблички.

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

Другая аналогия: мне надо просто откыть крышку компа, я достаю отвертку из ящика стола. Не надо топать в мастерскую за громоздкой электроотверткой и искать, в какую розетку ее включить.

Когда же целый день закучиваешь винты, то электроотвертка рулит однозначно.

Если про JSP, то она не подходит там, где нужны reusable components. Всё остальное там делается нормально, хотя и не так "изящно" как в других фрэймворках. Правда, если стараться делать на jsp "правильно", то в конце концов получится свой фреймворк, заточенный под породившую его задачу. Замкнутый круг. То же самое касается и ORM.

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

Так мы человеку что-нить посоветуем ? :)

> Обрашения к базе будут кешироваться и реально будут нужны только в 40% обрашений к скрипту.

Тогда, очевидо, и данные будут одинаковые, и результат рендеринга? Почему бы не кешировать срендеренные страницы тогда?

> ClearSilver можно использовать если просто положить его в каком-то виде в свою директорию у хостера? Или надо его именно у хостера собирать?

Гм. На знаю, не пробовал. У меня чаще стоит проблема "как бы это на все серверы разложить правильно" ;-)

Что мешает протестировать-то? Думаю, что можно а) найти готовый собранный под платформу хостера, б) поднять у себя (в vmware, скажем, или xen) такую же как у хостера систему и собрать в ней.

Вообще, идея размещать проект на несколько (десятков?) тысяч посетителей в день на shared hosting выглядит, ээ, странно.

>Вообще, идея размещать проект на несколько (десятков?) тысяч посетителей в день на shared hosting выглядит, ээ, странно.

Это на первое время.
Планируется использовать хостинг www.servage.net, может кто хосил там Python проекты?
Вообще от хостера кроме "Python support", что-либо требуется для работы ClearSilver / Django / TurboGears?
Python скрипты компилятся сами при первом обращении к ним или надо вручную?
Хостеры обычно поддерживают работу скомпиленных Python скриптов?

>посмотри темы, открой... тормоза были из-за сетевых проблем

out of memory? ;)

трудно это, человекам советовать. Раз он не костыль и не поделку делает, то пусть тогда спринг(у него документация качественная, да и мейнстрим это проверенный) использует и xen хостинг типа http://www.slicehost.com/

Думаю, если скорость на столько критична, то сервлет + caucho resin + кэширование всего что только можно, в том числе и отрендеренного html + особое внимае возможным утечкам ресурсов. остальную часть приложения можно в спринге.

ну да, кеширование на всех уровнях(n tiered architecture), благо !кластеризуемый! открытый кеш есть (oscache) и с хибернейтом интергрируется вроде. Сaucho resin тоже кластеризироваться может. Ну и прокси перед всем этим поставить можно. Тогда точно с скоростью, вернее с максимальным количеством респонзов, проблем не будет.

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

Что автор темы скажет?

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

Я вам больше скажу - слова "на джаве" - лишние ;)

Для перла, скажем, есть memcached.

И всегда можно кеширующий reverse-proxy перед HTTP-сервером воткнуть.

угу, даже есть java порт memcached

http://jehiah.com/projects/j-memcached/

2aist1:
Мне бы ваши знания :) Хочу такие же. В каком универе учились/учитесь Java? Или на работе научили?

Ради справедливости стоит отметить, что есть минусы в таком кешировании(на определённое время), как в memcached. Поэтому не всегда подходит гигантский хеш хранимых объектов под бобмой с часовым механизмом.

/Сам юзаю memcached в PHP/

как то ты не адекватно сЪиронизировал. Не все на вебе специализируются.

А почему никто не предложил parser3? Помимо Unicode, он даже поддерживает объектно-ориентирующихся программистов! http://www.linux.org.ru/jump-message.jsp?msgid=184288 http://www.parser.ru/

>Если по большому счету, то так. На сколько я знаю, все крупные сайты на джаве используют ту или иную модель распределенного кэширования информации. Но может тут что проще и конкретнее надо?

>Что автор темы скажет?

Да, memcached было бы хорошо, но боюсь на первоначальном хостинге его не будет. Пока планирую: - кешировать некоторые отренденные HTML страницы - кешировать небольшие справочные таблицы из БД в виде хешей в файлах и читать их serialize'ом - наверное ещё кеширвоать данные сессии в файлах, где будут результаты некоторых выборок из БД, читать их serialize'ом

>А почему никто не предложил parser3? Помимо Unicode, он даже поддерживает объектно-ориентирующихся программистов! http://www.linux.org.ru/jump-message.jsp?msgid=184288 http://www.parser.ru/

Он не распространен, специфический и врятли позволяет тонко работать с БД, файлами и т.п.

>Если по большому счету, то так. На сколько я знаю, все крупные сайты на джаве используют ту или иную модель распределенного кэширования информации. Но может тут что проще и конкретнее надо?
>Что автор темы скажет?

Да, memcached было бы хорошо, но боюсь на первоначальном хостинге его не будет.
Пока планирую:
- кешировать некоторые отренденные HTML страницы
- кешировать небольшие справочные таблицы из БД в виде хешей в файлах и читать их serialize'ом
- наверное ещё кеширвоать данные сессии в файлах, где будут результаты некоторых выборок из БД, читать их serialize'ом

В наших универах этому не учат :(

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

Просто файлы не дадут принципиального прироста по сравнению с БД, так как узкое место всё равно диск, который будет загружен (данных придется ждать десятки и сотни миллисекунд в худшем случае). Над файлом надо организовывать прозрачный инвалидируемый кэш прикладного уровня, управляемый приложенем, а не дисковой подсистемой ОС. Но это потребует произвольного доступа к сериализованным данным в файле.

Проще организовать такой инвалидируемый кеш сразу над БД и кешировать результаты запросов.

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

> Просто файлы не дадут принципиального прироста по сравнению с БД, так как узкое место всё равно диск, который будет загружен (данных придется ждать десятки и сотни миллисекунд в худшем случае). Над файлом надо организовывать прозрачный инвалидируемый кэш прикладного уровня, управляемый приложенем, а не дисковой подсистемой ОС. Но это потребует произвольного доступа к сериализованным данным в файле.

Тут помог бы memcached, но на первоначальном хостинге врятои что-то подобное будет.

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

В БД будет 1 большая таблица с кучей внешних ключей. И куча маленьких таблиц-справочников. Таблицы справочники я хочу кешировать в файл в виде хеша - полагаю загрузка из файла сразу в виде хеша будет быстрой.

В принципе можно при запросе данных из большой таблицы сразу просить БД связать эти данные по справочникам. Полагаю что связывание в БД + возврат кучи строк займет больше времени чем возврат БД внешних ID справочников, по которым из хешей я получу строки.

Имеет вообще смысл так делать?

>Правда, я плохо представляю как это организовать на перле. К сожалению, в области Веба ничего кроме джавы не использовал.

Я скорее всего на Python буду писать.

> В принципе можно при запросе данных из большой таблицы сразу просить БД связать эти данные по справочникам. Полагаю что связывание в БД + возврат кучи строк займет больше времени чем возврат БД внешних ID справочников, по которым из хешей я получу строки.

Хотя скорее всего наоборот?

Если данные в файле то приходится полагаться на дисковый кэш ОС. Это очень ненадежно, если машина нагружена. Когда приходится десятки миллисекунд тратить на ожидание подгрузки данных с диска, не так важно где они - в базе или в файле.

Кэширование на уровне приложения гарантирует нахождение данных в памяти в нужный момент.

Если есть возможность проведи тест: сравни скорость тягания данных из базы и из файлов на фоне параллельного копирования нескольких больших файлов. Принципиальной разницы быть не должно.

Справочники, если их суммарный объем невелик, лучше хранить в памяти, а из базы получать только IDшники значений. Join - операция весьма дорогая, особенно на нагруженной базе, так как данные придется тягять с разных мест.

У нас недавно тестировали постре, мускуль и файрберд на базах 2-4 Г на предмет скорости. Как ни странно, под нагрузкой лучше всего себя зарекомендовал файрберд. Скорее всего из-за того, что он данные хранит компактнее других и они лучше помещаются в память.

parser3

> Он не распространен, специфический и врятли позволяет тонко работать с БД, файлами и т.п.

Parser3 имеет единый интерфейс работы с базами данных, включает поддержку XML/XSLT, и даже позволяет хранить базу данных в простых файлах (например, tab-separated). Освоение языка не должно составить проблемы, и доступна отменная документация на русском языке с большим количеством примеров. (Документация на английском сейчас тоже есть.) Или вы имеете ввиду что-нибудь более конкретное под "тонко работать с БД, файлами"? ИМХО, работать с БД тонще чем Parser3 для веб-приложений практически нереально! Я на парсере даже писал клиент SOAP к JAVA-серверу SOAP, и даже сам сервер SOAP.

> Parser3 имеет единый интерфейс работы с базами данных, включает поддержку XML/XSLT, и даже позволяет хранить базу данных в простых файлах (например, tab-separated). Освоение языка не должно составить проблемы, и доступна отменная документация на русском языке с большим количеством примеров. (Документация на английском сейчас тоже есть.) Или вы имеете ввиду что-нибудь более конкретное под "тонко работать с БД, файлами"? ИМХО, работать с БД тонще чем Parser3 для веб-приложений практически нереально! Я на парсере даже писал клиент SOAP к JAVA-серверу SOAP, и даже сам сервер SOAP.

Да, в чем-то он возможно и хорош... но применим в основном только в России...
+ Разработан "Лебедевым и Ко", а мне его дизайнерский HTML-код не особо то нравится...
Особой пользы изучения не вижу...
Python, Java, Perl - они очень широко применяются и развиваются...
А вот забросят разработчики Parser и все, никто и не продолжит...

> Да, в чем-то он возможно и хорош... но применим в основном только в России...

Так если у вас задача -- написать во что бы то ни стало что-нибудь, что потом без труда будет поддерживаться любым веб программистом в любой стране, то да, парсер не лучший вариант. Если же задача быстро написать хороший и портируемый сайт без заморочек, и не испытывать каких-либо проблем с самостоятельной поддержкой -- то parser3 -- самое то.

> + Разработан "Лебедевым и Ко", а мне его дизайнерский HTML-код не особо то нравится...

Замечательный аргумент! Спрашивается, при чём здесь HTML Лебедева? ;)

Ну не использует он XHTML 1.0 Strict, ну и что с ним делать? Мы то с вами используем! ;)

> Python, Java, Perl - они очень широко применяются и развиваются... > А вот забросят разработчики Parser и все, никто и не продолжит...

Во-первых, parser3 полностью доступен в исходных кодах под лицензией GPL, так что кто-нибудь наверняка продолжит. А во-вторых, что-то не особенно похоже, что они его собираются забрасывать. К тому же, какая вам разница если его "официально" все забросят? Ваш сайт же всё равно будет работать? Будете переезжать на другую платформу? Так исходники языка есть, можно будет просто перекомпилировать сам парсер, и сайт будет как новый.

xml/xslt не лучший выбор там, где нужна высокая скорость обработки. Не для этого он разрабатывался. Лучше осмотреть в сторону более простых движков шиблонов или придумать свой, желательно на C/C++.

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

Мне нужно написать качественно, чтобы в случае чего можно было легко поддерживать, при этом дописывать куски может другой человек, который врятли знает Parser.
+ необходимо, чтобы работало максимально быстро, Java не удастся использовать, поэтому ориентируюсь на Python.

>Замечательный аргумент! Спрашивается, при чём здесь HTML Лебедева? ;)

Парсер может быть написан подобным же образом (не знаю - не смортел)...
Разработчик Python'а например работает в Google и одна из его задач - разработка Python. Google внушает больше доверия чем www.desing.ru.

>Во-первых, parser3 полностью доступен в исходных кодах под лицензией GPL, так что кто-нибудь наверняка продолжит. А во-вторых, что-то не особенно похоже, что они его собираются забрасывать. К тому же, какая вам разница если его "официально" все забросят? Ваш сайт же всё равно будет работать? Будете переезжать на другую платформу? Так исходники языка есть, можно будет просто перекомпилировать сам парсер, и сайт будет как новый.

Хочется в случае переезда использовать все новые возможности по максимуму. Например для Python как я понял есть Application Server'а, которые теоретически повысят производительность при минимальном изменении написанного кода...

>xml/xslt не лучший выбор там, где нужна высокая скорость обработки. Не для этого он разрабатывался. Лучше осмотреть в сторону более простых движков шиблонов или придумать свой, желательно на C/C++.

Да, согласен.
Присматриваюсь к ClearSilver, Cheetah...
Java как я уже говорил не могу использовать.

> xml/xslt не лучший выбор там, где нужна высокая скорость обработки. Не для этого он разрабатывался.

Вообще-то, он сильно быстрее шаблонных движков на скриптовых языках. Я мерил.

С ClearSilver не сравнивал, но, думаю, где-то на уровне.

Какой xml\xslt парсер использовался?