Что такое соответствующее время обработки страницы для веб-приложения?
Я работаю над веб-приложением, и оно переходит к сути дела, где у меня есть большинство необходимых функций, и я начинаю волноваться о скорости выполнения. Таким образом, я сделал некоторый поиск вокруг для получения информации, и я нашел много о сокращении времени загрузки страницы путем уменьшения CSS/JS, установки заголовков управления кэшем, использования отдельных доменов для статических файлов, сжатия вывода, и так далее (а также основные методы серверной стороны как memcached). Но скажем, я уже оптимизировал heck из всего это, и я обеспокоен в том, сколько времени он на самом деле берет мое веб-приложение для генерации страницы, т.е. чистое время обработки серверной стороны без удачных обращений в кэш. Очевидно, приемы для перевода в нерабочее состояние того времени будут зависеть от языка и базовых библиотек, которыми я пользуюсь, но к чему должно стремиться разумное число? Для сравнения я интересовался бы реальными примерами времени обработки для приложений, созданных с существующими платформами, делая типичные вещи как доступ к базе данных и рендеринг шаблонов.
Я всунул определенный код для измерения времени обработки (или по крайней мере часть его, которая происходит в рамках кода, который я написал), и я обычно вижу значения в 50-150ms диапазоне, который кажется довольно высоким. Мне интересно знать, сколько я должен сфокусировать на переводе в нерабочее состояние этого, или является ли мой целый подход к этому приложению слишком медленным, и я должен просто бросить его и попробовать что-то более простое. (На основе вкладки Net Firebug частей обработки это, которое я не измеряю обычно, добавляет меньше чем 5 мс, учитывая, что я тестирую с обоими клиентами и серверами на том же компьютере.)
К вашему сведению я работаю в Python, с помощью Werkzeug и SQLAlchemy/Elixir. Я знаю, что это не самые эффективные технологии там, но я действительно только обеспокоен тем, чтобы быть достаточно быстрым, не максимально быстро.
Править: Просто для уточнения 50-150ms, которое я заключил в кавычки выше, является чистое время обработки серверной стороны, только для самой страницы HTML. Фактическое время, которое требуется, чтобы страница загрузилась, как замечено пользователем, по крайней мере на 200 мс выше (так, 250-350ms общее количество) из-за времен доступа для CSS/JS/images (хотя я знаю, что это может быть улучшено с надлежащим использованием кэширования и Expires заголовки, спрайты, и т.д. который является чем-то, которое я сделаю в ближайшем будущем). Сетевая задержка добавит еще больше времени вдобавок ко всему, таким образом, мы будем, вероятно, говорить приблизительно 500 мс в течение общего клиентского времени загрузки.
Еще лучше вот снимок экрана от вкладки Net Firebug для типичного примера: Загрузка времен от Firebug http://www.ellipsix.net/ext-tmp/loadtimes.png, Это - 74 мс наверху, что я спрашиваю о.
4 ответа
IMHO, 50-150 мс на стороне клиента на стороне сервера - это нормально в большинстве обстоятельств. Когда я измеряю скорость некоторых очень известных сайтов, я редко вижу что-то столь же быстрое. Чаще всего это около 250 мс, а часто и выше.
Теперь я хочу подчеркнуть три момента.
Все зависит от контекста. Домашняя страница или страница, к которой будут обращаться очень часто, будет очень плохо работать, если загрузка займет несколько секунд. С другой стороны, некоторые редко используемые части сайта могут занимать до одной секунды, если оптимизация обойдется дорого.
Основная задача пользователей - быстро выполнить то, что они хотят. Речь идет не о времени, затраченном на доступ к отдельной странице, а скорее о времени доступа к информации или достижения цели. Это означает, что лучше, если одна страница занимает 250 мс, чем если пользователю придется посетить одну за другой три страницы для выполнения одного и того же действия, каждая из которых загружается за 150 мс.
Учитывайте воспринимаемое время загрузки. Например, на сайте Stack Overflow используется интересный трюк. Когда вы делаете что-то, основанное на AJAX, например, голосование вверх/вниз, сначала вы видите эффект, а затем делается запрос на сервер. Например, попробуйте проголосовать за свое собственное сообщение. Вы увидите, что сообщение проголосовало (стрелка станет оранжевой), затем, через 200 мс, стрелка станет серой и появится окно ошибки. Таким образом, в случае голосования "за", предполагаемое время загрузки (стрелка становится оранжевой) составляет 1 мс, в то время как реальное время загрузки, затраченное на выполнение запроса, составляет 100 мс.
EDIT: 200 мс тоже нормально. 500 мс, вероятно, немного повредят, если страница посещается часто или если пользователь ожидает, что страница будет быстрой (например, AJAX-запросы ожидаются быстрыми). Кстати, на скриншоте видно, что вы используете несколько CSS-файлов и десять PNG-изображений. Если объединить CSS в один файл и использовать CSS спрайты, вы, вероятно, сможете уменьшить воспринимаемое время загрузки, особенно при работе с сетевой задержкой.
Я просмотрел некоторые старые результаты JMeter, когда я написал и выполнил набор тестов производительности для веб-службы. Я приложу некоторые из них ниже, это, конечно, не от яблок к яблокам, но, по крайней мере, еще одна точка данных.
Время в миллисекундах. Требование местоположения и Требование карты имело собственные задержки в 15000 и 3000 миллисекунд, соответственно. Приглашение включало быстрый вызов 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 и предоставляет отличную информацию о том, как ускорить загрузку страниц.
50–150 мс для времени загрузки страницы - это нормально - на данном этапе вам не нужно проводить дополнительную оптимизацию.
Дело в том, что если ваши страницы загружаются в течение секунды, с вами все в порядке.
См. эту статью , в которой обсуждается влияние времени загрузки на преобразование (увеличение на 100 мс = 1% для Amazon).
Якоб Нильсен, известный спикер по юзабилити, опубликовал статью [1] по этому поводу несколько дней назад. Он предлагает использовать менее 1 секунды, а менее 100 мс - идеально, так как это немного больше прерывает поток пользователя.
Как отмечали другие пользователи, это зависит от контекста этой страницы. Если кто-то загружает файл, он ожидает задержки. Если они входят в систему и на это уходит десять секунд, они могут начать расстраиваться.