Delakey Blackhole: и надо еще вешать обработчик на req\res чтобы dispatch чистить, если клиент отвалился а /send все еще не было. ну или честно надеятся что /send будет чаще чем отваливающиеся клиенты всю память сожрут
Delakey Blackhole: у тебя log poll - управление по первому GET тебе вернется только после /send.
Если ты делаешь в одном терминале ```curl -X GET /subscribe; curl -X GET /subscribe``` а во втором ```curl -X GET /send``` то естественно у тебя первый курл не заканчивает работу пока ты send во втором не сделаешь.
А вот если сделатеь вот так ``` (curl -X GET /subs &); (curl -X GET /subs &); sleep 5; curl -X GET /send``` то оба курла отработают как надо
Выдуманные проблемы с рутом (как будто спец прав на нижние порты не надо). Проблема проблема проблема проблема. Ужос ужос. Решение реферера было тут в 11 году. Сессии синхаем между несколькими машинами. Тротлить тоже не проблема.
Ngnix не хакали. Ну кроме одного модуля похожего на коммерческий функционал.
Не пробовал auth_request курить?
dummyman: остановись - ты не знаешь как работает sendfile (включая кэш), не знаешь как работает send, не знаешь какие накладные расходы идут при пересечение границы userspace/kernelspace, не пробовал strace на nginx и ноду, не читал рекомендации и не зная что такое ab делаешь утверждения о перфе
xfg: то, что вы называете RT по определению не является RT. RT подразумевает _гарантированное_ время обработки события.
А в ноде у вас переменная изза переполнения с int на float переползет и вся математика у вас станет в два раза медленее.
Захочет V8 перекомпилировать функцию, и опять тайминги поплыли.
Время реакции на setImmediate зависит от IO. Да и приоритеты для разных setImmediate вы назначить не сможете. Как не сможете назначить приоритеты на разные сокеты.
То что вы имеет ввиду - это real-time web - "buzzword вокруг которого много шума"- что раньше называлось comet, long poll, socket.io you-name-it - но это и на php реализуется (про сокетио только не скажу).
