Компания Engine Yard, крупнейший хостер web-проектов на языке Ruby, выполняющий работу по сопровождению старых веток Ruby, представила новый открытый проект Puma (http://puma.io/), в рамках которого развивается полностью переработанный форк проекта Mongrel, отличающийся ориентацией на обеспечение максимальной производительности и поддержания обслуживания большого числа параллельных запросов. Несмотря на то, что Puma создан на базе Mongrel, в настоящее время, кроме кода HTTP-парсера, старая кодовая база полностью переписана. Непосредственно разбором протокола занимается написанный на языке Си компонент Ragel, все обрабатываемые запросы помещаются в обособленный пул потоков, что обеспечивает полноценное распараллеливание и задействование всех доступных в системе процессорных ядер. Код проекта распространяется (https://github.com/puma/puma) под лицензией BSD.Puma может использоваться в роли платформы для развертывания приложений на базе Ruby on Rails и отдельных приложений, использующих интерфейс Rack. Puma близок по возможностям к Mongrel и Webrick, и может выступать в качестве их прозрачной замены. Поддерживается работа с различными реализациями Ruby, такими как Rubinius (http://rubini.us), JRuby (http://jruby.org/) и MRI. Для классической реализации MRI, не способной выполнять одновременно несколько потоков из-за наличия глобальной блокировки, реализована поддержка распараллеливания на уровне ввода/вывода. Для Rubinius и JRuby возможно полноценное распараллеливания на уровне нитей.
<center><img src="https://www.opennet.ru/opennews/pics_base/0_1334224630.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></center>
URL: http://puma.io/
Новость: https://www.opennet.ru/opennews/art.shtml?num=33586
Черт возьми! Оси на графиках надо подписывать, даже если все очевидно.
Вы не представляете, как сложно нам, дальтоникам, смотреть на такие графики :)
Не только вам.
На офф сайте график представлен в виде таблички.
Но дизайнерская мысля сделала невозможным его читать не только дальтоникам...
Особенно порадовало цветовое решение для Rainbows, которое как бы намекает "да пофигу на эти результаты" или "попробуй угадай"
не только дальтоникам,
на черно-белом мониторе не видно
Y - расход памяти, X - количество запросов.
> Y - расход памяти, X - количество запросов.Т.е. Y - число запросов в секунду.
>> Y - расход памяти, X - количество запросов.
> Т.е. Y - число запросов в секунду.Дима, вы что-то не то пишете. Что там за ботва на графике - решительно непонятно.
Y — обработанных запросов в секунду, X — количество потоков.
=
На графике представлено отношение количества обработанных в секунду запросов к количеству одновременных запросов (больше - лучше); пометка KA обозначает тесты, в которых клиенты использовали keepalive запросы.
=//КО
> высокопроизводительный
> RubyРазве эти два понятия совместимы?
Мацумото давно уже пытается их совместить.
что-то лишнее
Если говорить о поизводительности в разработке, то более чем... А если заказчик не экономит на рефакторинге и планирует как положено жизненный цикл веб-сервиса, то в продакшне тоже обычно непреодолимых проблем не возникает.RoR и Ruby вместе с ним, как и многие другие инструменты, не универсальны и имеют свои ограничения.
На сегодняшний день, смею думать, что 90 процентов проектов этих ограничений недостигнут никогда...
При чем тут производительность разработки?
> При чем тут производительность разработки?Раз для вас ни при чем, значит вы реальными разработками никогда не занимались.
>> При чем тут производительность разработки?
> Раз для вас ни при чем, значит вы реальными разработками никогда не
> занимались.Всем плевать на производительность разработки, когда нужен сервер, выдерживающий высокие нагрузки. Если вы считаете иначе, то вы реальными разработками никогда не занимались.
Если приложение не идиоты писали - то скорость языка там не особо критична - 90% запросов будут вырождаться в примитивнейшую сборку заранее закэшированных кусков. 1-2 % - в сборку этих кусков и помещение их в кэш. И остальное - в отдачу "динамики", которая в большинстве случаев будет закэширована на следующих уровнях - reverse proxy/CDN/браузер.Да, есть ситуации, которые в этот сценарий не укладываются - но их мало, на вышеописанной схеме отлично строятся весьма крупные проекты.
Да, забыл добавить, что большая часть запросов, ответ на которые тупо собирается из кусков, до сервера приложений вообще доходить не должна - отвечать должны всё те же reverse proxy/CDN/браузер
Прежде чем говорить о производительности приложения, нужно сначала написать это приложение, и дождаться когда число пользователей и/или данных вырастет на столько, что приложение начнет упираться в ограничения платформы и архитектуры.Для этого надо еще на этапе разработки предусмотреть механизмы масштабирования. Ну и не ждать когда приложение само уткнется в ограничения и всё начнет падать, а масштабировать по мере роста нагрузки. Это и называется обеспечением жизненного цикла приложения.
Нужда в сервере выдерживающим высокие нагрузки откуда не возмись не появляется. Такие потребности обычно поддерживаются соответствующим баблом и архитектурными решениями.
Странно слушать народ, который говорит о производительности, пытаясь поднять сервис, обслуживающий несколько тысяч запросов в секунду, на "наколенном" сервере на базе целерона. Или что еще круче, на vds'е. Понятно, что такое имеет место быть, но серьезно относиться к этому сложно.
>> При чем тут производительность разработки?
> Раз для вас ни при чем, значит вы реальными разработками никогда не
> занимались.расскажите это разработчикам nginx и апача
>> Раз для вас ни при чем, значит вы реальными разработками никогда не
>> занимались.
> расскажите это разработчикам nginx и апачаВот и расскажите, они вам ответят тоже самое. Вы считаете что Puma, это конкурент nginx'у и apache? Они примерно такие же конкуренты, как карьерные самосвалы типа БелАЗа и Porsche 911...
Всё зависит от прямоты рук программиста. Если писать грамотно - то весьма производительный в нагруженных системах.
>> высокопроизводительный
>> Ruby
> Разве эти два понятия совместимы?Конечно! Как недавно пояснил Гвидо по поводу аналогичного вопроса, мол, "питон не тормозит, просто переписывайте критические части на непитоне!"
#>занимается написанный на языке Си компонент Ragel
>Конечно! Как недавно пояснил Гвидо по поводу аналогичного вопроса, мол, "питон не тормозит, просто переписывайте критические части на непитоне!"Код который тормозит не нужно переписывать, достаточно скомпилировать самым обычным gcc.
> Код который тормозит не нужно переписывать, достаточно скомпилировать самым обычным gcc.Ай, великий мастер, питон ты компейлируешь с gcc?! Отсыпь знания ладошку?
Это всегда пожалуйста. Отсыпаю: http://cython.org/
А Гвидо-то не в курсе?!
> А Гвидо-то не в курсе?!В курсе, в курсе.
Для простых людей задающих такие вопросы, нужны простые ответы.
Python программисты с опытом, все до одного, поверьте, давно в курсе.
>> А Гвидо-то не в курсе?!
> В курсе, в курсе.Van Rossum: ""It is usually much more effective to take that one piece and replace that one function or module with a little bit of code you wrote in C or C++""...
То есть Великий Гуру втихую _пользует _цитон, а на публику рекламирует С[++]? То есть попросту обвиняешь дяденьку во вранье, да??
> Для простых людей задающих такие вопросы, нужны простые ответы.
Этт Вы про "простое, логичное, но неправильное решение"?
> Python программисты с опытом, все до одного, поверьте, давно в курсе.
Наиболее опытные и пхп компилируют.
Тем не менее Гвидо сказал "replace [..] with [...] code you wrote in in C or C++".
~~_Заменить кодом _написанным на~~. То есть Ваше ""не нужно переписывать, достаточно скомпилировать"" -- есть рекомендация г-ну ван Россуму? И то есть он-таки нуждается в Вашей рекомендации, так как всё-таки не в курсе??
Стабильно код начал транслировать с версии 0.15 (сентябрь 2011), какого года это высказывание?
>>> А Гвидо-то не в курсе?!
>> В курсе, в курсе.
> Van Rossum: ""It is usually much more effective to take that one
> piece and replace that one function or module with a little
> bit of code you wrote in C or C++""...И что значит эта фраза вырванная из контекста?
> То есть Великий Гуру втихую _пользует _цитон, а на публику рекламирует С[++]?
> То есть попросту обвиняешь дяденьку во вранье, да??Тебя да. Еще час назад, ты не знал про cython .
>>Гвидо по поводу аналогичного вопроса, мол, "питон не тормозит, просто переписывайте критические части на непитоне!"
>не нужно переписывать, достаточно скомпилировать самым обычным gcc.Итого (после слива в №32): прямой речи Гвидо не читал, факты-тексты, предже чем пеной брызгать, не проверял, ирония не понимал. Ма-ла-цца!
>Итого (после слива в №32): прямой речи Гвидо не читал, факты-тексты, предже чем пеной брызгать, не проверял, ирония не понимал. Ма-ла-цца!Итого какая разница что когда-то, в каком-то году сказал Гвидо .
Сходи на сайт там документация, примеры, практика, можешь проверить.Зачем спорить с пеной у рта, в теме в которой нисколько не рубишь?
> Итого (после слива в №32):В чём состоял "слив"?
>> создан на базе Mongrel, в настоящее время, кроме кода HTTP-парсера, старая кодовая база полностью переписана.""What I notice is that my peers are progressing to more and more complicated and convoluted designs. They are impressed with the flashiest APIs, the biggest buzzwords, and the most intricate of useless features.
""They aren’t a mental challenge to understand anymore, they are just irritating. I’ll pick apart the flashy crap, boil down the technology to its essence and then come up with a much simpler design for the task at hand almost every time.
|*)))
А чего, никого не смущет, что эта самая "Пума (_16_:16) КА" типо опережает отсталых конкурентов вида "*** (_1_:16) {,KA}" _почти в 16 раз?К.О. для толстых и неповоротливах не пояснит физ.смысл этих "(n:M)"?
Объясните мне, идиоту... Зачем этот сервер нужен, неужели web-проекты на Ruby не дружат с обычным nginx или Apache?
Можно, конечно, использовать обычный FastCGI, но у него есть Фатальный Недостаток.
Какой же? Он имеет место быть только в связке с Ruby?
Он просто работает, для креативных рубистов это слишком скучно.
>Он просто работает, для креативных рубистов это слишком скучно.Сравнить скорость работы слабо?
Покажи хоть одно приложение на рельсах, для которого веб-сервер был бы узким местом.
>Покажи хоть одно приложение на рельсах, для которого веб-сервер был бы узким местом.Т.е. разницу между xCGI и сервером не освоил? Сей сервер можно сравнивать fastcgi и тому подобное. Разработан хостером рельсов, цель повышение производительности при уменьшение ресурсов и у них это получилось.
Puma может использоваться в роли платформы для развертывания приложений на базе Ruby on Rails и отдельных приложений, использующих интерфейс Rack.
