2016-03-09 2 views
0

(гипотетический сценарий)Сколько пользователей в то же время на сайте. CPU/memory/brandwidth

У меня будет очень простой статический сайт html с одной страницей. Он будет иметь простой текст, похожий на «Hello world» и кнопку, перенаправляющую на другой сайт (~ 2kb).

Веб-сайт «привет мир» будет размещен на моем компьютере с помощью node.js. Мой вопрос: сколько «живых» пользователей можно будет обрабатывать. Значение людей, которые просто сидят на веб-сайте и обновляются каждые ~ 30 секунд. Скажем ~ 30000 человек, которые обновляют. Значение веб-сайта будет иметь ~ 1000 обновлений в секунду. Этот процесс будет активен через ~ 3 часа. Какие факторы несут ответственность здесь? Мой процессор? ОЗУ? Пропускная способность?

(гипотетические установки)

100/10mb стабильного соединение волокна с верхним маршрутизатором.

16gb RAM.

i7-2600k 3.4GHz.

ответ

0

Все зависит от того, что делает приложение Hello World. Если это решение дифференциальных уравнений для ваших пользователей, он будет использовать много CPU. Если он функционирует как потоковый сервер видео, пропускная способность и использование памяти будут значительными. Приложение hello world ниже было протестировано с помощью тестового теста Apache на двухъядерной виртуальной машине с ~ 2 ГБ оперативной памяти, чтобы получить общее представление о том, чего можно ожидать.

var http = require('http'); 

http.createServer(function(req, res) { 
    res.writeHead(200, {'Content-Type': 'text/html'}); 
    res.write('<p>Hello World</p>'); 
    res.end(); 
}).listen(8080); 

Как вы можете видеть, эта программа очень проста, работает без фреймворков и без логики. Любой из них значительно изменит эти результаты. Параметр -n представляет собой количество полных запросов в тесте, а параметр -c показывает количество в секунду.

ab -n 30000 -c 1000 <URL> 

Обратите внимание, что длина документа составляет 18 байт. Любое увеличение там будет масштабировать вашу полосу пропускания линейно (так что если у вас есть 1kB html-файл, вы будете смотреть на ширину полосы 1kB * 1000/sec = ~ 8mbps, около 80% вашей восходящей линии связи). По этой причине кеширование очень важно. При обработке 1000 запросов в секунду узел использовал 99% CPU (так как 1000 одновременных подключений, вероятно, насыщали его способность реагировать, и поэтому у него всегда было что-то делать). Однако одним из преимуществ узла является то, что он использует относительно небольшую память для высокой параллелизма, поэтому он зависел от использования памяти на 3% в 2 ГБ.

Document Path:  /
Document Length:  18 bytes 

Concurrency Level:  1000 
Time taken for tests: 5.355 seconds 
Complete requests:  30000 
Failed requests:  0 
Total transferred:  3540000 bytes 
HTML transferred:  540000 bytes 
Requests per second: 5602.75 [#/sec] (mean) 
Time per request:  178.484 [ms] (mean) 
Time per request:  0.178 [ms] (mean, across all concurrent requests) 
Transfer rate:   645.63 [Kbytes/sec] received 

Надеюсь, это полезно при разработке вашего приложения!

+0

Спасибо! Это очень полезно.Я сделаю аналогичный тест, когда у меня будет время. Если вы заинтересованы в результатах, я опубликую результаты ниже. –

+0

Я всегда интересовался результатами! Как выглядел ваш мир привет? – TheToolBox

0

Позволяет рассчитать немного:
1000 тонизирует/сек * 2kByte = 2MByte/сек => 16MBit/второй + немного накладных расходов для запросов => ~ 20Mbit

Так что ваше соединение 10Мбит будет слишком медленный, но 100MBit был бы более чем достаточным в этом случае.

Я не думаю, что ОЗУ или мощность процессора будут проблемой, если у вас есть только статическая страница.

Но я должен добавить, что у меня на самом деле нет опыта с этим.

+0

Спасибо! Я буду вздыматься до 100mbs в upspeed, чтобы быть в безопасности! –