узел.сам JS или интерфейс nginx для обслуживания статических файлов?
есть ли какой-либо тест или сравнение, которое быстрее: поместите nginx перед узлом и позвольте ему обслуживать статические файлы напрямую или использовать только узел и обслуживать статические файлы с его помощью?
решение nginx кажется мне более управляемым, какие-либо мысли?
6 ответов
Я должен не согласиться с ответами здесь. Хотя узел будет делать все хорошо, nginx, безусловно, будет быстрее при правильной настройке. nginx эффективно реализован в C по аналогичному шаблону (возврат к соединению только при необходимости)с небольшим объемом памяти. Кроме того, он поддерживает функция sendfile syscall для обслуживания этих файлов, которые так быстро, как вы можете получить на обслуживание файлов, так как это само ядро ОС, что делает работу.
By теперь nginx стал стандартом де-факто в качестве frontend сервера. Вы можете использовать его для его производительности в обслуживании статических файлов, gzip, SSL и даже балансировки нагрузки позже.
P. S.: Это предполагает, что файлы действительно "статичными", как в на диске в момент запроса.
Я ab -n 10000 -c 100 для обслуживания статического байта 1406 favicon.ico, сравнение nginx, Express.JS (статическое промежуточное ПО) и кластеризованный Экспресс.js. Надеюсь, это поможет:
к сожалению, я не могу проверить 1000 или даже 10000 одновременных запросов, поскольку nginx на моей машине начнет бросать ошибки.
редактировать: как предложил artvolk, вот результаты кластера + static промежуточное ПО (медленнее):
в любом случае, я бы настроил Nginx для кэширования статических файлов...вы увидите огромную разницу. Затем, независимо от того, обслуживаете ли вы их с узла или нет, вы в основном получаете одинаковую производительность и одинаковую нагрузку на приложение узла.
Мне лично не нравится идея моего интерфейса Nginx, обслуживающего статические активы в большинстве случаев, в этом
1) проект теперь должен быть на одной машине - или должен быть разделен на активы (на машине nginx) & web приложение (на нескольких машинах для масштабирования)
2) конфигурация Nginx теперь должна поддерживать местоположения пути для статических активов / перезагрузки при их изменении.
У меня другая интерпретация диаграмм @gremo. Мне кажется, что и node и nginx масштабируются с одинаковым количеством запросов (между 9-10k). Конечно, задержка в ответе для nginx ниже на постоянные 20 мс, но я не думаю, что пользователи обязательно заметят эту разницу (если ваше приложение построено хорошо). Учитывая фиксированное количество машин, потребовалось бы довольно значительное количество нагрузки, прежде чем я преобразовал бы машину узла в nginx, учитывая, что этот узел нагрузки будет происходить в первую очередь. Один контрапункт к этому-если вы уже посвящаете машину nginx для балансировки нагрузки. Если это так, то вы также можете использовать его для своего статического контента.
Это сложный вопрос, чтобы ответить. Если вы написали действительно легкий сервер узлов, чтобы просто обслуживать статические файлы, он, скорее всего, будет работать лучше, чем nginx, но это не так просто. (вот "эталон" сравнение файлового сервера nodejs и lighttpd - который похож по производительности на ngingx при обслуживании статических файлов).
производительность в отношении обслуживания статических файлов часто сводится к большему, чем просто веб-сервер делает работу. Если вы хотите максимально высокая производительность, вы будете использовать CDN для обслуживания файлов, чтобы уменьшить задержку для конечных пользователей и воспользоваться кэшированием edge.
Если вы не беспокоитесь об этом, node может обслуживать статические файлы в большинстве случаев. Узел поддается асинхронному коду, на который он также полагается, поскольку он однопоточный, и любой блокирующий ввод-вывод может заблокировать весь процесс и снизить производительность приложений. Скорее всего, вы пишете свой код в неблокирующем режиме мода, но если вы делаете что-то синхронно, вы можете вызвать блокировку, что ухудшит скорость обслуживания других клиентов статическими файлами. Простое решение-не писать блокирующий код, но иногда это невозможно, или вы не всегда можете его применить.
Я уверен, что чисто узел.js может превзойти nginx во многих аспектах.
все сказали, что я должен остаться NginX имеет встроенный кэш, тогда как узел.js не поставляется с установленной фабрикой (вы должны создать свой собственный кэш файлов). Пользовательский кэш файлов превосходит nginx и любой другой сервер на рынке, поскольку он очень прост.
также Nginx работает на нескольких ядрах. Чтобы использовать весь потенциал узла, вы должны кластеризировать серверы узлов. Если вам интересно знайте, как тогда, пожалуйста, pm.
вам нужно глубоко копать, чтобы достичь производительности нирваны с узлом, это единственная проблема. Однажды сделал ад да... это лучше, чем Nginx.