Может ли общественность посоветовать библиотеку для HTTP-клиента, которая работала бы наподобие С-шного epoll-multiplexed client?
Примерно следующим образом: есть некий call manager, который должен с очень высокой стабильностью (в идеале с джиттером не более 1 мс) инициировать HTTP-запросы. Которые выполняются довольно долго (вплоть до десятков секунд), и которых в общем случае ожидается от 60 до 400 в секунду (норма — примерно 4000 concurrent HTTP-запросов). Реализация "в лоб" на HTTPClient от Апачей порождает несколько тысяч тредов, после чего все начинает ворочаться с заметными тормозами, и даже главный поток начинает генерировать новые запросы с весьма нестабильными таймингами. Можно ли как-нибудь в одном треде ожидать чтения более 1 сокета?
На С задача довольно тривиально решается epoll'ом в единственном потоке — заранее создается pool TCP соединений, заготавливается кэш вызовов, и в нужную миллисекунду просто вызывается send() в сокет. Но на этой железке по условиям задачи доступа к NDK нет. Зато Java 7 есть (в ближайшей перспективе 8). Есть какие-нибудь варианты?
Не открывает. Запускает реактор с небольшим количеством потоков, и через него параллельно можно тысячи запросов слать.
Тривиальная прокся на HttpCore NIO + HttpAsyncClient у меня без проблем держит 15k rps при пятистах входящих соединениях.
Здравствуйте, SkyDance, Вы писали:
SD>Там первый NIO. Попробую еще разобраться, но, кажется, оно тоже открывает тысячу потоков.
То что в NIO.2 появился AsynchronousChannel ещё не значит что в NIO первой версии принципиально не возможно организовать асинхронный I/O.
Да, всё получилось с асихнронностью, но тормознутость и полное отсутствие документации вымораживает конкретно. Даже простые задачи непонятно как делать. К примеру, как принудительно за-pool-ить 10 открытых HTTP соединений, чтобы они держались в готовом виде и можно было в любой момент послать сообщение?
И можно ли как-нибудь ускорить процесс между вызовом execute() и собственно физической отправой сообщения? А то оно там в кишках еще почти 300 мкс. какой-то фигней занимается.
A>А что за сервис пишешь, если не секрет, что 300мкс настолько критичны?
Часть сервиса, где синхронизируется время. Мне нужно ровно в 00:00 отправить нескольким клиентам определенные сообщения. Клиенты стары, как экскременты древних гигантов, новый сервис весь на Java, так что выбора особо нет.
Здравствуйте, SkyDance, Вы писали:
A>>А что за сервис пишешь, если не секрет, что 300мкс настолько критичны?
SD>Часть сервиса, где синхронизируется время. Мне нужно ровно в 00:00 отправить нескольким клиентам определенные сообщения.
Даже если ты победишь 300мкс, как быть с задержками в сети? А клиенты вообще в локальной сети или во внешней?
A>Даже если ты победишь 300мкс, как быть с задержками в сети? А клиенты вообще в локальной сети или во внешней?
Задержеки в сети известны и практически неизменны. На самом деле, если б там 300 мкс стабильно было, я бы даже не подумал писать. Но там вообще непредсказуемо — 300 мкс — это минимально.
В принципе, я посмотрел, что там внутри происходит, и причины задержек несложно понять. От объектов HttpPost до собственно записи в сокет там столько всяких слоёв наворочено, что быстро (и предсказуемо) это работать не может. Видимо, придется колхозить что-то еще.
