У нас есть проект, основанный на микросервисной архитектуре (шаблон RPC).Использование торнадо + пика.Для каждого командного работника создается очередь с идентификатором команды для маршрутизации результата обратно.С ростом количества очередей наша производительность падает.Становится невозможным работать около 50 RPS (слишком большая задержка между запросом пользователя и рабочим ответом).У нас была такая же проблема с nameko (nameko почти идентично нашей реализации).Код: обработчик торнадо
class DoNothingHandler(RequestHandler, GetRequestArgsMixin):
"""
Для нагрузочных тестов.
"""
@timed
@result_decorator
@coroutine
def get(self):
args = self.post_args_dict()
connector = yield UserServiceConnector.get_instance()
result = yield connector.execute_command(commands.DoNothing, args)
return result
служебный соединитель
class NamekoServiceConnector(AbstractServiceConnector):
@classmethod
@coroutine
def get_instance(cls) -> 'NamekoServiceConnector':
if not cls._instance:
cls._instance = cls()
raise Return(cls._instance)
def __init__(self, command):
self.config = {"AMQP_URI":""}
self.commands = command
@coroutine
def execute_command(self, command_name: str, args: dict = None):
with ClusterRpcProxy(self.config) as cluster_rpc:
hello_res = cluster_rpc.greeting_service.hello.call_async(args)
result = hello_res.result()
logger.info(f"Got result {result}")
command_result = AbstractResult(result=result)
raise Return(command_result)
тестовый рабочий
from nameko.rpc import rpc
класс GreetingService: name = "reeting_service "
@rpc
def hello(self, id):
return id
Мы протестировали его с помощью сообщений на основе Redis.И работает нормально до 400 RPS.Что мы делаем не так?Может быть, нам нужна другая система обмена сообщениями для шаблона RPC?Хотел получить 500+ RPS стабильной работы