У меня нет системы координат относительно того, что считается «быстрым»; Я всегда задавался этим вопросом, но так и не нашел прямого ответа ...

OpenStreetMap, кажется, имеет 10-20 в секунду

Википедия, похоже, составляет от 30000 до 70000 в секунду на 300 серверах (от 100 до 200 запросов в секунду на машину, большинство из которых - кеши)

Geograph получает 7000 изображений в неделю (1 загрузка за 95 секунд)

Не уверен, что кому-то все еще интересно, но эта информация была опубликована о Твиттере (и здесь тоже ):

Статистика

• Более 350 000 пользователей. Фактические цифры, как всегда, очень суперсверхсекретные.
• 600 запросов в секунду.
• В среднем 200-300 подключений в секунду. Пик до 800 соединений в секунду.
• MySQL обрабатывал 2400 запросов в секунду.
• 180 экземпляров Rails. Использует Mongrel в качестве «веб-сервера».
• 1 сервер MySQL (один большой 8-ядерный блок) и 1 подчиненный сервер. Slave доступен только для чтения для статистики и отчетов.
• 30+ процессов для обработки случайных работ.
• 8 Sun X4100s.
• Обработайте запрос в Rails за 200 миллисекунд.
• Среднее время нахождения в базе данных составляет 50-100 миллисекунд.
• Более 16 ГБ памяти memcached.

Когда я перехожу на панель управления своего веб-хостинга, открываю phpMyAdmin и нажимаю «Показать информацию о времени выполнения MySQL», я получаю:

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

Статистика запросов: с момента запуска на сервер было отправлено 3 444 378 344 запроса.

Всего 3444 млн
в час 2,68
млн в минуту 44,59 тыс
в секунду 743,13

Это в среднем 743 запроса mySQL каждую секунду за последние 53 дня!

Не знаю, как вы, но для меня это быстро! Очень быстро!!

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

Чтобы ответить на ваш вопрос, мы сами провели огромный нагрузочный тест и обнаружили, что он варьируется на различном оборудовании amazon, которое мы используем (лучшим значением был 32-битный средний ЦП, когда он снизился до $$ / событие / секунду) и наших запросов / секунд варьировалось от 29 запросов в секунду на узел до 150 запросов в секунду на узел.

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

ПРИМЕЧАНИЕ: благодаря анализу запросов / секунду (не ms / request) мы обнаружили серьезную проблему Linux, которую мы пытаемся решить, когда Linux (мы тестировали сервер на C и java) замораживает все вызовы в библиотеки сокетов при слишком большой нагрузке что кажется очень странным. Полную версию сообщения можно найти здесь .... http://ubuntuforums.org/showthread.php?p=11202389

Мы все еще пытаемся решить эту проблему, поскольку это дает нам огромный прирост производительности, поскольку наш тест идет с 2 минут 42 секунды до 1 минуты 35 секунд, когда это исправлено, поэтому мы видим улучшение производительности на 33% ... не говоря уже о том, Чем хуже DoS-атака, тем дольше эти паузы, так что все процессоры упадут до нуля и прекратят обработку ... на мой взгляд, обработка сервера должна продолжаться перед лицом DoS, но по какой-то причине она время от времени зависает во время Dos иногда до 30 секунд !!!

ДОПОЛНЕНИЕ: мы обнаружили, что на самом деле это была ошибка состояния гонки jdk .... трудно изолировать на больших кластерах, но когда мы запускали 1 узел данных сервера 1, но 10 из них, мы могли воспроизводить его каждый раз и просто смотрели на сервер / datanode, где это произошло. Переключение jdk на более раннюю версию устранило проблему. Думаю, мы были на jdk1.6.0_26.

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

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

Они не обязательно связаны.

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

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

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

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

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

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

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

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

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

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

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

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