legem Oct 17 2011 at 13:10

Пишем простой UDP BitTorrent-трекер на Netty + MongoDB

5 min

13K

Java*

From sandbox

+20

Comments 12

mentatxx Oct 17 2011 at 13:39

А не лучше взять высокопроизводительный и проверенный временем XBT?

-6

legem Oct 17 2011 at 13:46

Ну вообще я ставил целью изучить Netty, MongoDB и UDP-tracker протокол на примере реального приложения, а не «перебить» по производительности XBTT. Сейчас это лишь заготовка, из которой уже можно будет при желании сделать вполне себе стабильный и производительный трекер.

+12

maxcom Oct 17 2011 at 16:32

Executors.newCachedThreadPool() это не слишком правильно — в пике нагрузки может наплодиться много тредов. Лучше делать ограниченный пул с очередью

legem Oct 17 2011 at 19:37

Спасибо, скоро поправлю.

dborovikov Oct 17 2011 at 19:26

У вас там внутри ClientRequest-ов происходит блокирующий вызов к mongo. Это не очень хорошо. Стоит поискать неблокирующую библиотеку для доступа к mongo. И еще. Вы уверены, что Datastore является thread-safe?

legem Oct 17 2011 at 19:41

А можно поподробнее, где и из-за чего блокировка происходит?
А с Datastore похоже действительно могут быть проблемы… Чуть позже переделаю.

dborovikov Oct 17 2011 at 21:16

Блокировки на IO происходят внутри методов Datastore.instance().find/update, так как они написаны в блокирующем стиле. У меня нагуглился вот такой неблокирующий драйвер для монги: github.com/bwmcadams/hammersmith. Но он под Scala, увы.

umputun Oct 17 2011 at 22:27

да, длинные операции нельзя в асинхронных обработчиках делать. Впрочем, в приведенном случае это компенсируется Executors.newCachedThreadPool(), так что будет работать, но иногда как синхронный поток-на-хэндлер сервер, а это, видимо не то, что вам хотелось. Для подобных вещей в Netty есть несколько механизмов, например ExecutionHandler. Можно еще и чанковый ридер прикрутить, но это несколько сложнее.

dborovikov Oct 17 2011 at 23:17

Да, если операции блокировании IO довольно быстрые, то не жалко сделать их асинхронными просто выполняя в отдельном треде. Что касается тред-пула, то лучше завести свой, отдельный, что бы избежать стандартной асинхронной проблемы: медленные операции тормозят все обработчики, попавшие в текущую итерацию io-loop. Увеличивая количество воркеров мы просто уменьшаем количество обработчиков, которым «неповезло» оказаться в одной итерации с медленной операцией.

umputun Oct 17 2011 at 23:21

в Netty воркеры так и берутся из пула, из того, что передается в ChannelFactory. Документация вроде рекомендует cores*2, хотя конечно, это дело разработчика, сколько дать воркеров.

dborovikov Oct 17 2011 at 23:47

Это понятно, что из пула. Но лучше воркеры блокировать как можно меньше. Увеличение количества воркеров не решает проблему блокирования, а просто снижает (не устраняет, а именно снижает) пагубное влияния долгих операций. Если сделать все хендлеры неблокирующими (вообще конечно почти неблокирующими), то хватит как раз тех cores*2, а то и cores просто.

FanKiLL Jan 31 2012 at 15:50

Скажите, а почему вы не использовали encoder и decoder, а «парсите» пакет прям хендлере?
Ещё «Получение сообщений от клиентов.» сделал копи паст в свой tcp проект, и он не коррекно обрабатывает пакеты. Если юзер подключается и посылает 1 пакет и отключается всё норм, но если к примеру придёт больше 1 пакета они не коррекно обрабатываются.

Show the best of all time