Каковы “средние” запросы в секунду на производственное веб-приложение?

Обратите внимание, что графики частоты успешных обращений будут синусоидальными шаблонами с 'часами пик', возможно, 2x или 3x уровень, который Вы получаете, в то время как пользователи спят. (Может быть полезным, когда Вы планируете ежедневный материал пакетной обработки данных для случая на серверах)

, Вы видите эффект даже на 'международный' (многоязычный, локализованный) сайты как Википедия

Когда я перехожу к панели управления своего webhost, открываю phpMyAdmin и нажимаю на "Show MySQL runtime information", я добираюсь:

Этот сервер MySQL работал в течение 53 дней, 15 часов, 28 минут и 53 секунд. Это запустило 24 октября 2008 в 4:03.

статистика Запроса: Начиная с его запуска 3,444,378,344 запроса были отправлены на сервер.

Общие 3 444 M
в час 2,68 M
в минуту 44,59 k
в секунду 743.13

Это - в среднем 743 запроса MySQL каждую секунду в течение прошлых 53 дней!

я не знаю о Вас, но мне это быстро! Очень быстро!!

Это - очень открытый тип яблок к оранжевым вопроса.

Вы спрашиваете 1. средний запрос загружается для производственного приложения 2. что считают быстрым

, Они не обязательно имеют отношение.

Ваше среднее число # запросов в секунду определяется

a. число одновременных пользователей

b. среднее количество запросов страницы, которые они выполняют в секунду

c. количество дополнительных запросов (т.е. вызовы ajax, и т.д.)

относительно того, что считают быстрым.. Вы имеете в виду, как немного запросов сайт могут взять? Или если часть аппаратных средств считают быстрой, если это может обработать xyz # запросов в секунду?

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

Теперь Вы говорите мне, сколько пользователей Вы соединились.

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

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

Там действительно ли превосходным было видео (я думаю, что это, возможно, было на ted.com? Я думаю, что это, возможно, было веб-командой flickr? Кто-то знает ссылку?) с идеями о том, как масштабировать веб-сайты вне единственного сервера, например, как выделить соединения среди соединения только для чтения и серверов чтения-записи для получения лучшего эффекта для различных типов пользователей.