Ответ 1

OpenStreetMap имеет 10-20 в секунду

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

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

Ответ 2

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

Статистика

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

Ответ 3

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

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

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

Всего 3,444 M
в час 2,68 M
за минуту 44,59 k
в секунду 743.13

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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

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

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

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