Архитектура сервера?

Привет всем. Сейчас есть такая архитектура сервера:



Приложение в цикле каждые 100 мс делает вычисления, создает локальное tcp-соединение (с nginx-cервером), POST-запросом через это соединение отправляет информацию ~30-40 байт, закрывает соединение.



Естественно, это очень медленно, а причин несколько:

  • 100 мс, достаточно маленький интервал
  • TCP-соединение создается каждый апдейт цикла (О Keep-alive знаю, но поможет ли?)
  • Собственно, POST-запрос. HTTP-протокол для таких вещей ущербный




Прошу вас помочь в ускорении всего этого.

Во-первых, была идея не создавать подключение каждый раз, а сохранять Keep-alive, но дело в том, что таких вот приложений может быть тысячи запущенных одновременно, и все это на одном хосте. Не знаю, что лучше: держать серверу постоянное подключение или пересоздавать его.



Еще, наверное, стоит выбросить вообще POST-запрос и HTTP.



Будет лучше ли такая реализация:

Выбрасываю вообще nginx (он был звеном между приложением, которое раздавало информацию и клиентами, читающими GET-запросами)

Клиенты напрямую соединяются по TCP к серверу, настраивают, говорят информацию о себе и потом называют udp-порт, приложение соединяется с ним и начинает слать напрямую поток данных.



Что скажите, буду благодарен за любую подсказку.
  • Вопрос задан
  • 4660 просмотров
Решения вопроса 1
@da0c
Да, второй вариант с related UDP предпочтительнее. Есть однако над чем подумать.
1. А клиенты по UDP соединиться смогут (нет ли фаервола)? Можно конечно использовать UDP 53…
2. А клиентов вы как будете распространять? При работе по HTTP клиент получается браузерный, т.е. распространение как бы на халяву. Любой клиент на основе сокетов придется распространять в бинарном виде.
3. Еще стоит подумать об udp vs tcp. Если у вас сервер и клиент в пределах одной локалки, то однозначно — udp. Если вам важен порядок получения пакетов клиентом по интернет, то придется реализовывать какой-то свой протокол с нумерацией внутри udp.
Как показывает практика uTorrent, переимплементация TCP на UDP доставляет профит. Но нужно трезво оценивать, что 20% выигрыша в скорости будут стоить 80% усложнения кода.
Если писать свой транспорт с гарантией доставки не хочется, а гарантия доставки тем не менее нужна, то можно использовать TCP, забив на небольшой оверхед. А может и правда взять uTP.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
Zelgadis
@Zelgadis
Используйте ZeroMQ для связи. Биндинги есть к любому языку наверное.
Ответ написан
Комментировать
@mitric
Конечно http здесь избыточен. Слать данные в открытое постоянное сокет-соеденение будет быстрее. Делал такое на одной машине и между удаленными.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы