Каковы «средние» запросы в секунду для производственного веб-приложения?

Question

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

Answer 1

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

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

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

Answer 2

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

Статистика

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

Answer 3

Когда я захожу в панель управления моего веб-хоста, открываю 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 дня!

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

Answer 4

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

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

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

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

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

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

Answer 5

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

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

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

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

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

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

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

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

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

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