Имеет ли значение скорость языка программирования для веб-приложений?

Question

Я вижу множество тестов между PHP, Python, Ruby и т. Д. По всему Интернету. В Ruby много шума из-за того, что он очень медленный, что приводит к тому, что разработчики отказываются использовать его для веб-разработки по «соображениям производительности». Но действительно ли производительность интерпретатора имеет значение для веб-приложений? Разве узкое место не находится в базе данных в 99% случаев? Так почему же все волнуются?

Примечание: я понимаю, что в некоторых крайних случаях, таких как определенные математические / научные веб-приложения, производительность имеет большое значение, но я не говорю об этом; Я говорю о ваших средних социальных сетях, переполнении стека и т. Д.

Answer 1

Что вас должно пугать, так это то, что исследования, проведенные amazon.com и google.com, показали, что сокращение времени загрузки страницы <1 секунды оказало (для них) значительное влияние на их коэффициент конверсии и следовательно, прибыль. </p>

Поэтому производительность очень важна, даже для небольших сайтов. Вопрос в том, насколько это будет иметь значение. Потеря 0,1% продаж на самом деле не имеет значения, когда вы делаете 100 уникальных вещей в день, но когда вы делаете 10 миллионов, то внезапно, что 0,1% отнимает у вас много денег.

Даже небольшие изменения времени отклика может иметь значительные последствия. Google обнаружил, что переход от 10-результат загрузка страницы за 0,4 секунды до 30-страничная загрузка страницы за 0,9 секунды снижение трафика и доходов от рекламы на 20% (Линден 2006). Когда домашняя страница Google Maps был сокращен с 100 КБ до 70-80KB, трафик вырос на 10% в первую неделю, и дополнительные 25% в следующие три недели (Фарбер 2006). Тесты на Amazon показали аналогичные результаты: каждые 100 мс увеличиваются время загрузки Amazon.com уменьшилось продажи на 1% (Кохави и Лонгботам 2007). Эксперименты в Microsoft на Live Search показал, что при поиске страницы результатов были замедлены на 1 секунду: (Кохави 2007)

* Queries per user declined by 1.0%, and
* Ad clicks per user declined by 1.5%

После замедления страницы результатов поиска на 2 секунды:

* Queries per user declined by 2.5%, and
* Ad clicks per user declined by 4.4%

http://www.websiteoptimization.com/speed/tweak/psychology-web-performance/

Answer 2

Производительность имеет значение? В конце концов, конечно.

Но ваш веб-сайт должен стать настолько большим, что вы попадете в миллионы посещений в месяц, прежде чем это станет для вас проблемой за пределами традиционной оптимизации (например, правильная индексация в вашей базе данных ).

Не думаю, что отвращение к Ruby связано с производительностью (хотя с этим были проблемы). Более того, он не проверен, имеет репутацию нестабильного и навязал вам очень жесткие рамки (да, я знаю, что вы можете использовать Ruby без Rails и т. Д.). Я не фанат Ruby по той же причине, по которой я не фанат тяжеловесных фреймворков PHP, таких как CakePHP или Symfony: я нахожу эти фреймворки слишком инвазивными и настолько тяжелыми, что ты больше не пишешь PHP. Сравните это с более легкими фреймворками, такими как CodeIgniter, которые имеют намного лучший возврат инвестиций (imho).

Answer 3

Не думаю, что ваш вопрос очень продуман.

Сначала вы утверждаете, что большинству веб-приложений не требуется фантастическая производительность на стороне приложений, что, вероятно, справедливо для многих из них. Затем вы приводите несколько примеров веб-приложений, которые делают требующими хорошей производительности, и отмахиваетесь от них, говоря, что люди просто пишут их на C ++ или Java вместо этого!

Ну, разве вы не думаете, что они могли бы написать их на Ruby или Python? Возможно, именно поэтому люди заинтересованы в измерении производительности Ruby и Python!

РЕДАКТИРОВАТЬ : ОК, так что вы заинтересованы в очень простых веб-приложениях. Итак, вы и я оба можем видеть, что есть две возможности:

• Производительность на самом деле важна, поэтому они заинтересованы в производительности Ruby и Python и PHP.

• Производительность не важна, поэтому они ошибаются и либо не знают об этом, либо делают оправдание.

Answer 4

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

Answer 5

Имеет ли значение производительность для веб-приложений?

Да! Даже больше, чем для настольных приложений!

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

Answer 6

Ты прав. В большинстве случаев узкое место не зависит от вашего серверного языка. Конечно, 90% всей статистики составляется на лету, но я бы сказал, что в 9 случаях из 10 узкое место связано либо с пропускной способностью / скоростью передачи, либо с операциями с базой данных.

Предполагая, что вы эффективно используете каждый язык, есть ограниченные случаи, когда производительность PHP против Python против Ruby против .NET против всего, что когда-либо будет замечено пользователем. Когда такие вещи, как синтаксический анализ XML и сжатие, выполняются в очень большом масштабе, вы можете начать замечать, но в противном случае я бы просто придерживался того, с чем вы разбираетесь больше всего.

Зачастую некоторые из самых значительных улучшений в скорости веб-сайта могут быть вызваны сжатием gzip и осторожным использованием срока хранения кэша / контента. И обе эти вещи могут быть настроены в Apache или IIS. Я написал об этой теме здесь: http://swortham.blogspot.com/2007/10/three-ways-to-improve-your-websites.html

Answer 7

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

Другая сторона медали в том, что вам нужно быть успешным, чтобы она имела значение , как красноречиво и профанно сказал Тед Дзюба. «Медленные» языки, как правило, развиваются намного быстрее и более выразительны, чем скомпилированные языки, поэтому они позволяют команде быстрее запустить и запустить сайт.

Answer 8

Это может иметь большое значение, в зависимости от контекста. Большинство веб-сайтов работают на серверах общего хостинга, где эти вещи складываются. С несколькими сотнями веб-приложений, запущенных на одном компьютере, вы получите узкие места в процессоре и памяти.

Answer 9

jfar направит вас по правильному пути. Насколько это повлияет на ваш язык, профилирование, скорее всего, покажет, что ваш язык не является для вас проблемой.

• Избегайте компиляции по запросу, как old-scool cgi. Большинство современных веб-фреймворков должны быть резидентными между запросами.
• Если он не сильно изменится, сгенерируйте его и подавайте статический сигнал.
• Сжать. Включите gzip, если можете, и удалите пробелы и комментарии. Пробел для разработки и отладки.
• Выясните преобладающий вариант использования БД, запрос или вставку и настройте правильный.
• Кэширование / рендеринг того, что вы можете.
• Попробуйте провести сравнительный анализ различных серверов приложений, если вы работаете с ops, и люди разрешат вам изменить / обновить.

У кого-нибудь еще есть общие подсказки по настройке сети или ссылки на другие вопросы SO?

Есть ли хорошая книга по настройке производительности веб-приложений?

Answer 10

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

Но я бы также добавил еще одно соображение, и вот насколько «большой» размер вашей страницы с точки зрения изображений, JS и HTTP-запросов. У вас может быть очень медленный сайт, потому что ваша молниеносная база данных и код приложения создали монстра веб-страницы с раздутыми JS и изображениями. :)