Замена длительного опроса на WebSockets

Вопрос или проблема

У меня есть экземпляр Apache, на котором 150 клиентов используют долгий опрос на некоторых PHP-скриптах, чтобы получать обновления о новых загруженных файлах. Это, конечно, создает 150 потоков Apache. Теперь, кажется, веб-сервер достиг своего предела (это 10-летняя машина), и я не хочу переносить этот багаж на новый сервер.

Я думаю о том, чтобы использовать сервер WebSocket, который бы более эффективно обрабатывал этот случай, но интересуюсь, создадут ли 150 клиентов, обращающихся к Apache, который перенаправляет запросы на мой сервер WebSocket, также столько же потоков Apache или есть более эффективный способ справиться с этим.

Я не могу заменить Apache, только, может быть, на nginx, потому что он также должен предоставлять главную страницу. Я не могу использовать другой порт для сервера WebSocket, потому что это означало бы, что мне нужно будет обсуждать обновление правил файрвола с примерно 100 клиентами. Это решаемо?

Вы, вероятно, можете поставить Nginx перед ним в качестве прокси. Затем вы настраиваете его на перенаправление обычного трафика на Apache и используете специальный путь для веб-сокета, чтобы вы могли создать блок Nginx, который проксирует это на ваш сервер веб-сокетов.

Таким образом, у вас будет два блока:

location / {
    proxy_set_header  X-Real-IP       $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  Host            $host;
    proxy_pass https://1.2.3.4;
  }


location /websocket/ {
    proxy_set_header  X-Real-IP       $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  Host            $host;
    proxy_pass https://4.3.2.1;
  }

Пути сопоставляются по спецификации, а не по порядку.

Ответ или решение

Замена долгого опроса на WebSockets

Ваша текущая архитектура с использованием долгого опроса создает значительную нагрузку на ваш сервер Apache благодаря созданию более 150 потоков для работы с клиентами. Этот подход, хотя и рабочий, вряд ли эффективен в условиях ограниченных ресурсов, особенно когда оборудование уже устарело. Переход на WebSockets — разумный шаг к оптимизации производительности. Однако, чтобы реализовать данное решение, необходимо учесть несколько аспектов, о которых я расскажу ниже.

1. Понимание WebSockets

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

2. Архитектура с использованием Nginx

Для решения проблемы с обновлением правил файрвола и ограничения использования портов вы можете использовать Nginx в качестве прокси-сервера перед вашим WebSocket-сервером. Это даст вам возможность отделить нормальный HTTP-трафик и трафик WebSocket, используя единую точку входа для клиентов.

Ваша конфигурация Nginx может выглядеть следующим образом:

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_set_header  X-Real-IP       $remote_addr;
        proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header  Host            $host;
        proxy_pass http://localhost:8080;  # ваш Apache сервер
    }

    location /websocket/ {
        proxy_set_header  X-Real-IP       $remote_addr;
        proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header  Host            $host;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_pass http://localhost:9090;  # ваш WebSocket сервер
    }
}

Здесь:

  • Первая часть конфигурации обрабатывает обычные HTTP-запросы, перенаправляя их на сервер Apache.
  • Вторая часть обработки предназначена специально для запросов по WebSocket, с использованием специального URI (/websocket/). Это будет инициировать соединение WebSocket, которое передается на отдельный сервер, работающий на порту 9090.

3. Эффективность и производительность

Переход на WebSockets существенно уменьшит количество активных потоков на вашем сервере Apache. Вместо 150 одновременных подключений, которые блокируют ресурсы сервера под долгий опрос, вы сможете обрабатывать гораздо больший объем трафика с помощью одного, постоянно открытого WebSocket-соединения для каждого клиента. Это не только освободит ресурсы вашего старого сервера, но и улучшит пользователям опыт работы с приложением.

4. Изменения для клиентов

Поскольку вы не можете изменить порт, требуется минимизация изменений для ваших клиентов. С помощью Nginx вы можете настроить прокси на входящие WebSocket-запросы без изменения клиентских настроек. Вам нужно будет только убедиться, что все запросы к WebSocket происходят через правильный путь (/websocket/), но без изменения используемого порта.

Заключение

Переход с долгого опроса на WebSockets — это шаг к более эффективной и производительной архитектуре для вашей системы. Использование Nginx как прокси-сервера убережет вас от сложных изменений сетевой инфраструктуры и потенциал проблемы с доступом для ваших клиентов. Правильно настроенная схема не только облегчит нагрузку на сервер, но и улучшит качество обслуживания. Настоятельно рекомендую тщательно протестировать новую архитектуру и мониторить производительность на раннем этапе, чтобы гарантировать, что вы получаете желаемые результаты.

Оцените материал
Добавить комментарий

Капча загружается...