django - замечательная весчь :)

Интересно в том-же контексте посмотреть на Catalyst http://www.catalystframework.org/ просто там у него perl внутри... А то сравнение скриптовых язаков применяемых для разработки web-приложений выглядит не полным ;-)

гик, питон - быдлокодерство.
пыхпых правда тоже :)
настоящие (труЪ) пацаны пишут на сях

Без JAva как-то не прикольно. Как-то агрессию не стимулирует ;)

Си - тоже быдлокодерство. Настоящие (трупЪ) поцаны пробивают на перфокартах скомпилированный лисп-код.

Гон. PHP рвёт недоязыки как тузик грелку.

Как на PHP connection pool реализовать? Как я понял, pconnect - это всётаки не то что-то.

А чем pconnect не устраивает?

> PHP рвёт недоязыки как тузик грелку.

Недоязыки? Бугога. Кроме смеха подобные выражения вызвать ничего более не могут :)))))

А это... почему для рельсов сетап был на один пункт длиннее (апач->лайт->рельсы-fastcgi), а не сразу лайт->рельсы?

>А чем pconnect не устраивает? Ну если это pool, то как его настроить?

> А это... почему для рельсов сетап был на один пункт длиннее (апач->лайт->рельсы-fastcgi), а не сразу лайт->рельсы?

Они пробовали апач/mod_proxy_balancer->рельсы и lighttpd/fastcgi->рельсы, читай внимательнее. :)

А что понятие connection pool, подразумевает что его надо настраивать? Или всё таки возможность настроить это фишка конкретной реализации?

Судя, хотя бы вот по этому http://www.webopedia.com/TERM/C/connection_pool.html само понятие такого не подразумевает, так что pconnect вполне попадает под его определение.

Конечно, всякие вещи типа балансировки нагрузки, лимитирования числа соединений, переключения на резервный сервер и т.д. с помощю него не сделать, но по идее это должно настраиваться средствами СУБД.

всё забываю этот Django попробовать...

> гораздо быстрее

Ну и ге там гораздо? Между рор и джанго не такое уж большое различие. А если учесть что сам по себе руби действительно намного тормознее питона http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=python&... можно только похвалить роровцев:)

Для полного сравнения не хватает еще Perl, ASP, Parser, Java, Pike, Lua...

С другой стороны, не ко всем есть фреймворки, поэтому полное сравнение должно быть такое: PHP, Perl, Python, Ruby, Java, ASP.

Вот тогда пофлеймим.

Но и на этом авторам спасибо.

чушь какая то на 150 юзерах крутили Монгрель. Зачем апач с проксибалансером прикрутили не совсем ясно и чистоту экспиремента испортили. А учитывая, что Руби крутится аз из без как пхп акселераторов и как питон прекомпиляции, то я понимаю что РоР впереди планеты всей. Что и сам могу заверить. Кстати собираюсь открывать хостинг РоРа, а то что то в России провы чухают с этим по полной, идиоты. РоР пока еще показывает только свою мощь архитектуры, а когда сюда влезут игроки помощнее и прикрутят прекомпиляторы, жит-компилеры и прочие аксселераторы, то я это будет единственная платформа.

Давно мечтаю о единой платформе, только вот их (платформ) с каждым днем все больше и больше.

>то я это будет единственная платформа

Гыы мечтатель :)

<quote>
Судя, хотя бы вот по этому
http://www.webopedia.com/TERM/C/connection_pool.html само понятие
такого не подразумевает, так что pconnect вполне попадает под его
определение.
</quote>

То, что это pool я уже понял :) просто отсутствие возможности как
следует его натроить погает. Страшно как-то пользоваться тем,
характеристики чего тебе не ясны. Сколько времени невостребованное
соединение будет держаться? Какое максимальное количество соединений разрешено? Сколько соединений надо всегда держать открытыми, даже
если они не востребованны? Сконфигурировать эти параметры на уровне базы данных на большинстве хостингов не получится, так как никто
такого доступа не даст ( или я не прав? ). А от этого зависит
эффективность конкретного приложения и идеальные циферки в разных
случаях будут разные.

таки lua всех порвет. хороший язык.

> таки lua всех порвет. хороший язык.

Вряд ли. Вот простой тест нужно было написать с выводом списка UNIX
окружения... и я так и не нашёл соответствующей функции в lua. Есть
только os.getenv(keyword), а нужна вся таблица.

Аналог на php:

foreach($_ENV as $key => $val)
{
echo $key." = ".$val."\n";
}

Попробовал cgilua использовать... чуть не стошнило на клаву.
Но интерпретатор lua на первый взгляд очень быстрый. Хотя это
ни о чём не говорит. На большом приложении он вполне может стать
очень медленным.

> PHP рвёт недоязыки как тузик грелку

Не знаю кого способен порвать PHP, но буквально неделю назад в обсуждении новостей Sun-ch'у было показано что его жестоко обманули сказав что python сливает пыхпыху на конкретных примерах. На сколько я помню, python 2.4 делал пыхпых 5.1.4 на расчете факториала 100 в цикле почти что в 2 раза.
Наверное это бы и был - кто Sun-ch'у напел :)

> Зачем апач с проксибалансером прикрутили не совсем ясно и чистоту экспиремента испортили

Согласен. Тестировали apache против lightpd, что абсолютно некорректно.
Смотрим http://www.lighttpd.net/benchmark/ и читаем вывод:

lighttpd + fastcgi более чем на 25% шустрее чем apache + mod_php4.
Для статики lighttpd быстрее apache в 4-6 раз.

Смело добавьте эти 25% к результатам php-фрэймворка. Кстати, я не знаю,
какого качества этот фрэймворк, я с ним не сталкивался.

> python 2.4 делал пыхпых 5.1.4 на расчете факториала 100 в цикле почти что в 2 раза.

А Haskell GHC с Ocaml'ом на тех же тестах вообще рвут всех, включая C++.
Только о чём это тебе говорит? Может быть ты всё бросил и побежал писать
веб-приложения на haskell? Проблема этих тестов в том, что они
синтетические и с реальностью имеют очень мало общего.

Я пробовал писать веб-приложения почти на всём, что перечислено на
shootout.alioth.debian.org. Тока откатился на php, хотя никакого
восторга по оотношению к нему не испытаваю. Просто всё остальное ещё
хуже по совокупнному набору качеств!

> Для полного сравнения не хватает еще Perl, ASP, Parser, Java, Pike, Lua

Мне нужен был максимально быстрый интерпретатор для скриптов в режиме
CGI (форк на каждый запрос).
Я тестировал php5, perl, phyton, ruby, pike, lua, newlisp. Мне был
интересен pike в первую очередь, и на синтетических тестах он якобы
лучший был, но в cgi-режиме он оказался самой тормозной черепахой.
Тестировал ruby. Тест "Hello, world!" показал неплохие результаты -
вдвое быстрее php5! Я уж было обрадовался. Но, первое же подключение
файла стандартной библиотеки (require 'date') снизило скорость
исполнения скрипта втрое!!! А подключение второго файла (require 'cgi')
снизило скорость ещё вдвое! На этом фоне php показался просто супер
скоростным ;) Так что меряйте скорость на чём-то реальном, и не верьте
синтетическим бенчмаркам.

>А Haskell GHC с Ocaml'ом на тех же тестах вообще рвут всех, включая C++.

На любом языке можно писать неэффективный код ;) Разница в том, что некоторые языки позволяют улучшить узкие места прозрачно, а в некоторых это делается через жопу..

Ответы на все вопросы. http://ru.php.net/manual/en/features.persistent-connections.php

А то что его сконфигурить нельзя, это да плохо, ну что ж поделаешь. Хотя в 90% (может даже в 99%) случаев для которых сейчас используется PHP это нафиг не нужно.

> Мне нужен был максимально быстрый интерпретатор для скриптов в режиме
CGI.
как то слова максимально быстрый и CGI мягко говоря не дружат ...
зачем тратить большую часть процессорного времени на запуск и от ставшейся части требовать быть максимально быстрой ?

>(форк на каждый запрос)
CGI это exec на каждый запрос, форк это mod_...

> На этом фоне php показался просто супер
скоростным ;) Так что меряйте скорость на чём-то реальном, и не верьте
синтетическим бенчмаркам.
только в реальных задачах где нужна максимальная производительность CGI режим мало кому нужен, там больше статические языки и треды популярны
а если мы не второй ebay делаем то и mod_[язык которой нравится] сойдет

> На любом языке можно писать неэффективный код ;)

Да, а ещё на любом языке можно написать никому не нужный / нигде не
встречающийся в реальных приложениях код ;) Как по вычислению факториала
можно судить о производительности CMS, например? Я не знаю. А вы?

> как то слова максимально быстрый и CGI мягко говоря не дружат ...

Тесты (реальные) говорят об обратном. Разница в производительности между
apache+mod_xxx и лёгкий вебсервер (типа lighttpd, mathopd) + CGI на
приложениях, обращающихся к БД минимальна. Большую часть времени
приложение проводит в общении с базой данных.

> зачем тратить большую часть процессорного времени на запуск и от ставшейся части требовать быть максимально быстрой ?

Причины могут быть такие:

- Ограничения по памяти на миниустройствах. mod_xxx отжирает её слишком много.

- Безопасность исполнения на хостинге в условиях множества
пользователей. CGI скрипты легко запускать под разными uid.

> CGI это exec на каждый запрос, форк это mod_...

Ответ неправильный. На самом деле это fork+exec.

> только в реальных задачах где нужна максимальная производительность CGI режим мало кому нужен

Нужна максимальная производительность в режиме _CGI_. Что не понятно
в этой фразе?

В настоящее время быдлокодерствую на PHP над одним проектом, как раз на Symfony. О Django не слышал, а вот за RoR хотел браться. Но т.к. времени было мало и на изучение Python/Ruby тратить его возможности не было - был выбран PHP. Пока не жалею, фреймворк очень неплохой.

Выбирая между RoR и Django в свое время выбрал последний. Быстро, красиво, удобно да еще и на питоне.. Правда потом хостинг найти посложнее чем для RoR..

PHP не перевариваю. Ну просто не укладывается он в моей голове особенно $this->instance_var

> не укладывается он в моей голове особенно $this->instance_var

Первый раз вижу такой странный довод против php. В чём конкретно
проблема? У меня укладывается.

> Просто всё остальное ещё хуже по совокупнному набору качеств!

Странно. Для подавляющего большинства студий выбор PHP совсем иной. Просто он установлен на 99% хостинга. А perl, RoR, Python или ASP, будь они хоть в десять раз скоростнее - нет. В результате - не зачем тратить время и ресурсы на программу, которая пойдет не у всех. Только и всего. Скорость.. скорость оптимизируется. Доказано... мной :)

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

newlisp?

а что newlisp? как он себя показал в ваших тестах?

> Ну и ге там гораздо? Между рор и джанго не такое уж большое различие.

Цитата:

Rails performed much better than Symfony. And Django performed much better than Rails.

Так что это я не сам придумал, все претензии к авторам. :)

А что народ может сказать о Prado? (http://www.pradosoft.com/)

P.S. "Аффторов" просьба не беспокоиться. Меня интересует мнение именно среди php фреймворков, например в сравнении с тем же Symfony...

> а что newlisp? как он себя показал в ваших тестах?

Он лучший, если не считать lua. На простых тестах скорость минимум вдвое
выше, чем у аналогичных php-скриптов. Вообще он мне понравился, но
сырость всё же ощущается. Особенно удивило наличие исключений в виде
destructive function. Выглядит как грязный хак. Мысль в этом языке
заложена правильная, но реализация пока хромает.

> Странно. Для подавляющего большинства студий выбор PHP совсем иной.

Да мне как-то плевать на большинство, да тем более вебстудий. Я делаю
исследование для себя с целью поиска наиболее подходящих платформ для
быстрой у удобной разработки веб-приложений, с оглядкой, конечно, на
возможности провайдеров. Скажу по секрету: слухи об убогости php сильно
преувеличены ;) Да, он противоречивый местами. Да, он факториал медленно
считает ;-) Но пойдите найдите что-то более подходящее для малых и
средних по величине веб-проектов... По срокам разработки, по наличию
готовых библиотек, по известности, по производительности, по лёгкости
втиснуть на любой хостинг. И вы поймёте, что ближайшие конкуренты как
минимум на шаг позади.

> Скажу по секрету: слухи об убогости php сильно преувеличены ;)

Но таки зачем писать на PHP, если есть нормальные языки? :)

> Но таки зачем писать на PHP, если есть нормальные языки? :)

Нормальные? Определение нормальных языков в студию. Это те, где
факториал быстро считается? А мне оно надо? Я клал на синтетическиие
тесты. Это писькомерки. Когда дело доходит до реальных приложений,
они сливают. Или те, где якобы разработка быстрее и приятней?
Так я давно не пишу на голых языках. Я работаю с библиотеками.

И что, у того же Питона мало библиотек? =)

А нормальные языки - это предначенные для программирования, а не для клепания мелких домашних страничек. Надеюсь, никто не будет утверждать, что программировать на PHP приятнее, чем на Питоне или Руби?

> Я клал на синтетическиие тесты. Это писькомерки.

Понимаю, что PHP ваше всё, но в статье по ссылке "подробности" как раз и обсуждаются реальные тесты, а не синтетические писькомерки. Вы таки статью прочитали?

> Вы таки статью прочитали?

Превнимательнейшим образом. Вы считаете тесты реальными?
А я считаю, что для реальности им вот чего нехватает:

1) исходных текстов
2) сравнения по времени, затраченному на написание программы
3) объяснения рокировке apache -> lighttpd для RoR.
4) объяснения выбора php-фрэймворка из десятков подобных, среди которых
есть гораздо более известные, например, cake - близкий аналог RoR.

Нда, молодой человек. Исходя из ваших фраз получается что таки платформу (ну или язык) вы выбрали не исходя из реальных его достоинств или недостатков, а исходя из простоты найти под него хостинг.
Может конечно расчет факториала и писькомерка, но эта писькомерка явно показывает что считает питон быстрее пыхпыха в разы. А то, что реальные веб-приложения тратят основное время на работу с БД - это если мы про пых пых бебе говорим или про хомяк васи пупкина, то это да. А если про что-то более иное, то это далеко не всегда истина.
Любой фреймворк - это в первую очередь тонна кода, которую ЯП должен уметь быстро переваривать и если подойти к проблеме писькомерок с этой стороны, то писькомерки перестают быть такими уж бесполезными и произвоительность самого ЯП начинает играть тоже определенную роль.

Именно поэтому после многих лет писания кода на php, лично я уже года полтора как полностью перешел на python, о чем еще ни разу не пожалел. А выбор хостинга на самом деле не такая уж и проблема, если бюджет на хостинг превышает 5 баксов в месяц. А для более-менее серьезных проектов это так и есть. В конце концов VDS/VPS сегодня тоже достаточно дешев.

> никто не будет утверждать, что программировать на PHP приятнее, чем на Питоне или Руби?

Я буду утверждать, что понятие "приятно" субъективно, и для каждого
программиста имеет очень разное наполнение... Мне _не приятно_
программировать на python. А нужных мне библиотек на ruby мало, и при
этом программмирование на ruby я так же не назвал бы очень приятным.
Оно просто сносное.

> сравнения по времени, затраченному на написание программы

Вот как раз тут Rails и Django однозначно вне конкуренции. Хотя, конечно, счётчик посетителей для мелкой домашней странички быстрее сделать на PHP, не спорю. :P

> объяснения рокировке apache -> lighttpd для RoR

Вы таки читали? RoR они тестировали и под апачем (88.15 trans/sec), и под lighttpd (85.33 trans/sec). Но под&#12288;более&#12288;высокой нагрузкой lighttpd начал выдавать "500 Internal Server Error и нии%ёт".

> объяснения выбора php-фрэймворка из десятков подобных

Да ётить, ну какой-то же фреймворк им надо было выбрать! Если Вы считаете, что cake мог бы выдать лучшие результаты, то мы с нетерпением ждём Ваших тестов.

А вот исходники, согласен, могли бы выложить.