Стоимость масштабирования Rails против стоимости масштабирования PHP против фреймворков Python

Question

Полагаю, этот вопрос часто задавали. Я знаю, Rails может масштабироваться , потому что я работал над этим, и это круто. И в этом нет особых сомнений в том, что касается PHP-фреймворков.

Я не хочу знать, какие рамки лучше.

Какова разница в стоимости масштабирования Rails по сравнению с другими фреймворками (PHP, Python) при условии, что большое приложение имеет 1 миллион посещений в месяц?

Это то, что меня часто спрашивают. Я могу объяснить людям, что «Rails хорошо масштабируется», но какова в конечном итоге экономика?

Если кто-то может предоставить некоторые показатели, это было бы замечательно.

Answer 1

Одним из основных факторов в этом является то, что выбор структуры не зависит от доступа к базе данных. Независимо от того, какой подход вы используете, вы, скорее всего, поместите данные в реляционную базу данных. Тогда вопрос заключается в том, насколько эффективно вы можете получить данные из базы данных. Это в первую очередь зависит от СУБД (Oracle против Postgres против MySQL), а не от платформы - за исключением того, что некоторые библиотеки отображения данных могут неэффективно использовать SQL.

Для чистого параметра «количество посещений» вопрос действительно в том, насколько быстро работает ваша система HTML-шаблонов. Вопрос в том, сколько страниц вы можете отобразить в секунду? Я бы сделал это основным показателем, чтобы определить, насколько хорошо система будет масштабироваться.

Конечно, разные страницы могут иметь разные расходы; для некоторых вы можете использовать кэширование, но не для других. Таким образом, при измерении масштабируемости разделите ваши 1 миллион посещений на дешевые и дорогие страницы и измерьте их отдельно. Вместе они должны дать хорошую оценку нагрузки, которую может выдержать ваша система (или количества систем, необходимых для удовлетворения спроса).

Существует также проблема использования памяти. Если у вас есть данные в SQL, это не должно иметь значения, но при кэшировании вам также может понадобиться учитывать масштабируемость. использование основной памяти.

Answer 2

ИМХО Я не думаю, что стоимость масштабирования будет отличаться между этими тремя, потому что ни в одной из них не включены «батареи масштабируемости». Я просто не вижу огромных архитектурных различий между этими тремя вариантами, которые могли бы вызвать существенную разницу в масштабировании.

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

Если вам нужно кэширование памяти, вы, по крайней мере, будете использовать memcached (или нечто подобное, которое будет взаимодействовать со всеми тремя языками). Возможно, вы помогаете масштабируемости, используя nginx, чтобы обслуживать напрямую из memcache, но это явно не изменит производительность php / perl / python / ruby.

Если вы используете MySQL или Postgresql, вам все равно придется правильно проектировать базу данных для масштабирования независимо от языка вашего приложения, и любой инструмент, который вы используете для запуска кластеризации / зеркалирования, будет вне вашего приложения.

Я думаю, что с точки зрения использования памяти, Python (с режимом демона mod_wsgi) и Ruby (корпоративный ruby ​​с passenger / mod_rack) имеют довольно приличные следы, по крайней мере сопоставимые с PHP в fcgi и, вероятно, лучше, чем PHP в mod_php (то есть preache for Apache MPM) + php во всех процессах apache отнимает много памяти).

Там, где этот вопрос может быть интересным, - попытка сравнить эти 3 языка с чем-то вроде Erlang, где у вас (предположительно) имеется дешевая встроенная масштабируемость автоматически во всех процессах Erlang, но даже тогда у вас будет узкое место в базе данных RDBMS, если только Ваше приложение прекрасно вписывается в один из способов работы с базой данных Erlang, например CouchDB.

Answer 3

К сожалению, я не знаю ни одного сравнения стоимости Rails, PHP и Django. Но я знаю сравнение стоимости некоторых Java Web Framework: Spring (9k $), Wicket (59k $), GWT (6k $) и JSF (49k $).

У вас есть оригинальная конференция здесь:

http://www.devoxx.com/display/DV11/WWW++World+Wide+Wait++A+Performance+Comparison+of+Java+Web+Frameworks

Там у вас есть пост об этом (короче):

http://blog.websitesframeworks.com/2013/03/web-frameworks-benchmarks-192/

Если вы хотите попытаться сделать вывод об этой стоимости. Вы можете скрестить эти данные с эталонным тестом, предложенным Techempower:

http://www.techempower.com/benchmarks/

Итак, если вы знаете, что Spring довольно дешевый по сравнению с Wicket и Django / Rails, у него худшие оценки в тестах, чем у Wicket и Spring, это, вероятно, означает, что они будут стоить дороже.

Надеюсь, это поможет.