[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Сколько RPS может выдержать один выделенный сервер
T1grOK
Многие конечно сразу скажут, что зависит от очень многих факторов, но все же.

Имеется проект, по своей сути схож на баннерную сеть, то есть "часть нашего сайта" используется на сторонних ресурсах. И возникает логичный вопрос насколько много сможет обработать HTTP запросов один выделенный сервер(взять хотя бы E3-1230v2 3.3 GHz / 2 x 1000 GB (RAID) / 8 GB).

Код на сторонних сайтах - это 20кб данных и 3 запроса к нашей БД(все в пределах индексов, таблицы небольшие), то есть со стороны скрипта имеем максимально быструю производительность.

Интересует именно способен ли один сервер, чисто физически обработать хотя бы 2-3к rps?

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
FatCat
2-3 тысячи запросов в секунду?
Давай считать.
ThreadsPerChild сколько потянет? Больше 10 стремно, можно завесить сервер. То есть, 10 запросов могут обрабатываться одновременно. То есть, в физической секунде у нас есть 10 000 миллисекунд серверного времени.
Таким образом, чтобы обслужить 3К запросов в секунду, запрос должен обслуживаться в среднем 0.003 секунды.

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

_____________
Бесплатному сыру в дырки не заглядывают...
T1grOK
Не совсем то, что хотелось услышать, но за отклик спасибо.
И поправочка:
Цитата (FatCat @ 13.09.2014 - 08:30)
Таким образом, чтобы обслужить 3К запросов в секунду, запрос должен обслуживаться в среднем 0.003 секунды.

Если быть точным 0.0003 секунды, кажется абсолютно фантастической цифрой, если честно.

P.S. Сделал несколько синтетических тестов AB, на VPS (ihc.ru, "Земля") и был неприятно удивлен результатами:
15 rps на скриптах(Kohana fr.), где всего лишь выводится статичная страничка.(nginx + apache, fastcgi).
А глубоким вечером этот показатель не выше 10 rps(который раз замечаю, в определенное время суток тормоза у ihc).

На сервере крутится еще YouTrack, но даже с учетом этого я ожидал большего от данного VPS.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
Invis1ble
Цитата
15 rps

Цитата
10 rps

это с кэшерами?
P.S.
<?php echo View::factory('profiler/stats'); ?>


P.P.S. Ты даже ОСь не написал :D

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

sergeiss
T1grOK, тебе FatCat правильно сказал: всё зависит от того, сколько времени, в среднем, обрабатывается каждый запрос. Если ты дашь эту цифру, то я тебе дам ответ на основе "теории телетрафика". Эта теория очень хорошо подтверждается на практике. Работая в сотовой связи, я с этим имел дело в течение многих лет smile.gif

Давай сделаем примерный расчет.
Дополнительными условиями будут:
1. Как обрабатываются запросы: они ждут в очереди некоторое время или сразу дается отказ при отсутствии ресурсов.
2. Предполагается, что у системы достаточно ресурсов для обработки всех наших рассчитанных запросов одновременно. Пуст это будет 50 одновременных запросов.
3. Продолжительность обработки одного запроса 1/500 секунды.

Вопрос: сколько вызовов можно обработать одновременно?
Ответ: точной цифры нет smile.gif Если просто взять 50 и умножить на 500, то получим 25000 - максимальный предел, который никогда не будет достигнут.
Правильный ответ:
1. В системе без ожидания (формула Эрланга Б, зависимость совершенно не линейная).
Если вероятность отказа допускаем 2% (т.е. столько запросов вообще не будут обработаны), то расчет показывает 20130 запросов в секунду.
Вероятность отказа 1% - 18950 запросов.
Вероятность отказа 0.1% - 16255

2. В системе с очередью (с ожиданием; формула Эрланга Це, также нелинейная зависимость). Вроде как, веб-серверы должны поддерживать очередь, в разумном количестве.
Тут всё более "красиво" получается. И тут речь идет уже не об отказах, а о времени ожидания. Если, конечно, оно не превышает заданных пределов.

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

Тут больше параметров получаем. За ключевой параметр возьмем вероятность задержки более 1/500 сек, т.е. то, что запрос стоит в очереди дольше, чем потом обслуживается.
Получаем, что можем обслужить 23350 запросов, при том, что 2% запросов будут ждать дольше 1/500 сек.
Если мы потребуем, чтобы количество таких запросов (ждущих более 1/500 сек) не превышало 1%, то тогда получим 23100 запросов.
Но если нам пофиг, и мы допустим, чтобы до 50% запросов могли торчать в очереди более 1/500 сек, то тогда получим 24700 запросов.

Короче говоря, вывод простой smile.gif Зависимости нелинейные, примеры я показал. Без каких-либо исходных данных нельзя сделать расчет вообще. А расчет дает не точную, а вероятностную оценку.

PS. То, что описал, несложно. Хотя я знаю, что с первого прочтения может появиться мысль, что "это всё сложно" или даже "ну и бред написан!" smile.gif Уверяю, что это просто на самом деле, когда вникнешь немного.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
T1grOK
Цитата (Invis1ble @ 14.09.2014 - 08:58)
это с кэшерами?

Нет, без.
В профайлер я в первую очередь заглянул Application Execution - 0,025 - 0,035 с.
Довольно быстро, но я все равно ожидал большего smile.gif

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
FatCat
Цитата (T1grOK @ 14.09.2014 - 10:37)
Если быть точным 0.0003 секунды

Это если в один поток.
Если есть 10 потоков (каждый момент сервер обслуживает 10 запросов одновременно), времени на запрос можно выделить в 10 раз больше.
В принципе, ничто не мешает попробовать сделать больше потоков, и тем самым дать каждому запросу больше времени. Вон, смельчаки и по 300 потоков делают:
Цитата (session_on @ 14.09.2014 - 15:48)
Изменил в конфиге httpd "ThreadsPerChild" с 25 до 300 (Для запуска парсера в 100 и более потоков).
Но там парсер, который бОльшую часть времени ждет получения данных; нагрузка на машину не велика.

_____________
Бесплатному сыру в дырки не заглядывают...
FatCat
Цитата (T1grOK @ 14.09.2014 - 14:09)
0,025 - 0,035 с.

Потребуется ThreadsPerChild увеличить как минимум до 100.
У нас на хостинге (этот форум), уже на 15 сервер начинает работать нестабильно.

_____________
Бесплатному сыру в дырки не заглядывают...
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.