Какое время обработки страницы подходит для веб-приложения?

Question

Я работаю над веб-приложением, и оно подходит к тому моменту, когда у меня есть большинство необходимых функций, и я начинаю беспокоиться о скорости выполнения.Поэтому я попытался найти информацию и многое узнал об уменьшении времени загрузки страницы за счет минимизации CSS / JS, установки заголовков управления кэшем, использования отдельных доменов для статических файлов, сжатия вывода и т. Д. (А также базовых серверныхсторонние приемы вроде memcached).Но, скажем, я уже оптимизировал все это, и меня беспокоит, сколько времени на самом деле уходит мое веб-приложение на генерацию страницы, то есть чистое время обработки на стороне сервера без попаданий в кеш.Очевидно, что приемы для того, чтобы сократить это время, будут зависеть от языка и базовых библиотек, которые я использую, но к какому разумному количеству стремиться?Для сравнения, меня могут заинтересовать примеры времени обработки приложений, созданных с использованием существующих сред, выполняющих типичные вещи, такие как доступ к базе данных и шаблоны рендеринга.

Я попробовал немного кода для измерениявремя обработки (или, по крайней мере, часть того, что происходит в написанном мной коде), и я обычно вижу значения в диапазоне 50-150 мс, что кажется довольно высоким.Мне интересно знать, насколько я должен сосредоточиться на том, чтобы свести это на нет, или же весь мой подход к этому приложению слишком медленный, и я должен просто отказаться от него и попробовать что-то более простое.(Исходя из вкладки «Сеть» Firebug, части обработки, которые я не измеряю, обычно добавляют менее 5 мс, учитывая, что я тестирую и на клиенте, и на сервере на одном компьютере.)

К вашему сведениюЯ работаю в Python, используя Werkzeug и SQLAlchemy / Elixir.Я знаю, что это не самые эффективные технологии, но на самом деле меня интересует только быстрая, а не настолько быстрая скорость, насколько это возможно.

РЕДАКТИРОВАТЬ : просто чтобы уточнить, 50-150 мсек, которые я цитировал выше, это чистое время обработки на стороне сервера, просто для самой HTML-страницы.Фактическое время, необходимое для загрузки страницы, по мнению пользователя, составляет не менее 200 мс выше (итого 250-350 мс) из-за времени доступа к CSS / JS / изображениям (хотя яЯ знаю, что это может быть улучшено при правильном использовании кэширования и Expires заголовков, спрайтов и т. д., что я буду делать в ближайшем будущем).Задержка сети добавит еще больше времени, поэтому мы, вероятно, говорим о 500 мс для общего времени загрузки клиента.

Еще лучше, вот скриншот с вкладки Net Firebug для типичного примера: Время загрузки из Firebug http://www.ellipsix.net/ext-tmp/loadtimes.png Это 74 мс наверху, о котором я спрашиваю.

Answer 1

ИМХО, 50-150 мс на стороне клиента, на стороне сервера - это нормально в большинстве случаев. Когда я измеряю скорость некоторых очень известных веб-сайтов, я редко вижу что-то быстрое. В большинстве случаев это около 250 мс, часто выше.

Теперь я хочу подчеркнуть три пункта.

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

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

3. Учитывайте предполагаемое время загрузки. Например, на сайте Stack Overflow используется интересный трюк. При выполнении чего-либо, основанного на AJAX, например, при голосовании вверх / вниз, сначала вы увидите эффект, затем запрос будет отправлен на сервер. Например, попробуйте проголосовать за ваше собственное сообщение. Он покажет вам, что за сообщение проголосовали "за" (стрелка станет оранжевым), , затем , через 200 мс, стрелка станет серой и появится окно с ошибкой. Таким образом, в случае повышенного голосования воспринимаемое время загрузки (стрелка становится оранжевым) составляет 1 мс, когда реальное время загрузки, потраченное на выполнение запроса, составляет 100 мс.

РЕДАКТИРОВАТЬ: 200 мс тоже хорошо. 500 мс, вероятно, немного повредят, если к странице часто обращаются или если пользователь ожидает, что страница будет быстрой (например, запросы AJAX ожидаются , чтобы быть быстрыми). Кстати, на скриншоте я вижу, что вы используете несколько файлов CSS и десять изображений PNG. Объединяя CSS в один файл и используя CSS-спрайты , вы, вероятно, можете сократить предполагаемое время загрузки, особенно при работе с задержкой в ​​сети.

Answer 2

Якоб Нильсен, известный оратор по юзабилити, опубликовал статью [1] об этом несколько дней назад. Он предполагает, что менее 1 секунды - это предложение, менее 100 мс - идеальное решение, поскольку оно прерывает поток пользователя немного больше.

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

[1] http://www.useit.com/alertbox/response-times.html

Answer 3

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

Время указано в миллисекундах. Location Req и Map Req имели собственные задержки 15000 и 3000 миллисекунд соответственно. Invite включает быстрый вызов на ldap-сервер мобильного оператора. Другие были довольно стандартными, в основном чтение / запись в базу данных.

sampler_label    count    average    min    max
Data Blurp       2750     185        30     2528 
UserAuth         2750     255        41     2025
Get User Acc     820      148        29     2627
Update User Acc  4        243        41     2312
List Invitations 9630     345        47     3966
Invite           2750     591        102    4095
ListBuddies      5500     344        52     3901
Block Buddy      403      419        79     1835
Accept invite    2065     517        94     3043
Remove Buddy     296      411        83     1942
Location Req     2749     16963      15369  20517
Map Req          2747     3397       3116   5926

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

Я думаю, что ваши номера абсолютно нормальные. Что касается всего остального, что заставляет веб-сайты казаться медленными, если нет, взгляните на YSlow . Он прекрасно интегрируется с Firebug и предоставляет отличную информацию о том, как ускорить загрузку страниц.

Answer 4

50-150мс для времени загрузки страницы в порядке - вам не нужно дополнительно оптимизировать на этом этапе.

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

См. в этой статье , в которой рассматриваются эффекты времени загрузки для преобразования (увеличение на 100 мс = 1% для Амазонки).