Как быстро должна быть создана динамически генерируемая веб-страница? - PullRequest
2 голосов
/ 07 мая 2009

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

Итак, как быстро создается страница для поддержания быстрого сайта?

Сайты разработаны в классическом ASP, с бэкэндом SQL Server, генерирующим наборы записей XML, которые я отображаю с использованием XSLT. Не самый эффективный метод, и создание страниц занимает от 7 мс до 120 мс (т.е. интервал таймера между первой строкой кода и «Response.Write») в зависимости от сложности страницы. Более медленные страницы связаны с тем, что база данных выполняет большие и более сложные запросы. Даже если я переписываю всю классику ASP в ASP.NET, не будет никакого существенного улучшения общей скорости рендеринга страницы.

Я часто слышал, как Джефф сказал, что он хочет, чтобы SO был самым быстрым сайтом , и его блоги обсуждали оптимизацию его кода и базы данных, но как далеко вы должны зайти в оптимизации вашего кода? Является ли мое время экономным, если вы экономите миллисекунды, используя StringBuffer вместо String + String?

[Разъяснение]

В какой момент вы начинаете думать: «Создание этой страницы занимает слишком много времени?». Это более 20 мс, более 200 мс или это нормально для страницы, занимающей более секунды, чтобы построить? Каковы ваши "целевые времена?"

Ответы [ 5 ]

5 голосов
/ 07 мая 2009

Это полностью зависит от вашей аудитории и целей - я работал над приложениями с целевым событием onload <4secs и над приложениями, где время на сервере должно быть <1 мс. Это может пойти в любую сторону - но что бы вы ни делали, вы должны знать, что любые оптимизации производительности, которые вы делаете на уровне сервера, скорее всего, будут затухать как по производительности сети, так и по-прежнему основным узким местом в Интернете, и восприимчивым временем загрузки. </p>

У Yahoo есть отличные рекомендации для общей производительности веб-сайта, особенно в области воспринимаемой нагрузки.

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

2 голосов
/ 07 мая 2009

Очень интересный скринкаст на эту тему можно найти здесь: текст ссылки .

Хотя он сделан парнем из Rails, он отлично применим к другим фреймворкам.

2 голосов
/ 07 мая 2009

Пользователи не заботятся о том, как быстро вы готовите свои данные, они заботятся только о фактическом времени загрузки страницы.

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

Использование массива (jscript) или .NET StringBuffer может значительно сократить время рендеринга. Помимо разгрузки излишнего использования ЦП, которая позволила бы вашему серверу обрабатывать больше трафика, я бы сказал, что такая очевидная оптимизация очень важна.

0 голосов
/ 07 мая 2009

Одним из факторов, влияющих на удовлетворенность пользователя временем отклика сервера, является то, как часто он запрашивает новую страницу. Если вы представляете (скажем) страницу с большим количеством информации, которую пользователь собирается потратить некоторое время, чтобы прочитать, более длительное время «рендеринга» вполне подойдет. Напротив, если человек быстро перемещается по страницам, ему нужен почти мгновенный ответ.

Например, если вы находитесь на новостном сайте, вы, вероятно, будете в порядке, если на следующую страницу уйдет целая секунда или две, поскольку вы потратите 30 секунд на ее чтение.

С другой стороны, если вы просматриваете интерактивную карту, вы, вероятно, хотите, чтобы ответ был менее секунды.

0 голосов
/ 07 мая 2009

Если вы можете сбрить миллисекунды, просто изменив одну вещь, сделайте это!

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

...