NK
я конечно подозреваю что можно использовать его plack интерфейс и его завернуть в fastcgi...
Size: a a a
2021 September 14
W
Ну вот только так.
W
Просто потому что он сам занимается парсингом HTTP сообщений и предоставляет свой request / response объекты. Ибо без этого скорость падает.
W
Мы сейчас для него пилим Роутер быстрый и дальше будет уже фреимворк (То что у каталиста называется $c).
NK
кстати, поленился в гитхабе сделать тикет, но почему все так не любят в примерах добавлять пример когда всё вешается на юникс сокет, а не на порт?
NK
в мире, где половина софта должна бы, но в принципе не умеет вешаться на юникс сокет - это такая боль
R
FastCGI ни разу не fast. Скорее это просто такой интерфейс между проксей и бегендом.
W
Потому что Юникс сокеты медленные.
NK
ну это не так же
W
Юникс сокеты, если мне не изменяет мой склероз, это всегда однопоток-же
W
(Могу ошибаться, вскользь работал с этим и давно уже)
R
если DGRAM
стримовые мало чем от TCP отличаются
стримовые мало чем от TCP отличаются
NK
google: is unix socket faster than tcp
W
А Stream они умеют в многопоточность?
W
https://unix.stackexchange.com/questions/615330/what-happens-when-two-processes-listen-on-the-same-berkeley-unix-file-socket
Вот тут говорится что 2 процесса не могут сделать bind на unix сокеты.
Вот тут говорится что 2 процесса не могут сделать bind на unix сокеты.
W
А это значит что вы ограничены одним серверным потоком, что убивает производительность в ноль
NK
я вообще ничего примерно не знаю про всё интерналс, но никакой проблемы с мультиплексированием на евентах нет
NK
а UniEvent то сокеты вообще поддерживает?
W
Стоп... Тут подмена понятий
W
Если вы поднимаете один поток, то unix socket будет работать быстрее чем TCP. Да.
Если вы поднимаете 10 процессов, то в unix socket'е слушать может все равно только один, а в TCP - все 10 процессов и тут unix socket сливает.
Если вы поднимаете 10 процессов, то в unix socket'е слушать может все равно только один, а в TCP - все 10 процессов и тут unix socket сливает.