Т.е. собираем образ с приложением, и образ nginx'а со статикой этого приложения?

Да

Потому что Apache это сделает быстрее

Нет, не быстрее. И апач по пути съест всю память

Приехали

На статике нет

Больше чем енжинкс и нода

Но быстрее ноды точно

На статике нет

Вот сразу видно людей не знающих отличий мультиплексоров от prefork

когда упрешься в производительность ноды в 1 потоке

so_reuseport и вот это всё, если говорить о линуксе. Ядро само раскидает запросы между воркерами

@pragus прав, апачу очень плохо при большом кол-ве медленных соединений. Но отсюда и ответ, почему nginx лучше Node для статики - зачем ноде заниматься этим? Ей своей "динамики" с головой хватает. А обслуживанием внешних клиентов с медленным и лагающим инетом пусть занимается nginx.

Пусть будет по вашему Роман.

@pragus прав, апачу очень плохо при большом кол-ве медленных соединений. Но отсюда и ответ, почему nginx лучше Node для статики - зачем ноде заниматься этим? Ей своей "динамики" с головой хватает. А обслуживанием внешних клиентов с медленным и лагающим инетом пусть занимается nginx.

Некоторые вещи не сделать на nginx :( либо будет очень медленно

Например?

Я не спорил вообще, если есть вариант отдавать статику апачем или нодой, лучше апач

Если есть енжинкс, лучше в разы

openresty для тех случаев есть

Мы же тут не про хайлоад трем

Я не спорил вообще, если есть вариант отдавать статику апачем или нодой, лучше апач

Я не понимаю вашего упрямства с апачем. Апач тратит процесс/тред на каждый коннект. Если у тебя 4к коннектов, то это 4к процессов.

Вы со статикой быстрее в канал упретесь чем в память

Мы же тут не про хайлоад трем

Это не про хайлоад. Машина с апачем элементарно досится даже с gprs

Я не упираюсь, Апач терпеть не могу как и попытки использовать язык какой-то вместо профильного софта типа енжинкса

Машина с любым сервисом наружу ддоситься

Это не про хайлоад. Машина с апачем элементарно досится даже с gprs

Факт. Раньше так "клали" довольно крупные проекты. Но не суть. Зачем насиловать труп?) Роман, можно пример проблем с nginx?

Лично я против костылей в виде ноды отдающей статику

+1

на продакшн ноде не место (статика)

Лично я против костылей в виде ноды отдающей статику

Для localhost.dev вполне уместная штука.

Даже динамику можно качественно отбывать nginx + ssi

Не учителя людей плохому, запроксировать контент статичный и сервис в роде 10 минут гугления

Ноде*

Факт. Раньше так "клали" довольно крупные проекты. Но не суть. Зачем насиловать труп?) Роман, можно пример проблем с nginx?

мм... мне надо отдать файл с диска, потом сходить к внешнему сервису, получить путь к следующему файлу, снова отдать его клиенту. всё это в рамках одного tcp коннекта. т.е. для клиента это должно выглядеть как tcp-коннект, из которого периодически льются данные.

Это уже не статика

это первая проблема. вторая проблема - на моих задачах уж слишком много начинает занимать копирование памяти

Это уже не статика

с чего бы вдруг? всего лишь надо несколько файлов с диска склеить и отдать как один

Потому что у вас логика

Какой файл следующий

В одной точке входа

В разных случаях вернётся разный набор файлов

То что вы отдаёт кстати ярый контент это другой разговор

Статичный контент*

да не файл, а поток байт.

Ваша ручка возвращает Динамику

Все поток байт;)

В статике это одинаковый результат

Ваша ручка возвращает Динамику

ну окей. пусть будет динамика.

да не файл, а поток байт.

А этот поток можно сформировать и положить на диск, чтобы потом отдавать через nginx? Если да, то так и надо делать. Иначе, действительно, динамика получается.

Ну в таком случае openresty, golang

Если много

Либо много НОД за балансировщикамм

Всегда можно запросить контент

И получить редирект на поток байт в виде файла

Который вы дописываете быстрее чем его читают

Либо много НОД за балансировщикамм

А балансировщик всё равно nginx с кучей upstream) Вот и пришли опять к неизбежности его наличия.

Енжинкс хорошо

Нода не балансировщик

И н сервер раздачи статики

Именно. Даже нативный cluster лучше заменить балансировкой на nginx.

Нативный кластер?)

Он ужасен

Код посмотрите

upd

Udp т.е.

Я о том и говорю. Но он не ужасен, у него цель другая просто.

Дайте нагрузку и теряйте пакеты

nginx - плохой балансер

ERROR: S client not available

А хапрокси не лучше

Быстрее но не лучше

nginx - плохой балансер

Вполне хороший. Ведь речь не о хайлоаде, как выше было сказано?

Что тотдопиливать на луа придется

Работать пора)

В общем, тут спорить вообще не о чем, на мой взгляд. Правило простое: всё внешнее (что дальше вашего сервера) - тормозное и лагающее непонятно-что, и его всегда надо обслуживать отдельным процессом. Что за процесс будет - вопрос второй уже.

Вполне хороший. Ведь речь не о хайлоаде, как выше было сказано?

просто если не хайлоад - то можно использовать вообще всё что угодно.

Ну да. На сайте про любимиго домашнего кота. Но речь всё-таки о более-менее живых и настоящих проектах. И лишь 1 из 1000 таких как-то нагружен. В остальных можно применять компромиссные решения.

ну я вот видео раздаю. совсем немного, но всякие особенности уже дают о себе знать

С видео не работал, увы. Тонкостей там полно. Для чего-то солидного с видео раньше народ любил эрлангом обмазаться. Сейчас, наверное, стоит смотреть в сторону go. Но тут чатик с Нодой, поэтому надо брать её и пытаться оптимизировать.

Если аккуратно работать с бинарными данными - то все должно быть вполне ок

Если аккуратно работать с бинарными данными - то все должно быть вполне ок

угу. о том и речь.

В частности, если речь идет о видео, то я бы сделал пул с буферами фиксированной длиной и утилы для стриминга таких буферов

Нативный кластер хак еще тот. Долго не мог понять кто так его сделать додумался.

Вопрос не в том - как, вопрос - зачем

другого способа-то особо и нет

О, хромиум 53, а я пропустил.

@vkurchatkin Это кстати тот, в котором промисы не такими медленными сделали.

Но им ещё есть куда дальше оптимизировать.

Всем привет! Подскажите плиз. Есть mongoose схемы Account и Window. Они связаны так: var Account = new Schema({ ... windows: [{ type: mongoose.Schema.Types.ObjectId, ref: 'Window' }] }); var Window = new Schema({ ... creator: { type: mongoose.Schema.Types.ObjectId, ref: 'Account' } }); окна в аккаунт я добавляю так: var window = new Window({ ... creator: mongoose.Types.ObjectId(req.user._id) }); window.save(); Account.findByIdAndUpdate( req.user._id, { $push: { "windows": window } }, { safe: true, upsert: true, new: true }, function (err, user) { if (err) console.log(err); req.logIn(user, function (err) { if (err) return next(err) res.send({ success: true, window: window }); }) } ); А удаляю так: Window.findOne({ id: req.body.id }, function (err, window) { if (err) console.log(err) Window.findOne({ _id: window._id }).remove(function (err, data) { if (err) console.log(err); Account.findOneAndUpdate({ _id: req.user._id }, { $pullAll: { windows: [{ _id: window._id }] } }, function (err, user) { if (err) { console.log(err); } req.logIn(user, function (err) { if (err) return next(err) res.send({ success: true, window: req.body.id }); }) }); }) }); Как то это оч странно выглядит. Подскажите как это должно быть, плиз

http://telegram.wiki/tips:tdesktopcodesnippets

а то вырвиглазненько

поправил :)

а что смущает?

удаление как из коллеции окон так и из массива в поле аккаунта

по идее это же один объект

в массиве то только ссылка

а я думал отсутствие промисов

это тоже

findOneAndRemove

это не прокатывает?

@vkurchatkin Это кстати тот, в котором промисы не такими медленными сделали.

Меня не очень беспокоит производительность промисов