"Run PHP on the Google App Engine (http://www.webdigi.co.uk/blog/2009/run-php-on-the-google-app.../)" - запуск PHP скриптов в Google App Engine (http://www.opennet.me/opennews/art.shtml?num=21171), используя Quercus (http://www.caucho.com/resin-3.0/quercus/) - интерпретатор языка PHP, написанный целиком на Java. При измерении производительности Mediawiki и Drupal, Quercus оказался быстрее стандартного mod_php в 4 раза, продемонстрировав скорость близкую к mod_php с включенным акселератором APC.URL: http://www.webdigi.co.uk/blog/2009/run-php-on-the-google-app.../
Новость: http://www.opennet.me/opennews/art.shtml?num=21264
Гон! MediaWiki и Drupal зависят от SQL движка, которого в принципе нет в App Engine!
>Гон! MediaWiki и Drupal зависят от SQL движка, которого в принципе нет
>в App Engine!Да вот только в mediawiki есть поддержка нескольких различных БД, а следовательно и соответствующий уровень абстракции.
>Гон! MediaWiki и Drupal зависят от SQL движка, которого в принципе нет
>в App Engine!Это сравнивалось не на на АппЕнджайне, а на обычноv сервере
Caucho Resin (Quercus) против Apache + mod_php
Этим бенчам уже много лет и это одно из доказательств того, что джава не настолько медлее Си++ как это кажеться не которым "специалистам".
http://www.workhabit.com/labs/resin-backed-php-drives-4x-per...
Думаю, про скорость, а именно быстроту Явы никто не спорит. Раздражает тот факт, что каждая копия ява-программы подгружает свой набор (одних и тех же) биб-ек, из-за чего и нарекания в сторону прожорливости памяти явой. Яву бы научить безопасным shared биб-екам, понимаю, что песочница и всё такое, но всё же биб-ки, думаю, можно было бы сделать shared. Помнится, какие-то наработки в этой области были у Apple, и они вместе с Сан хотели привнести данные инновации в стандартный JSDK.
Спорщиков хватает, - типа User234, и попугаи которые повторяют за ним.
Это доказательство кривости неоптимизированного PHP-интерпретатора, о которой и так все знают - не зря же тот же APC сделан. А так - хоть Java VM, хоть Zend Engine - так или иначе, это интерпретация. При чем здесь C++?
Статическая компиляция против динамической. Шаред библиотеки, сборка мусора и динамическая компиляция не совместины. Джава как раз запускаяет один процес, а апач много процесов. Разрабочики джавы хотят по максимуму использовать память так как она сейчас стоит 15 баксов за гиг.Если веб сервер потребляет пямять на 5 долларов, то это не проблема.
Теоретически можно оптимизировать джаву потреблять менше памяти как это делает мобильная джава.
Глупости. Интерпретатор PHP один из самых вылизанных и накладные расходы на компиляцию мизерны, по сравнению с файловыми для include/require.
А вот судить о скорости выполнения в среде "жабы" могут говорить только авторы среды, потому как вряд ли кто-то, кроме них, лучше знает за счет чего есть выигрыш :)))