У меня есть веб-сайт, который обменивается данными через XMLRPC с веб-службой сервера XMLRPC. (Веб-сервис написан на Python с использованием xmlrpclib.) Я считаю, что xmlrpclib будет блокироваться, пока он обрабатывает один запрос.
Таким образом, если впереди вас три пользователя с запросом xmlrpclib, ваш ответ займет в четыре раза больше времени.
Как мне справиться с этим, если я получаю слишком много запросов XMLRPC, а веб-служба зависает и имеет медленное время ответа?
Если я получаю косую черту, я предпочитаю, чтобы первые пользователи получали хорошее время отклика, а всем остальным предлагалось вернуться позже. Я думаю, что это лучше, чем дать всем ужасное время ответа.
Как мне создать такое поведение? Это называется балансировкой нагрузки? На самом деле я не занимаюсь балансировкой, пока у меня не будет несколько серверов.
Ну, во-первых, есть ли способ переделать сервер XMLRPC, чтобы он мог обрабатывать несколько одновременных запросов? Наличие нескольких веб-сеансов зависит от службы, которая может выполнять только один запрос за раз, вероятно, НЕ будет сокращать ее для использования в реальном мире. Внутренний корпоративный сайт с низким трафиком может сойти с рук, но в реальном мире - никак.
Теперь, с учетом сказанного, я думаю, вам нужно предоставить немного больше информации о платформе веб-сервисов, чтобы получить ответы, которые вы можете использовать. Лучшее, что я могу сказать на данный момент, - это «подсчитать невыполненные запросы XMLRPC на веб-сервере и потерпеть неудачу, если их слишком много», но это настолько типично, что бесполезно.
Вы можете ограничить скорость подключений, используя iptables с заявлением вроде:
iptables -A INPUT -p tcp --dport 22 -i ! vlan28 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP
Как видите, мы используем это, чтобы ограничить скорость, с которой ssh-соединения могут устанавливаться на наших серверах, но, изменив номер порта или другие переменные, вы можете использовать это практически в любой ситуации.
Вы можете решить эту проблему, поставив обратный прокси перед сервером XMLPRC. Обратный прокси-сервер можно настроить так, чтобы он имел только одно соединение с сервером XMLPRC и при этом имел другое максимальное количество возможных подключений, которые публика может установить с ним, скажем, 10.
Например, на внутреннем сервере Apache для MaxClients может быть установлено значение «1», а для внешнего обратного прокси-сервера Nginx могут быть установлены ограничения на подключение до 10 клиентов, использующих worker_processes и worker_connections.
Таким образом, до 10 клиентов могут подключаться к обратному прокси-серверу и помещаться в очередь до тех пор, пока сервер XMLPRC не станет доступным (при условии некоторого значения времени ожидания). Если одновременно установлено более 10 подключений, обратный прокси-сервер может просто не ответить. Итак, вы, вероятно, захотите настроить это так, чтобы вы могли ставить в очередь столько соединений, сколько вы можете ответственно обработать.
Детали зависят от реализации. Я успешно использовал как HAProxy, так и Nginx в качестве обратных прокси, и считаю, что с Nginx более приятно работать.
Я также согласен с приведенным выше отзывом о том, что возможность обслуживать только один запрос за раз на серверной части звучит так, как будто это может быть проблемой!