Сильно ли передача по http медленнее, чем напрямую?

Question

[WebDev]

Сайт состоит из трех частей:
api.mysite.com - rest АПИ на php. Работает с базой, принимает и отдает данные.
ws.mysite.com - приложение на node с вебсокетами для риалтайма.
mysite.com - SPA приложение на vuejs, которое взаимодействует с двумя вышеописанными сервисами.
Вопрос в следующем: сервис с вебсокетами тоже пишет данные в базу и тут два варианта:
1) Настроить коннект к базе в nodejs и писать напрямую.
2) Обращаться к api через http.
Второй вариант удобнее, веб сокеты занимаются только обработкой событий, а с базой работает только api.
В этом случае сервис с сокетами выглядит так:

socket.on('message', message => {
    https.get('https://api.mysite...');
    
    socket.emit('...');
});

Полагаю, что установка дополнительного http соединения - это дополнительное время. Критично ли это или можно забить и делать как удобнее?

Answer 1

[rPman]

Если вам нужна скорость, то уходите от постоянного переподключения к сервисам.

Конечно, современные веб-сервера и браузер умеют переиспользовать подключение для http rest, но это стоит перепроверить в вашем случае. Если идут постоянные переподключения то высокие пинги могут превратить работу вашего сервиса в лагучую дрянь (один https добавит пару туда-сюда отправлений).

websocket изначально по определению однократно открывает подключение а затем использование открытого канала возможно в обе стороны (с http rest только в одну и с оговорками в сторону клиента, читай не эффективно).

А еще вопрос, как у вас организован код обработки http rest. Если это старый классический подход, когда на каждый запрос запускается php скрипт это это еще и высоченная нагрузка на сервер, переделывайте (а точнее убирайте эту фигню и оставьте websocket), так как разница подходов дает ускорение на пару тройку порядков (это не шутка и не преувеличение).

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

Comments

[Vitsliputsli]

Ускорение в 100-1000 раз? Позвольте не поверить.
Да, в некоторых ситуациях асинхронность и постоянность ws будет отличным решением (те же spa с постоянным подключением), но в других многопоточность выиграет (к примеру, нужно дать не быстрый ответ, или непостоянные подключения, ведь подключение к ws не быстрое). Имхо, для разных ситуаций, разные инструменты.

[rPman]

Легко, вот ваше приложение обрабатывает 200 в секунду, на каждый отправляя запрос в базу данных (это кстати очень хороший результат для 1 сервера), а вот оно уже обрабатывает порядка 15000 запросов в секунду. на простом десктопном железе (помню пробовал себя, напишу ли я простую торговую биржу на php, ядро обрабатывало типичную нагрузку которая для криптовалютного рынка сейчас является нормой, а тогда это было на порядок быстрее).

Причина - смена парадигмы. Уход не только от запрос-запуск скрипта но и от баз данных как основной источник информации (база данных должна быть инструментом восстановления и резервирования но для доступу к данным классические реляционные или те же document oriented - избыточны).

Что делает http rest приложение чтобы ускориться? кеширует информацию в памяти, какая-нибудь memcached база данных, но даже убрав медленный диск остаются блокировки и синхронизация. Но зачем, когда все приложение может держать все данные в памяти в том виде каком они есть, не затрачивая время на сериализацию, синхронизацию (многопоточность) и прочее прочее...

Answer 2

[grinat]

На практике сокеты годятся только чтобы слушать входящие сообщения. Если в обе стороны, то куча геммора, плюс сокет.ио честно говоря то еще дерьмо. В связке с пыхой, я бы лучше взял https://github.com/centrifugal/centrifugo оно разворачивается в отдельном докер контейнере и с коробки все есть.