metaclass | Кто-то тупой, или я или гвозди

Кто-то тупой, или я или гвозди

Сижу изучаю различные варианты реализации middle-tier, который планируется использовать в будущем для нескольких проектов. Решил пересилить свой страх и взглянуть на J2EE. А надо сказать, что для неподготовленного ума ентерпрайз жаба выглядит совершенно ирреально бредовой: миллиарды фреймворков, утилит, серверов, сотни страниц документации, проекты на ней содержат over 9000 папок и мелких исходников и xml-конфигов и вообще я не уверен, что в здравом уме и имея некую начальную свободу выбора инструментов, с этим стоит вообще связываться.

Начал искать что-нибудь вроде "J2EE для начинающих с пошаговыми инструкциями". Нашел AppFuse. Вроде все описано понятно, есть QuickStart, написано откуда качать зависимости, итд, итп. Но таки вы будете смеятся - но я не могу найти, где качать исходники этого дела. Ссылки "Download" на сайте нету.

Я, конечно, счас попытаюсь произвести описанные там вуду-ритуалы, может мавен тот все что нужно сам скачает, но то, что начинать приходится с вуду-действий, как-то печалит.

Вообще говоря, у меня уже есть почти полностью готовая основа для этого миддл-тиера, на которой я бы проект сделал очень быстро: Firebird+Delphi+ASP.NET RESTful веб-сервис. Но проблема в том, что это означает полную и окончательную привязку проектов к виндам, отказ от любых потенциальных работ с юниксами в будущем и сгнаивание мозга до состояния "сеньор-фокспро-девелопер в ВЦ НИИ Говна и Торфа, 50 лет, 30 лет опыта рисования формочек в дизайнере".

Кроме того, если дать объявление "требуется разработчик на дельфи" - приходят такие долбаные мышевозы с паттернами "magic button" что рыдать хочется, соответственно шансов на то, что хотя бы когда-нибудь я займусь только архитектурой и управлением проектами, вместо того, чтобы самостоятельно писать код, внедрять и обслуживать - не останется никаких.

PS: Есть кстати, еще одна, еще более неадекватная альтернатива: сойти с ума и ударится в нетривиальщину вроде ерланга и хаскеля, начать писать самодельный миддл-тиер на чистом С и изобретать прочие велосипеды. То, что это гарантированно будет легче для нервной системы, чем J2EE и ASP.NET, я уверен. Там комьюнити меньше и не будет такого, что половина интернетов забита разнообразными фреймворками, каждый из которых настолько наворочен, что позволяет не писать код, а всего лишь парой сотен xml-конфигов сделать любое приложение.
Я вспоминаю 90-е годы, когда никаких интернетов не было, проекты были более мелкие и выбора "на чем писать" особо не было, можно было велосипеды изобретать хоть годами.

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

Вот, к примеру: я считаю, что любой, кто сталкивался с статической типизацией и выводом типов, резко перестанет делать проекты "мегапереконфигурируемыми" с помощью сотен xml-конфигов, т.к. это выносит проверку правильности с времени сборки на время деплоймента и запуска. Ошибся в xml-файле в одной букве и вешайся, читай 100-строчные стеки вызовов и это еще хорошо, если у тебя доступ к продакшен-серверу есть.

Flat | Top-Level Comments Only

Если у вас «внезапно» стало 600 запросов в секунду, и все они дошли до серверов приложений, то как это не прискорбно, вы идиот.

Digg-эффект. Хабра-эффект и т.п. Насчет того что оно будет не с 0 я в курсе.

Притом будь на месте сервера приложений ява, если у вас резко с 1го запроса в секунду произойдет рост до 600 — будет все то же самое.

И что же будет? Просто если вы попробуете взять jmeter и тестировать к примеру самую простую вещь типа hello world, то к примеру при сравнении php и java происходит такая хитрая загогулина, до 100 соединений php отдает быстрее. После 100 php начинает отдавать медленнее и жрать больше памяти и разброс на времени отклика начинает увеличиваться. Java при это работает ровно так же как и до этого работала. Увеличение до 600 соединений практически не влияет на производительность, хотя php уже дохнет.

А касаемо интерпретатора, вас плохо информировали. Сервер приложений интерпретирует код однократно. В момент запуска. То, что само исполнение бинарного опкода медленнее чем у сопоставимой явы факт. Но интерпретация тут не при чем.

Я имел ввиду весь комплекс интерпретатор + ВМ.

Кстати, опять же подождем пока в яве появятся замыкания. А там и сравним скорость :)

Думаете у java при этом станет хуже или допилят Ruby? :]

Дигг/хабра-эффект являются частным случаем DDoS. С которым принято бороться не наращиванием способности сервера приложений проглатывать все запросы, какие только подадут на вход, а настройкой маршрутизаторов, load балансеров и прочего. Да конечно же, не упасть под пиковым интересом пользователей к сайту это правильно. Но вопрос в том, что у любого проекта есть бюджет. Который основывается в конечном счете на реальных платежеспособных пользователях, а не на толпе праздно шатающихся интеллектуалов. Под этот бюджет выбирается обычно решение. Знаете, есть такой термин TCO?
Про рост со 100 запросов в секунду до 600 — очень умозрительно. Во-первых, хотелось бы посмотреть пример в котором это так, который я могу воспроизвести (притом желательно не hello world, а реальный бизнес пример). Во-вторых, если такового нет (а в целом и если есть) хотелось бы услышать объяснение почему, на ваш взгляд, это так?
Про «весь комплекс», такое ощущение, что вы отвечаете на слова, которые забыли прочитать. Я вам объясняю, почему интерпретатор не участвует в обработке запросов, вы мне рассказываете про скорость «всего комплекса».
А про станет ли ява хуже, я не знаю. Ровно как и не знаю станет ли она хуже от покупки Ораклом Сана. Я знаю, что это вещь которая сейчас уже есть в руби, но которая является новым marketing b-s для явы.

Знаете, есть такой термин TCO?

Знаю-знаю. Я просто считаю, что если человек полез в java то у него там явно возможны хорошие нагрузки.

Про рост со 100 запросов в секунду до 600 — очень умозрительно.

Был чисто прикидочный тест, что лучше.

Во-первых, хотелось бы посмотреть пример в котором это так, который я могу воспроизвести (притом желательно не hello world, а реальный бизнес пример).

Ну бизнес пример это думать надо :)

Во-вторых, если такового нет (а в целом и если есть) хотелось бы услышать объяснение почему, на ваш взгляд, это так?

Почему вышло так как раз таки есть объяснение. Разница в используемых моделях. В php это CGI модель, когда все каждый раз заново инициализируется. В случае же java инициализация сервлета делается ровно один раз при его старте. Далее при подключении генерируется отдельный поток который обрабатывает это соединение. Как только обработка завершается, он может обработать следующее и т.п. Ограничить количество потоков и объем потребляемой памяти возможно. Как результат такая модель хороша когда соединений много, иначе получается типичный вариант стрельбы из пушки по воробьям.

Я вам объясняю, почему интерпретатор не участвует в обработке запросов, вы мне рассказываете про скорость «всего комплекса».

Почему интерпретатор там не учавствует, я вполне понимаю.

Т.е. не человек полез в яву в поисках решения для 600 запросов в секунду (sic!), а ява обязывает.
Чисто прикидочный тест, это да. Измерение длинны пениса у сферического коня в вакууме. Пользы столько же.
Думать, к вопросу о примерах, вообще полезно. Я вот сходу не могу назвать ни одной сферы, где дешево и с наскоку нужно обеспечивать 600 запросов в секунду. Зато помню как первый год работал ticket.rzd.ru написанный на вашей хваленой яве.
Ваши объяснения хорошо сопряжены с прошлыми частями беседы. Сразу видно, как вы владеете ситуацией в современной разработке. Могу например посоветовать вам ознакомиться с такой новой и нигде еще не используемой технологией как FastCGI.
Про многопоточность, это имеет свою роль несомненно, но увы не является чем то для явы уникальным. Более того, сам факт наличия потоков создает кучу дополнительных проблем как для разработчиков платформы, так и для тех, кто пишет для нее код.
А про ваше понимание про интерпретатор, тем хуже, если вы понимаете, но продолжаете использовать его в качестве аргумента. В этом случае вы либо идиот, либо пиздюк пытающийся отбрехаться первым придуманным аргументом в расчете на то, что оппонент не владеет обсуждаемым вопросом.

Т.е. не человек полез в яву в поисках решения для 600 запросов в секунду (sic!), а ява обязывает.

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

Я вот сходу не могу назвать ни одной сферы, где дешево и с наскоку нужно обеспечивать 600 запросов в секунду. Зато помню как первый год работал ticket.rzd.ru написанный на вашей хваленой яве.

В яве тоже далеко не все гладко. И налажать в ней из-за того что писал автор (дофига-дофига всего) тоже можно легко.

Могу например посоветовать вам ознакомиться с такой новой и нигде еще не используемой технологией как FastCGI.

Про FastCGI я знаю. Но вопрос тогда стоял php или таки java (товарища которого это интересовало пишет на java), а вот от FastCGI в php толку ноль. Он эту модель в чистом виде не подддерживает.

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

Не является.

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

Конечно. И это не всегда надо.

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

В качестве какого аргумента? Что Ruby на данный момент не сильно быстро работает?

То, что вы не знаете, как подружить php с fastcgi не значит, что их нельзя подружить. Сайтов которые этим пользуются до жопы.
А про аргумент я все тот же — интерпретатор.

То, что вы не знаете, как подружить php с fastcgi не значит, что их нельзя подружить. Сайтов которые этим пользуются до жопы.

FastCGI подразумевает наличие демона который ожидает соединения и обрабатывает его. В случае php fastCGI это не так. Используется враппер который через FastCGI запускает обычные php скрипты. Т.е. любой сайт который запускается при помощи php-cgi или mod_php можно запустить и там. Причем без модификации. Я помню только одну единственную реализацию которая реально изображает FastCGI.

FastCGI подразумевает наличие демона который ожидает соединения и обрабатывает его. В случае php fastCGI это не так.

Эти два утверждения логически противоречивы.
Если подразумевает, значит, демон есть.
Видимо, в случае с PHP он тоже есть.

Используется враппер который через FastCGI запускает обычные php скрипты.

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

Видимо, в случае с PHP он тоже есть.

Не ввиде приложение, а в виде самого php.

Что как бы говорит нам, что нет никакой особой нужды в использовании PHP под FastCGI, он и под Apache работает ровно точно так же.

Дык я на это и намекаю. Что модель то та же остается. То что у нас есть демон который конвертит FastCGI в CGI мало что меняет.

Не ввиде приложение, а в виде самого php.

Ну, может оно и к лучшему.

Дык я на это и намекаю. Что модель то та же остается. То что у нас есть демон который конвертит FastCGI в CGI мало что меняет.

Я все равно не понимаю, при чем здесь CGI.
CGI здесь совсем не при чем.
mod_php никакого отношения к CGI не имеет.

Ну, может оно и к лучшему.

Вот в случае PHP это точно.

Я все равно не понимаю, при чем здесь CGI.

CGI подразумевает, что при приходе запроса активируется скрипт и ему кормятся параметры в формате CGI после того как он отдает ответ он умирает. В mod_php если нет акселератора даже код не сейвится скомпилированный, т.е. да мы имеем php в памяти что позволяет не запускать его каждый раз, но скрипт то запускается каждый раз заново, как это делается при CGI.

Правильно, вам просто нужно в сочетании с php-fastcgi использовать eaccelerator. В этом случае второй решит проблему однократной генерации байт-кода, а второй проблему демонизации.
Однако мы отклонились от темы. В случае с рельсами это работает из коробки на стандартном mongrel_cluster.

yep. Только FastCGI в чистом даже php-fastcgi с акселератором не дает. Сугубо говоря если я в скрипте открою соединение, то в конце скрипта оно закроется.

В случае рельсво действительно так.

В php это CGI модель, когда все каждый раз заново инициализируется.

Сегодня в этом обсуждении просто праздник какой-то!
Это где же в PHP CGI-модель, я прошу прощения?
А что тогда такое mod_php?

Это где же в PHP CGI-модель, я прошу прощения?
А что тогда такое mod_php?

А что в случе mod_php у нас скрипт каждый раз заново не выполняется да?

Выше было написано слово "инициализируется", а не "выполняется".
Нет, не инициализируется заново каждый раз.
А что, разве в случае java сервлет каждый раз заново не выполняет обработчик запроса?
Я думал, именно в этом смысл динамической обработки.

В скрипте все переменные инициализируются заново. Если не используется pconnect то каждый раз производится переподключение к базе данных. Разница между php-cgi и mod_php в том что во втором случае php у нас висит в памяти и когда надо форкается и выполняет скрипт к которому обратились. Причем если нет акселератора, код особо не кешируется.

В скрипте все переменные инициализируются заново.

Так а разве FastCGI нужен для того, чтобы переменные заново не инициализировались?
Я думал, чтобы не делать fork и чтобы файлы каждый раз с диска не читать.

Если не используется pconnect то каждый раз производится переподключение к базе данных.

Да и фиг бы за этим.
pconnect в тех конфигурациях, которые в вебе встречаются, вообще не нужен.

Разница между php-cgi и mod_php в том что во втором случае php у нас висит в памяти и когда надо форкается и выполняет скрипт к которому обратились.

В какой это он памяти висит и куда форкается?
Я бы даже так сказал - а зачем это он форкается, если он уже в памяти висит?
Разница между php-cgi и mod_php, как мне кажется, совсем не в этом.

Причем если нет акселератора, код особо не кешируется.

А что такое акселератор?

Так а разве FastCGI нужен для того, чтобы переменные заново не инициализировались?
Я думал, чтобы не делать fork и чтобы файлы каждый раз с диска не читать.

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

pconnect в тех конфигурациях, которые в вебе встречаются, вообще не нужен.

Нужен нужен.

В какой это он памяти висит и куда форкается?
Я бы даже так сказал - а зачем это он форкается, если он уже в памяти висит?

Чтобы выполнить скрипт, зачем же еще. Это причем не он сам, а apache.

Разница между php-cgi и mod_php, как мне кажется, совсем не в этом.

В чем?

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

Состояние?
Я бы опасался держать состояние в FastCGI-демоне.
Это, все-таки, ресурсы, а не состояние.
Но PHP все ресурсы, фактически, подтягивает через расширения движка.
PHP - это клей.
Соответственно, все зависит от того, насколько эффективно работают расширения, тот же pconnect, например, не на уровне же PHP-кода пул держит.

Нужен нужен.

Зачем?

Чтобы выполнить скрипт, зачем же еще. Это причем не он сам, а apache.

Apache форкается вовсе не для того, чтобы выполнить скрипт.
Он форкается, чтобы обработать запрос, а уж что там входит в обработку запроса - это не дело процесса-родителя. Поэтому, в частности, Apache точно так же будет форкаться и на отдачу статики. Или не будет форкаться, если воркеров достаточно.
Ровно так же, как и в случае фермы FastCGI-обработчиков.
Разницы никакой.

В чем?

В том, что в случае mod_php PHP подтянут в адресное пространство Apache в виде библиотеки. И никуда ему форкаться, вообще говоря, не надо, он и так уже здесь.

А что такое акселератор?

xcache, apc и т.п.

Я не про названия.
Акселератор - это такая библиотека, которая использует разделяемую память.
Если бы PHP форкался, как Вы говорите, в случае использования mod_php, то, для использования разделяемой памяти нужен был бы процесс-родитель php.
Тем не менее, если на машине запущен apache с mod_php, никаких процессов php на ней нет.
Это как бы говорит нам, что php не форкается.

если php собран в mod_php и он работает как часть apache то с чего мы его увидим? Апач то как раз таки форкается активно.

(no subject)

alexclear.livejournal.com - 2009-12-17 15:11 (UTC) - Expand

(no subject)

norguhtar.livejournal.com - 2009-12-17 15:21 (UTC) - Expand

600 запросов в секунду это никакой не хабраэффект.
И даже не digg-эффект, я так полагаю.

Чисто как пример приведено.

Flat | Top-Level Comments Only