Хех! Я обычно пишу для fastcgi на php.... :)))))))))))))))))))))))))))))))))))))))))))))))))))

Как это не понятно - первый листинг - он и есть для mod_fastcgi - на перле.

Особенно классно смотрятся графики из Экселя ;)

Забавно тестируется в данном случае java servlets. Меняем условия проведения конкурса и получаем следующее:

http://www.caucho.com/articles/benchmark.xtp

В обсуждаемом тесте несбалансированы условия тестирования по крайней мере для сервлетов. Tomcat/Apache! И сравнивается с mod_perl/Apache! Ужыс.

2gamajun (*) (2002-08-13 18:13:44.767)
они об это честно написали, но те кто используют ServLet'ы и так все знают и понимают ;-).

Действительно странно выглядят результаты...
mod_perl быстрее Servlets и php?
ню-ню...

Было бы здорово если бы они обошлись без БД - тогда бы результаты можно было бы сравнивать..

to: Nik (*) (2002-08-13 18:24:01.373)
mod_perl __действительно__ быстрее Servlets и php
Учи мат часть.

С уважением.

2 anonymous (*) (2002-08-13 18:53:14.968)

А факты?

Уже приводили линк, говорящий об обратном...
Вот он еще раз: http://www.caucho.com/articles/benchmark.xtp

Так что твое высказывание применимо скорее к тебе.

>>>> Уже приводили линк, говорящий об обратном...

Хороша фраза. Слышал гром. Ты Nik веришь каждому чужому слову в инете... Глупенький. Но мой опыт утверждает, что анонимус прав.

Остров.

2anonymous (*) (2002-08-13 19:27:42.259)
а на чем вы пускал ServLet'ы

А теперь про матчасть, компилируемый язык (java) в разы быстрее чем perl\php и т.д. ибо сила скриптовых языков не в скорости.

А если бы вы прочили статью то увидели бы этот абзац:
# Servlets on the other hand, behaved exactly as we expected. They run smoothly, Tomcat performed fast enough for a two year old project in the face of a complete redesign, and their behavior was predictable to some extend, and thus easily profilable. The servlet specification, being part of J2EE suite of specifications, would be more appropriate as a framework for large e-commerce sites, where it can be supported by enterprise-wide application servers on systems with lots of processors and memory. In our humble opinion, servlets and Java are not very well suited to quick site development, a field in which PHP excels. Also, we must make clear that for the results presented here we only used Tomcat as a benchmarking platform; other application servers perform much faster (eg see a comparison between Orion and Tomcat at [8]). The servlets platform is very promising and the results presented here may be unfair.

К слову Orion работает быстрее Tomcat в 6-7 раз.

Старая сказка про исключительную быстроту java. В жизни java делает mod_perl и php на цикличных "привет мир" и серьезно проигрывает на парсингах, на реализациях протоколов, криптографии и тд. Как вы думаете, на чем написан парсер XML для perl,php,java? Внимание,правильный ответ : C,C,java. Собственно вот и обьяснение результатов тестов. И perl и php легко расширяются интерфейсами к библиотекам написанным на C,что и является основным эффективным способом. Тоесть в указанных выше задачах львиная часть кода выполняются практически с эффективностью процессора.

Лучше ценить java за красоту, чем за скорость

все эти беньчмарки просто зачяточны.

2 Остров:
Мне по крайней мере пришлось поработать со всеми этими технологиями.
И мой опыт показывает что по производительности распределение примерно такое: Java - PHP - Perl

П поводу скорости парсеров на Java - это бред.
Посмотрите на бенчмарки XSL процессоров - на первом месте процессор от Джеймса Кларка писанный на java. да даже тот же Xalan в Java варианте быстрее C++.
На современных процессорах Java проги могут оказываться быстрее C-шных! Ну и естественно не стоит мерить яву со скриптовыми языками.

Ну да, перл скриптовый язык. Но не интерпретируемый! что вы тут всем голову морочите?

Java парсер быстрее сишного!!?

К доктору или авторов кода или автора наблюдений. Java по определению медленнее С*, остальное в ручонках.

2 anonymous (*) (2002-08-14 11:00:25.633):
вы наверное великий парсерописатель...
Ну так напишите на C XSL трансформер который будет быстрее XT.
Вот тогда и делайте такие заявления.

ну а пока можно посмотреть к примеру что пишут тут:
http://www.xml.com/pub/a/2001/03/28/xsltmark/?page=2

>Java по определению медленнее С*, остальное в ручонках.
это по какому такому определию она должна быть медленее ?

Скажем так на реальных задачах она часто медленнее (кстати не сильно по сравнению с perl,php и т.д.), но в принципе она может легко быть и быстрее. А если сравнивать не с С, а С++ то тут вообще разговор особый, т.к. в g++ затыков с С++ достаточно много.

Предлагаю любопытную ссылку по поводу сравнения языков. На мой взгляд убедительно.

http://www.bagley.org/~doug/shootout/

СтранниК

По скриптовые языки - perl - компилируемый язык, при запуске вся программа компилируется в byte code, который потом выполняется. При запуске из под mod_perl эта компиляция происходит один раз - в apache parent, если все подгружается в нем. jit etc в этом байте коде нет, то это - компилятор, а не интепритатор ( eval "$line"; - не считаем, так как так писать - не надо ). В общем случае - надо сначала предсталять о чем говоришь.

mk

ps. Про php не знаю точно, но в последних тоже что то вроде появилось.

ДЫК я не понял:

а ПХП почему не мод? они бы тогда и перл как cgi запускали бы. и все бы увидели как он обо.... .

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

какая разницца, у кого длиннее?.. главное -- на чём умеешь писать, причём правильно...

>Как это не понятно - первый листинг - он и есть для mod_fastcgi -
>на перле.

А... Точно. Тогда напротив такой его отрыв становится непонятным...
Я, наивно, предположил, что их fastcgi был на сях и поэтому так
легко и непринуждённо уделал конкурентов.

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

А главное - он через suexec работает. В отличие от.

Главное что он не apache-specific. Даже для IIS есть. Вот только для apache-2.0 пока нет :(

to gamajun: apache ни имеет ни какого отношения к компиляции perl в byte code :)

mk

2 любители Java

Посмотрите сколько памяти она жрет. sun jdk 1.4 ~16MB на обычном Hello World дает.

2 anonymous (*) (2002-08-15 23:40:32.66):
А ты посмотри цены на память.
кого интересуют лишние пара тройка сот мегов?
Ты б еще сказал что jre весит не мало и на винте место занимает...

По скриптовые языки - perl - компилируемый язык, при запуске вся программа компилируется в byte code, который потом выполняется. При запуске из под mod_perl эта компиляция происходит один раз - в apache parent, если все подгружается в нем. jit etc в этом байте коде нет,

Мдясь... ПЕРЛ компилирует (?) свой код во внутреннее представление в виде чего-то там не помню а лезть лень а не в байт код киньте мне ссылку на байт код перла.

Байт код перла. perl -MO=Bytecode -e '{print "Hello World!\n"}'

2Nik (*) (2002-08-16 09:39:57.822)

Это оч.серьезный показатель производительности. Если она на Hello World 16 мег жрет то как она на чем нить серьезном будет себя везти.

BOSHiK

2 BOSHiK:
Ты совсем не прав.
Рост занимаемой памяти идет совсем не линейно. Ты сначала посмотри на то о чем пишешь, а потом заявляй так категорично.
Вообще проблемы паняти imho на данный момент не существует. Каждый может легко позволить себе поставить 1-2Gb а этого хватит много на что. если же вместе с Servlets comtainer'ом на этой же машине и субд живет, то все-равно 2Gb хватит для очень большого круга задач. А когда не хатит, то Java решения тоже будут выигрышны - они очень хорошо масштабируются.

> Каждый может легко позволить себе поставить 1-2Gb

Вот ты точно не знаешь, о чем пишешь. 2Gb на 32битной системе поставишь
не на каждой. На линуксе можно, а на бсд нет. На линуксе работа с таким
объемом памяти обходится не бесплатно. Система работает медленнее.
А 64-битную платформу могут себе позволить далеко не все.
Идем далее. Жаба как известно очень чувствительна к лимиту на
количество открытых файлов. Опять же не на любой системе их можно
открывать бесконечно. А значит если у меня количество клиентов не
игрушечное, а порядка 500-1000, то жаба автоматически исключается как
вариант для стандартного железа. С другой стороны, зачем наращивать это
железо, если скажеи php легко справляется с таким объемом?