Масштабируемость важно, но масштабирование, когда вы нужно, также важно. У всех нас нет потребности в масштабировании Facebook или Twitter:) Это может просто быть примером управления ресурсами.
Тест проблема
Без базы данных и с помощью NodeJS, некоторые из преимуществ узла являются его количество одновременных соединений. Для простой загрузки io, похоже, вы выбрали хороший выбор фреймворка. И, поскольку ваш набор проблем - это конкретный ресурс, подвергаемый бомбардировке, выполните некоторое тестирование нагрузки на вашем сервере. Популярные и бесплатные инструменты включают в себя:
И есть оплата услуг как NeoLoad, LoadImpact (который является бесплатным при малых уровнях), forecastweb, E-Load , и т. д.
С этими результатами определите причину
Это размер файла, который будет подан? Это количество одновременных запросов? Какие ресурсы используются или превышены во время замедления (ram, ports, файловая система, некоторые другие IO, CPU, пропускная способность и т. Д.)?
Посмотрите на this question, который определяет несколько концепций загрузки сервера. Чтобы реализовать решение, вам нужно будет определить причину замедления. Это: 1) Некоторые очереди заполняются? 2) Проблема с TCP-соединениями и портами? 3) Слишком медленное распределение ресурсов? Это поможет сформировать ваше решение.
План для масштабирования.
Тип масштабирования, необходимый для вашего проекта, может быть только частью, необходимой для другого. Если вы знаете основную причину в этом случае, это увеличит ваши параметры.
Является ли проблема пропускной способностью? Возможно, использование вашего веб-сервера в качестве маршрутизатора для нескольких облачных экземпляров файловой службы будет эффективно увеличивать пропускную способность, которую видят ваши пользователи. Даже просто хранить ваши файлы в большом облаке, что может гарантировать пропускную способность, которая вам может понадобиться.
Является ли проблема ЦП, ОЗУ и т. Д.? Вам может потребоваться несколько экземпляров одного и того же веб-приложения (или увеличенного выделения для вашей VFS). Это «эластичная» часть Elastic Cloud Computing от Amazon (EC2) и другие модели. Создайте «золотое изображение» и дублируйте, когда увидите, как начинается запуск трафика, используя встроенные средства мониторинга, отключая его, когда происходит спешка. Может быть программным или просто ручным.
Является ли проблема одновременными запросами? Узким местом не должно быть NodeJS, до 1000 одновременных запросов. Возможно, просто проверьте свою реализацию, чтобы убедиться, что поток нитей одного узла не замедляется. Возможно, node clustering или некоторые worker threads облегчат узкое место, достаточное для ваших целей.
Последняя Примечание: Для обслуживания статических файлов, которые я слышал nginx или даже Apache Tomcat немного более хорошо подходит, чем NodeJS. В зависимости от сложности вашего веб-приложения вы можете легко или легко переключаться или тестировать.
Знаете ли вы, что большой объем трафика придет? Вы знаете, как долго это продлится? – clay
Нет, учитывая, что это происходит, когда одна из моих картин вызывает большой интерес в социальных сетях/reddit и т. Д. Это довольно непредсказуемо, хотя обычно большие пики будут длиться пару дней. –
Проблема в том, что сервер не может обрабатывать достаточное количество одновременных запросов или что каждый запрос слишком долго реагирует? Вы пишете свой веб-сервер, который обрабатывает эти запросы? – clay