я тут пытаюсь понять, как правильный HTTP-сервер должен себя вести. хочется услышать критику к подходам и методам.
рассуждаю в терминах жабы, но все кто осилил http://docs.oracle.com/javase/7/docs/api тоже приглашаются к дискуссии.
- Когда пишешь http-сервер первый раз, то на каждый accept() создаёшь новый
Thread с обработчиком.
Это может привести к неконтролируемому росту потоков
- Когда пишешь http-сервер второй раз, то после каждого accept() кладёшь
Runnable в newFixedThreadPool.
Это может привести к тому что из-за нескольких keep-alive соединений, ты
новые соединения обрабатывать перестанешь
- В третий раз, у тебя уже ThreadPoolExecutor с SynchronousQueue. Всё по
честному, без обработчика будет висеть не более одного коннекта.
Это нехорошо, что у тебя количество соединений ограничено числом воркеров.
- В четвёртый раз, я хочу использовать ThreadPoolExecutor в ArrayBlockingQueue,
с размером очереди в разы большим чем число потоков. В конце каждого run()
вместо цикла будет проверяться — если коннект всё ещё жив, то делается
offer() в очередь в обход ThreadPoolExecutor.submit(). Если не удалось —
закрываем соединение. Ибо нефиг.
Это наверное грешно.
8 comments
recommend
bookmark
subscribe
В java же есть I/O с мультиплексированием через java.nio (смотреть в сторону каналов), али это больно низко уровнем ?
мне кажется это не совсем имеет отношение к тому в каком порядке и во сколько потоков обрабатывать соединения
Вероятно, да. Но асинхронная манера работы всяко позволит более гибко выбирать дальнейшую судьбу обработки: использовать ли пул, или все отдавать одному воркеру. Event-driven все-таки, как метко высказался Ктулху.
event-driven или нет, но количество воркеров (т.е. потоков, которые обработают уже распаршенный GET-запрос) у тебя будет всё равно конкретное количество и соединения у тебя будут физические, с которыми нужно что-то сделать.
Гм, ладно, это я, видимо, не в ту степь полез.
Кстати, если интересно, как на жавке пишут http сервера, то вроде вот что-то: http://code.google.com/p/rupy/
в официальной доке по HttpCore пишут: Contrary to the popular belief, the performance of NIO in terms of raw data throughput is significantly lower than that of blocking I/O.
Там же пишут, что в случае большого числа соединений лучше NIO.
Это уже какая задача.
там где много асинхронных соединений я использую NIO, а там где гигабайты данных приходят, юзаю обычный HttpCore