Как следует из названия, мне нужны nodejs и mongodb для обработки 5000 запросов в секунду. Сразу же. Со временем мы вырастем во много раз.
Мои первоначальные мысли заключаются в том, чтобы разместить каждую на отдельных машинах, хотя я не уверен, следует ли мне начинать с небольших машин и готовиться к масштабированию в ближайшее время, или начать с более крупных машин и масштабировать позже.
В любом случае я полностью рассчитываю, что в конечном итоге эти два уровня будут масштабированы, но мне интересно, каков будет триггер для увеличения масштаба. Могу ли я масштабироваться по использованию ЦП или памяти? Если на ЦП, что я должен попытаться снизить среднюю загрузку ЦП?
Да, и да, я буду покупать поддержку у 10gen, чтобы они могли проверить мою модель документа и убедиться, что я храню данные наиболее эффективным способом.
«Вообще говоря», нет числа, под которым вы должны держать свой процессор. Если у вас четырехъядерная система, и ваше приложение хорошо работает при средней нагрузке 12, то вам больше возможностей. Вам действительно нужно проверить и определить эти вещи самостоятельно. В средней загрузке ЦП отражается гораздо больше, чем просто то, что он делает.
Я оставлю базовые настройки производительности, такие как рендеринг на стороне клиента, параллелизм, кэширование, nginx и т. Д., На ваше усмотрение в Google и перейду к некоторым эксклюзивным.
1. Отключите алгоритм Нэгла: Если вы хоть немного знакомы с сетевым программированием в реальном времени, вы узнаете этот алгоритм как обычную настройку сокетов. Благодаря этому каждый ответ покидает сервер намного быстрее.
Настройка доступна через API node.js. socket.setNoDelay, который устанавливается для каждого сокета соединения COMET с длительным опросом.
2. Пул соединений Mongodb: Создание новых аутентифицированных соединений с базой данных стоит дорого. Таким образом, вместо того, чтобы создавать и уничтожать соединения для каждого запроса к базе данных, вы хотите как можно больше повторно использовать существующие соединения.
Вы можете найти множество других настроек производительности на airpair или medium, но в вашем случае эти два повлияют больше всего.
Примечание: Топология развертывания и стратегия балансировки нагрузки также будут иметь большое значение. Я бы сказал, используйте NGINX в качестве RP перед вашим сервером-узлом и позвольте ему обрабатывать всю балансировку нагрузки между несколькими экземплярами узлов!