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

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

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

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

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

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

 * Количество запросов на пользователя снизилось на 1,0%, а
* Количество кликов по рекламе на пользователя снизилось на 1,5%.

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

 * Количество запросов на пользователя уменьшилось на 2,5%, и
* Количество кликов по рекламе на пользователя снизилось на 4,4%.

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

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

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

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

EDIT : Хорошо, значит, вас интересуют очень обычные веб-приложения. Итак, мы с вами видим две возможности:

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

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

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

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

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

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

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

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

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

Most sites will release first-version code as soon as the site is functional. If they are at all successful, pretty soon there are multi-second pages, and they need to attend to either hardware or software, and you're I guess suggesting an implicit distinction between page code and database software.

Are you wondering if we should not bother with the page code and assume any non-hardware scaling issues are in the database? That's not my experience; although it's usually the database that gets released soonest because like horseshoes, too often close is good enough (as long as the answer is what you expected.)

But I've seen a lot more page code that tried to do what databases are designed to do (e.g. with arrays) than vice versa (e.g. cursors), with equally detrimental consequences on speed and scalability. And optimizing a database query is in my experince less work than fixing PHP code.

I think most speed problems are not the language (or the dbms itself) but rather the quality of the design and the code. So I would think good developers would be more concerned with whether or not a language facilitates good design and good code, not how fast it runs.

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

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

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

По моему опыту, как только вы действительно начинаете чем-то заниматься, то именно в базе данных, где вы можете получить наибольшую РАЗНИЦУ.

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

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

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

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

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