Наткнувшись на рекомендацию хостинг-провайдера по конфигурации различных облачных серверов в зависимости от используемого типа ПО я как-то сильно озадачился.
Для вроде как шустрой и такой оптимальной Java рекомендуется фактически в 2 раза больше памяти и в 2 раза более шустрый процессор чем для куда более тормознутого Ruby или PHP. Откуда у подобной ситуации ноги растут? Исходя из своего опыта с Java, единственное что мне приходит в голову это тотальный over architecture большинства Java решений, что приводит к в 2 раза более высоким требованиям при более производительном коде.
Какие еще могут быть причины такой занятной рекомендации?
Re: Java, Ruby, PHP и рекомендации к облачным хостам
Здравствуйте, kaa.python, Вы писали:
KP>Наткнувшись на рекомендацию хостинг-провайдера по конфигурации различных облачных серверов в зависимости от используемого типа ПО я как-то сильно озадачился.
у нас был продукт, значительная часть которого написана на руби. руби тормоз по жизни и увеличение тактовой частоты вдвое поднимает производительность рельсов едва ли на 10%. с другой стороны, Java намного чувствительнее к частоте и есть смысл пускать ее на быстрых камнях. а вот для рельсов быстрый камень это деньги, выброшенные на ветер.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re: Java, Ruby, PHP и рекомендации к облачным хостам
А тебя не смущает, что для Явы дискового места "требуется" почти в 2 раза больше?
А полоса пропускания в 2 раза больше?
Обычное сегментирование рынка. Если назначить одинаковые условия, то и брать придется одинаково. ПХП — нищеброды, с них много не возьмешь, да и конкуренция ПХП хостингов большая. Рубисты — просто продвинутые ПХПшники. Приходится доить джавистов, но чтобы появились основания, завысим требования.
Re[2]: Java, Ruby, PHP и рекомендации к облачным хостам
Здравствуйте, мыщъх, Вы писали:
М>у нас был продукт, значительная часть которого написана на руби. руби тормоз по жизни и увеличение тактовой частоты вдвое поднимает производительность рельсов едва ли на 10%. с другой стороны, Java намного чувствительнее к частоте и есть смысл пускать ее на быстрых камнях. а вот для рельсов быстрый камень это деньги, выброшенные на ветер.
Судя по рекомендации, Java выдает производительность равную Ruby на в два раза более мощном железе. Допустим, если дальше у Ruby прироста не будет, а Java покажет замечательный рост производительности, это не отменяет изначального вопроса — с чего вдруг более быстрая Java требует ощутимо больше ресурсов чем тормоз-Ruby.
Да, а ты не натыкался на статистику по скорости роста производительности языков при увеличении мощности железа?
Re[2]: Java, Ruby, PHP и рекомендации к облачным хостам
Здравствуйте, avpavlov, Вы писали:
A>Обычное сегментирование рынка. Если назначить одинаковые условия, то и брать придется одинаково. ПХП — нищеброды, с них много не возьмешь, да и конкуренция ПХП хостингов большая. Рубисты — просто продвинутые ПХПшники. Приходится доить джавистов, но чтобы появились основания, завысим требования.
Есть ещё такая вещь, как "quality of service". Мне в таком ключе когда-то отвечали на тему "почему java-хостингов мало": потому что там не детишки в песочнице играются, сама платформа более требовательна к пряморукости, и требования к качеству хостинга тоже гораздо выше, а нафига хостерам этот геморрой.
Re[2]: Java, Ruby, PHP и рекомендации к облачным хостам
Здравствуйте, avpavlov, Вы писали:
A>А тебя не смущает, что для Явы дискового места "требуется" почти в 2 раза больше? A>А полоса пропускания в 2 раза больше?
Нет, не смущает. В тех тарифных планах, если прибавить производительность процессора или объем памяти, то "в нагрузку" добавится дисковое пространство и/или полоса пропускания.
A>Обычное сегментирование рынка. Если назначить одинаковые условия, то и брать придется одинаково. ПХП — нищеброды, с них много не возьмешь, да и конкуренция ПХП хостингов большая. Рубисты — просто продвинутые ПХПшники. Приходится доить джавистов, но чтобы появились основания, завысим требования.
Я правильно понял, что ты утверждаешь что однотипный сайт (веб-приложение) на Java пойдет на аналогичном железе со скоростью не ниже чем если бы он был написан на Ruby/PHP?
Re[3]: Java, Ruby, PHP и рекомендации к облачным хостам
KP>Нет, не смущает. В тех тарифных планах, если прибавить производительность процессора или объем памяти, то "в нагрузку" добавится дисковое пространство и/или полоса пропускания.
Ну если ты готов признать, что два показателя хостинга не имеют отношения к производительности Явы, то почему ты не готов признать, что остальные тоже не имеют?
KP>Я правильно понял, что ты утверждаешь что однотипный сайт (веб-приложение) на Java пойдет на аналогичном железе со скоростью не ниже чем если бы он был написан на Ruby/PHP?
А с чего бы это JSP странице (оставим уж голые сервлеты в сторонке) быть медленнее PHP страницы? Учитывая, что в Яве JIT предмет постоянной многолетней оптимизации?
Re[4]: Java, Ruby, PHP и рекомендации к облачным хостам
Здравствуйте, avpavlov, Вы писали:
A>Ну если ты готов признать, что два показателя хостинга не имеют отношения к производительности Явы, то почему ты не готов признать, что остальные тоже не имеют?
Готов. Но с учетом того, что я не первый раз вижу рекомендации использовать для Java более производительные хосты, нежели чем для Ruby, допускаю что это не с проста и не только маркетинговая уловка.
A>А с чего бы это JSP странице (оставим уж голые сервлеты в сторонке) быть медленнее PHP страницы? Учитывая, что в Яве JIT предмет постоянной многолетней оптимизации?
Единственный вариант пришедший мне в голову я написал в первом посту — резмерное увлечение архитектурой со стороны Java разработчиков и как следствие слишком навороченные решения.
Re[5]: Java, Ruby, PHP и рекомендации к облачным хостам
KP>Готов. Но с учетом того, что я не первый раз вижу рекомендации использовать для Java более производительные хосты,
Сколько из этих раз сопровождались объяснением, почему требуются более производительные компы? Думаю, что ни разу.
KP>Единственный вариант пришедший мне в голову я написал в первом посту — резмерное увлечение архитектурой со стороны Java разработчиков и как следствие слишком навороченные решения.
Ну это же не проблема Ява-платформы и/или её производительности. На Яве межно писать и без чрезмерного увлечения архитектурой и делать в меру навороченные решения
Re: Java, Ruby, PHP и рекомендации к облачным хостам
Здравствуйте, kaa.python, Вы писали:
k> Исходя из своего опыта с Java, единственное что мне приходит в голову это тотальный over architecture большинства Java решений, что приводит к в 2 раза более высоким требованиям при более производительном коде. k> Какие еще могут быть причины такой занятной рекомендации?
У меня опыт не написания, а обслуживания (читай хостинг) некоторых веб-приложений на Java, среди которых всякие Jira, Confluence, Fish-Eye и различные "самописные" приложения. Так вот, они реально жрут CPU и RAM как "не в коня корм" (отожрать гигов 5 и свалиться с OOM — для них милое дело) даже на очень слабой нагрузке и объемах данных. В то же самое время, рядом стоящий redmine, написаный на ruby спокойно работает под виртуалкой в 256 метров.
Является ли это "over architecture" — не знаю, но когда я слышу что-то типа "у нас приложение на Java, прикиньте конфигурацию сервера", то я смело умножаю память раза в 3 и помощнее CPU и очень часто не хватает и этого.
Здравствуйте, Anton Batenev, Вы писали:
AB>У меня опыт не написания, а обслуживания (читай хостинг) некоторых веб-приложений на Java, среди которых всякие Jira, Confluence, Fish-Eye и различные "самописные" приложения. Так вот, они реально жрут CPU и RAM как "не в коня корм" (отожрать гигов 5 и свалиться с OOM — для них милое дело) даже на очень слабой нагрузке и объемах данных. В то же самое время, рядом стоящий redmine, написаный на ruby спокойно работает под виртуалкой в 256 метров.
AB>Является ли это "over architecture" — не знаю, но когда я слышу что-то типа "у нас приложение на Java, прикиньте конфигурацию сервера", то я смело умножаю память раза в 3 и помощнее CPU и очень часто не хватает и этого.
AB>У меня опыт не написания, а обслуживания (читай хостинг) некоторых веб-приложений на Java, среди которых всякие Jira, Confluence, Fish-Eye и различные "самописные" приложения. Так вот, они реально жрут CPU и RAM как "не в коня корм" (отожрать гигов 5 и свалиться с OOM — для них милое дело) даже на очень слабой нагрузке и объемах данных. В то же самое время, рядом стоящий redmine, написаный на ruby спокойно работает в однопоточном неконкурентном режиме под виртуалкой в 256 метров.
см. выделенное
Jira хотя бы многопоточная, а остальные вообще другие задачи решают, и сравнивать их с Редмайном смысла нет.
Здравствуйте, Anton Batenev, Вы писали:
AB>У меня опыт не написания, а обслуживания (читай хостинг) некоторых веб-приложений на Java, среди которых всякие Jira, Confluence, Fish-Eye и различные "самописные" приложения. Так вот, они реально жрут CPU и RAM как "не в коня корм" (отожрать гигов 5 и свалиться с OOM — для них милое дело) даже на очень слабой нагрузке и объемах данных. В то же самое время, рядом стоящий redmine, написаный на ruby спокойно работает под виртуалкой в 256 метров.
В java, в java. Небось юзают бездумно эту гадость под названием JEE — rich, stateful и прочие страшные слова. Оттого и ресурсы жрёт. А сделали бы stateless на спринге — и всё было бы хорошо.
Re[3]: Java, Ruby, PHP и рекомендации к облачным хостам
Может быть и существуют проекты на Java, которые действительно мало кушают, шустро работают и т.д. Мне просто таких не встречалось, по этому предпочитаю перестраховываться.
Здравствуйте, avpavlov, Вы писали:
a> AB>У меня опыт не написания, а обслуживания (читай хостинг) некоторых веб-приложений на Java, среди которых всякие Jira, Confluence, Fish-Eye и различные "самописные" приложения. Так вот, они реально жрут CPU и RAM как "не в коня корм" (отожрать гигов 5 и свалиться с OOM — для них милое дело) даже на очень слабой нагрузке и объемах данных. В то же самое время, рядом стоящий redmine, написаный на ruby спокойно работает в однопоточном неконкурентном режиме под виртуалкой в 256 метров. a> см. выделенное
Не совсем понимаю выделенное? Однопоточный — ладно, понятно, prefork модель апача (как один из вариантов запуска), а почему неконкурентный-то — процессов же может быть сколь угодно?
a> Jira хотя бы многопоточная, а остальные вообще другие задачи решают, и сравнивать их с Редмайном смысла нет.
Похоже, что это требования, на которых она хотя бы как-то заведется и будет хоть что-то отвечать. В реальной же жизни даже чистая jira и 5-10 пользователей на 2GB памяти уже работать не могут. Вероятно, отсюда и пошло выражение "У вас все сделано через джиру".
a> В твоём случае или кривые плагины, или кривые руки админов, или и то и то вместе.
Предположим, плагинов нет. Jira жрет память. Какие ручки крутим?
AB>Не совсем понимаю выделенное? Однопоточный — ладно, понятно, prefork модель апача (как один из вариантов запуска), а почему неконкурентный-то — процессов же может быть сколь угодно?
Это к апачу не имеет никакого отношения. Рельса (на которой Редмайн крутится) тупо однопоточная (правда вроде как в 1.9 исправили, но я с Редмайном уже 1.5 года как "расстался", не могу уже тут точно сказать). Чтобы устроить параллельное обслуживание, надо запускать несколько инстансов и диспетчиризовать на них через mod_passenger.
Да, ступил на счет Конфлюенс. А вот броузер кода в Руби это простейшая поделка, про которую и упоминать нет смысла, особенно на фоне ФишАй. Что там и говорить, у нас был легаси проект, который состоял из нескольких корней, которые мэппились через svn:externals — Редмайн про такое и слыхом не слыхивал.
AB>Похоже, что это требования, на которых она хотя бы как-то заведется и будет хоть что-то отвечать. В реальной же жизни даже чистая jira и 5-10 пользователей на 2GB памяти уже работать не могут. Вероятно, отсюда и пошло выражение "У вас все сделано через джиру".
А зачем им давать заниженные требования? Чтобы их говном потом поливали? Как раз лучше дать завышенные, чтобы резерв иметь.
AB>Предположим, плагинов нет. Jira жрет память. Какие ручки крутим?
Ок, Жиру я никогда не администрировал и видел только в окне броузера, поэтому сочинять не стану
Но Жира сама по себе не запустится, нужен веб сервер. Допустим был Томкат, то проблемы могли начинаться ещё с него
— сессии не персистились на диск и никогда не экспайрились
— деплой/андеплой приложения без рестарта Томката — они 100 раз уже заявляли об окончательной победе над этой проблемой, но тем не менне проблемы есть
— а что собственно за OOME был? Может тупо permgen?
— Ну и надо включать GC log смотреть тратится память медленно, или обвально за 30 секунд, смотреть какая активность предшествует
— а релиз нотес для Жиры проверяли? Может проблема известная и исправленная?
Короче, ООМЕ может быть вызвано большим числом причин. Но Жира приложение довольно распространённое, поэтому я не верю, что там долгое время есть утечка, которую никто не может обнаружить и исправить
Кстати, помню у нас забавный случай был с JspWiki — тоже вдруг начало падать с OOME, причем по логам иногда выходило что и юзеров в этот момент на ней не было. Ничего в голову не приходило, а тут один юзер пишет, что "мол уже за последнее время несколько раз за последнее время пытается сохранить страницу, но она подвисает минут на 20, а потом рвется коннект" Текст страницы прилагался. Выяснилось, что его страница содержала ошибку — макро для построения оглавления был поставлен прямо в строку с заголовком. В итоге JspWiki минут 20 строила бесконечное оглавление, а потом падала с ООМЕ.
Re[4]: Java, Ruby, PHP и рекомендации к облачным хостам
Здравствуйте, avpavlov, Вы писали:
a> Это к апачу не имеет никакого отношения. Рельса (на которой Редмайн крутится) тупо однопоточная (правда вроде как в 1.9 исправили, но я с Редмайном уже 1.5 года как "расстался", не могу уже тут точно сказать). Чтобы устроить параллельное обслуживание, надо запускать несколько инстансов и диспетчиризовать на них через mod_passenger.
Ну так я и говорю, сама-то рельса однопоточная — это фиг с ней, понятно, никто и не запускает ее на продакшине в standalone (ну я надеюсь на это по крайней мере). В обычной-то жизни мы запускаем рельсы или через apache (mod_passenger / mod_fcgid) или через nginx или через mongrel и т.д. — там запускается множество экземпляров, которые вполне себе асинхронны друг для друга.
a> AB>Предположим, плагинов нет. Jira жрет память. Какие ручки крутим? a> Ок, Жиру я никогда не администрировал и видел только в окне броузера, поэтому сочинять не стану a> Но Жира сама по себе не запустится, нужен веб сервер. Допустим был Томкат, то проблемы могли начинаться ещё с него
У Jira есть stanalone режим, там tomcat встроенный как я понимаю.
a> — сессии не персистились на диск и никогда не экспайрились a> — деплой/андеплой приложения без рестарта Томката — они 100 раз уже заявляли об окончательной победе над этой проблемой, но тем не менне проблемы есть
Чистили, перестраивали индексы — в общем, основные рекомендации выполнялись.
a> — а что собственно за OOME был? Может тупо permgen?
Не знаю, разбирать многокилометровые трейсы явы занятие не из приятных.
a> Короче, ООМЕ может быть вызвано большим числом причин. Но Жира приложение довольно распространённое, поэтому я не верю, что там долгое время есть утечка, которую никто не может обнаружить и исправить
Решили проблему простой установкой Jira на сервер с 32GB RAM и получили стабильность — собственно, то, из за чего и началась дискуссия — прожорливые они, заразы.
