| 1.1, Аноним (-), 14:03, 12/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +14 +/– |
Черт возьми! Оси на графиках надо подписывать, даже если все очевидно.
| | |
| |
| 2.2, Именно (?), 14:10, 12/04/2012 [^] [^^] [^^^] [ответить]
| +7 +/– |
Вы не представляете, как сложно нам, дальтоникам, смотреть на такие графики :)
| | |
| |
| 3.6, ixti (ok), 15:36, 12/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
 На офф сайте график представлен в виде таблички.
Но дизайнерская мысля сделала невозможным его читать не только дальтоникам...
Особенно порадовало цветовое решение для Rainbows, которое как бы намекает "да пофигу на эти результаты" или "попробуй угадай"
| | |
|
| |
| 3.5, Дима (??), 15:35, 12/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Y - расход памяти, X - количество запросов.
Т.е. Y - число запросов в секунду.
| | |
| |
| 4.12, Vkni (ok), 17:54, 12/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
 >> Y - расход памяти, X - количество запросов.
> Т.е. Y - число запросов в секунду.
Дима, вы что-то не то пишете. Что там за ботва на графике - решительно непонятно.
| | |
|
|
| 2.25, Abu (?), 12:54, 13/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
=
На графике представлено отношение количества обработанных в секунду запросов к количеству одновременных запросов (больше - лучше); пометка KA обозначает тесты, в которых клиенты использовали keepalive запросы.
=
//КО
| | |
|
| |
| 2.11, northbear (??), 17:16, 12/04/2012 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Если говорить о поизводительности в разработке, то более чем... А если заказчик не экономит на рефакторинге и планирует как положено жизненный цикл веб-сервиса, то в продакшне тоже обычно непреодолимых проблем не возникает.
RoR и Ruby вместе с ним, как и многие другие инструменты, не универсальны и имеют свои ограничения.
На сегодняшний день, смею думать, что 90 процентов проектов этих ограничений недостигнут никогда...
| | |
| |
| |
| 4.14, Минона (?), 21:47, 12/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> При чем тут производительность разработки?
Раз для вас ни при чем, значит вы реальными разработками никогда не занимались.
| | |
| |
| 5.16, Аноним (-), 00:49, 13/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> При чем тут производительность разработки?
> Раз для вас ни при чем, значит вы реальными разработками никогда не
> занимались.
Всем плевать на производительность разработки, когда нужен сервер, выдерживающий высокие нагрузки. Если вы считаете иначе, то вы реальными разработками никогда не занимались.
| | |
| |
| 6.18, Crazy Alex (ok), 01:37, 13/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Если приложение не идиоты писали - то скорость языка там не особо критична - 90% запросов будут вырождаться в примитивнейшую сборку заранее закэшированных кусков. 1-2 % - в сборку этих кусков и помещение их в кэш. И остальное - в отдачу "динамики", которая в большинстве случаев будет закэширована на следующих уровнях - reverse proxy/CDN/браузер.
Да, есть ситуации, которые в этот сценарий не укладываются - но их мало, на вышеописанной схеме отлично строятся весьма крупные проекты.
| | |
| |
| 7.19, Crazy Alex (ok), 01:40, 13/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
Да, забыл добавить, что большая часть запросов, ответ на которые тупо собирается из кусков, до сервера приложений вообще доходить не должна - отвечать должны всё те же reverse proxy/CDN/браузер
| | |
|
| 6.23, northbear (??), 11:13, 13/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Прежде чем говорить о производительности приложения, нужно сначала написать это приложение, и дождаться когда число пользователей и/или данных вырастет на столько, что приложение начнет упираться в ограничения платформы и архитектуры.
Для этого надо еще на этапе разработки предусмотреть механизмы масштабирования. Ну и не ждать когда приложение само уткнется в ограничения и всё начнет падать, а масштабировать по мере роста нагрузки. Это и называется обеспечением жизненного цикла приложения.
Нужда в сервере выдерживающим высокие нагрузки откуда не возмись не появляется. Такие потребности обычно поддерживаются соответствующим баблом и архитектурными решениями.
Странно слушать народ, который говорит о производительности, пытаясь поднять сервис, обслуживающий несколько тысяч запросов в секунду, на "наколенном" сервере на базе целерона. Или что еще круче, на vds'е. Понятно, что такое имеет место быть, но серьезно относиться к этому сложно.
| | |
|
| 5.17, Аноним (-), 00:56, 13/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> При чем тут производительность разработки?
> Раз для вас ни при чем, значит вы реальными разработками никогда не
> занимались.
расскажите это разработчикам nginx и апача
| | |
| |
| 6.24, northbear (??), 11:18, 13/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Раз для вас ни при чем, значит вы реальными разработками никогда не
>> занимались.
> расскажите это разработчикам nginx и апача
Вот и расскажите, они вам ответят тоже самое. Вы считаете что Puma, это конкурент nginx'у и apache? Они примерно такие же конкуренты, как карьерные самосвалы типа БелАЗа и Porsche 911...
| | |
|
|
|
|
| 2.21, letsmac (ok), 09:30, 13/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Всё зависит от прямоты рук программиста. Если писать грамотно - то весьма производительный в нагруженных системах.
| | |
| 2.22, Andrey Mitrofanov (?), 09:56, 13/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> высокопроизводительный
>> Ruby
> Разве эти два понятия совместимы?
Конечно! Как недавно пояснил Гвидо по поводу аналогичного вопроса, мол, "питон не тормозит, просто переписывайте критические части на непитоне!"
#>занимается написанный на языке Си компонент Ragel
| | |
| |
| 3.26, f (??), 14:49, 13/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Конечно! Как недавно пояснил Гвидо по поводу аналогичного вопроса, мол, "питон не тормозит, просто переписывайте критические части на непитоне!"
Код который тормозит не нужно переписывать, достаточно скомпилировать самым обычным gcc.
| | |
| |
| 4.27, Andrey Mitrofanov (?), 15:09, 13/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Код который тормозит не нужно переписывать, достаточно скомпилировать самым обычным gcc.
Ай, великий мастер, питон ты компейлируешь с gcc?! Отсыпь знания ладошку?
| | |
| |
| |
| |
| 7.30, f (??), 15:46, 13/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> А Гвидо-то не в курсе?!
В курсе, в курсе.
Для простых людей задающих такие вопросы, нужны простые ответы.
Python программисты с опытом, все до одного, поверьте, давно в курсе.
| | |
| |
| |
| 9.32, f (??), 16:15, 13/04/2012 [^] [^^] [^^^] [ответить] | +/– | Стабильно код начал транслировать с версии 0 15 сентябрь 2011 , какого года это... текст свёрнут, показать | | |
| 9.37, f (??), 18:03, 13/04/2012 [^] [^^] [^^^] [ответить] | +/– | И что значит эта фраза вырванная из контекста Тебя да Еще час назад, ты не зна... текст свёрнут, показать | | |
|
|
|
|
|
| 4.33, Andrey Mitrofanov (?), 16:20, 13/04/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>Гвидо по поводу аналогичного вопроса, мол, "питон не тормозит, просто переписывайте критические части на непитоне!"
>не нужно переписывать, достаточно скомпилировать самым обычным gcc.
Итого (после слива в №32): прямой речи Гвидо не читал, факты-тексты, предже чем пеной брызгать, не проверял, ирония не понимал. Ма-ла-цца!
| | |
| |
| 5.36, клевый пыщ (?), 17:58, 13/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
>Итого (после слива в №32): прямой речи Гвидо не читал, факты-тексты, предже чем пеной брызгать, не проверял, ирония не понимал. Ма-ла-цца!
Итого какая разница что когда-то, в каком-то году сказал Гвидо .
Сходи на сайт там документация, примеры, практика, можешь проверить.
Зачем спорить с пеной у рта, в теме в которой нисколько не рубишь?
| | |
| 5.38, f (??), 18:16, 13/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Итого (после слива в №32):
В чём состоял "слив"?
| | |
|
|
|
|
| 1.34, Andrey Mitrofanov (?), 16:35, 13/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>> создан на базе 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.
|*)))
| | |
| 1.35, Andrey Mitrofanov (?), 16:40, 13/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
А чего, никого не смущет, что эта самая "Пума (_16_:16) КА" типо опережает отсталых конкурентов вида "*** (_1_:16) {,KA}" _почти в 16 раз?
К.О. для толстых и неповоротливах не пояснит физ.смысл этих "(n:M)"?
| | |
| 1.39, Aesthetus Animus (ok), 20:51, 13/04/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Объясните мне, идиоту... Зачем этот сервер нужен, неужели web-проекты на Ruby не дружат с обычным nginx или Apache?
| | |
| |
| 2.40, Аноним (-), 21:23, 13/04/2012 [^] [^^] [^^^] [ответить]
| +/– |
Можно, конечно, использовать обычный FastCGI, но у него есть Фатальный Недостаток.
| | |
| |
| |
| |
| 5.44, gag (??), 11:01, 14/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
>Он просто работает, для креативных рубистов это слишком скучно.
Сравнить скорость работы слабо?
| | |
| |
| 6.45, Аноинм (?), 14:15, 14/04/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
Покажи хоть одно приложение на рельсах, для которого веб-сервер был бы узким местом.
| | |
| |
| 7.46, Аноним (-), 16:05, 15/04/2012 [^] [^^] [^^^] [ответить]
| +/– | |
>Покажи хоть одно приложение на рельсах, для которого веб-сервер был бы узким местом.
Т.е. разницу между xCGI и сервером не освоил? Сей сервер можно сравнивать fastcgi и тому подобное. Разработан хостером рельсов, цель повышение производительности при уменьшение ресурсов и у них это получилось.
| | |
|
|
|
|
|
| 2.43, gag (??), 10:52, 14/04/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Puma может использоваться в роли платформы для развертывания приложений на базе Ruby on Rails и отдельных приложений, использующих интерфейс Rack.
| | |
|
|
