2016-04-06 3 views
3

У меня есть приложение JRuby с использованием целлулоида. Он получает запросы через сокет Zeromq и отвечает строкой JSON.Задержка обработки больше запросов/сек

Итак, в моем приложении есть 2 актера для обработки запросов, а другой для отправки ответа (Push-разъем в Zeromq). Приложение получает запросы со скоростью около 30 запросов в секунду. Было бы больше в будущем сказать 1000/сек. Но при увеличении количества запросов в секунду требуется больше времени для обработки. Он начинает использовать больше CPU.

Для каждого полученного запроса я обрабатываю это внутри блока отсрочки.

defer { 
    response = ResponseHandler.new(socket,message).start 
    send_response(response) 
} 

В течение 20 запросов/сек он отлично работает без каких-либо задержек. Сервер имеет конфигурацию с 15 ГБ оперативной памяти и 4 ядра. Он подключается к DB Postgres и Redis DB. Но, похоже, это не проблема.

Вот основная структура у меня есть, есть главный актер службы,

supervisor = Service.supervise 

это внутренне создает экземпляры PushSock Актера с 10 бассейном.

@pushsocket_actor = PushSock.pool(size: 10) 

метод send_response в отложенном блоке выше вызовов pushsocket actor. В отложенном блоке ResponseHandler не актер.

Так что с сервисом, я не пользуюсь бассейном.

+0

Вы используете 'Celluliod :: IO' напрямую? Есть ли у вас какие-либо сущности кода? – digitalextremist

+0

Нет, я не использую Celluliod :: IO –

ответ

2

Используйте бассейн.

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

Вы должны быть реалистами относительно ваших потребностей в ресурсах, хотя! Знаете ли вы, сколько вам нужно за запрос? На основе этого вам необходимо спланировать свою стратегию актера.

Не используйте слишком много или слишком мало актеров. Прямо сейчас, вы используете слишком много потоков, я подозреваю, потому что использование defer {} не устанавливает ограничений, таких как async, если использовать их с реалистичным размером пула.

+0

Я обновил свой вопрос с помощью базовой структуры в приложении. Итак, вы имеете в виду, что я не должен использовать отсрочку и вместо нее использовать async? –

+0

async также порождает новую тему, не так ли? –

+0

'async' использует другой вид прокси -' defer {} 'вызывает использование' Future' -прокси и неограниченно. Если вы используете пул и 'async', он будет ограничивать количество вызовов async числом участников, которые у вас есть в пуле ... что важно. – digitalextremist