Комментарии 41
XBTT вобще жостко оптимизирован на скорость и является на данный момент самым быстрым трекером из тех что мне попадались.
Как побочный результат — достаточно запутанный код, который тяжело затачивать под свои нужды.
Как побочный результат — достаточно запутанный код, который тяжело затачивать под свои нужды.
+1 к оптимизированности, про запутанность кода — мне так не показалось, объектные «плюсы», большая часть логики, которую имеет смысл «затачивать» в одном методе — insert_peer. впрочем, это скорее спор о вкусе и цвете фломастеров :)
Про фломастеры это вы верно подметили :)
Просто я что бы разобраться потратил достаточно много времени.
Просто я что бы разобраться потратил достаточно много времени.
если не секрет — что именно затачивали? в плане обменяться опытом и «заточками»
Я к сожалению сыграл пассивную роль в данном проекте :), все сделал мой товарищ.
Стояла задача заменить PHPBTTracker на XBTT, последний отказывался кушать паскеи.
Проблема оказалась в SHA1 ф-ции, которую пришлось отключить.
Это так, не заточка, а просто нужно было обеспечить совместимость со старой базой.
Позже была идея добавить функционал, так как трекер у нас локальным был, нужно было добавить возможность отдавать список пиров в зависимости от айпи клиента (во внутрисеть — внутресетевые, во внешку — внешние). Вот тут то я и слил, долго думал куда бы приткнуть и так и не осилил по молодости. Сейчас может и получилось бы что, но проблема отпала, так как у многих во внутрисети появился анлим и вопрос мирового трафика уже не стоит так остро.
Трекер жив благодаря его создателю Кравченко Ивану, за что ему респект и уважение :)
Это, кстати, трекер сети Киевского Политехнического Института — bete.tv
Стояла задача заменить PHPBTTracker на XBTT, последний отказывался кушать паскеи.
Проблема оказалась в SHA1 ф-ции, которую пришлось отключить.
Это так, не заточка, а просто нужно было обеспечить совместимость со старой базой.
Позже была идея добавить функционал, так как трекер у нас локальным был, нужно было добавить возможность отдавать список пиров в зависимости от айпи клиента (во внутрисеть — внутресетевые, во внешку — внешние). Вот тут то я и слил, долго думал куда бы приткнуть и так и не осилил по молодости. Сейчас может и получилось бы что, но проблема отпала, так как у многих во внутрисети появился анлим и вопрос мирового трафика уже не стоит так остро.
Трекер жив благодаря его создателю Кравченко Ивану, за что ему респект и уважение :)
Это, кстати, трекер сети Киевского Политехнического Института — bete.tv
Мне вот как-то тоже код не показался сложным, хотя я под плюсы и не писал толком никогда :) Тем не менее, модифицированный мною (некоторая кастом-функциональность) xbtt работает вот уже более полугода без рестарта… :) Я и проект-то бросил давно :)
НЛО прилетело и опубликовало эту надпись здесь
… и ни одного комментария в коде!
По второй части — накопления запросов — сами доходили до этого.
А по первой части — однопоточном приложении, обрабатывающем запросы без блокировки — очень интересно.
А по первой части — однопоточном приложении, обрабатывающем запросы без блокировки — очень интересно.
накопление угу, довольно банальная вещь. мы и в php в этом же проекте аналогично накапливаем часть счётчиков в APC и изредка сбрасываем в базу.
однопоточность в данном случае не идеал, просто так сложилось исторически, на мой взгляд всё-таки работу с базой стоило бы вынести в отдельный thread, но автор не хочет, мне тоже лень.
однопоточность в данном случае не идеал, просто так сложилось исторически, на мой взгляд всё-таки работу с базой стоило бы вынести в отдельный thread, но автор не хочет, мне тоже лень.
> однопоточность в данном случае не идеал
Если Вы о том, что обработка одного запроса может быть слишком долгой, то да, тяжёлые куски лучше выносить в отдельные потоки.
Но, во-первых, в таком варианте количество потоков может быть меньше количества соединений.
А во-вторых, обработка запросов может быть достаточно быстрой, чтобы обойтись одним потоком, и избежать жуткого геморроя с отладкой и дедлоками.
И вообще: блокироваться — это как-то неправильно в принципе +)
Если Вы о том, что обработка одного запроса может быть слишком долгой, то да, тяжёлые куски лучше выносить в отдельные потоки.
Но, во-первых, в таком варианте количество потоков может быть меньше количества соединений.
А во-вторых, обработка запросов может быть достаточно быстрой, чтобы обойтись одним потоком, и избежать жуткого геморроя с отладкой и дедлоками.
И вообще: блокироваться — это как-то неправильно в принципе +)
Это разве все в плане оптимизации? Имхо, это тока вершина айсберга
Этим людям хватило. А у вас синдром преждевременной эяк оптимизации.
Я имею ввиду оптимизацию системы. Всяко ведь не на стандартной конфигурации все работает.
система FreeBSD, настроена по мотивам www.opennet.ru/base/net/tune_freebsd.txt.html
но мне хотелось описать именно архитектуру приложения, с акцентом на обработку большими пачками как сетевого I/O так и работы с базой. в теме C10K акцент в основном на отдачу статики, а здесь приложение умудряется ещё и в MySQL всё тысячи запросов в секунду писать
но мне хотелось описать именно архитектуру приложения, с акцентом на обработку большими пачками как сетевого I/O так и работы с базой. в теме C10K акцент в основном на отдачу статики, а здесь приложение умудряется ещё и в MySQL всё тысячи запросов в секунду писать
опа, а еще отдельное спасибо за «ON DUPLICATE KEY UPDATE» =) не знал
По-первому — см. c10k в поисковиках
> и если для каждого создавать свой поток (thread) со своим стеком и постоянно переключаться между ними — ресурсов сервера очень быстро не хватит.
Не более чем точка зрения. Современные ОС могут держать без проблем даже миллионы тредов и выбор thread/poll не всегда столь очевиден, как вы описали.
> и если для каждого создавать свой поток (thread) со своим стеком и постоянно переключаться между ними — ресурсов сервера очень быстро не хватит.
Не более чем точка зрения. Современные ОС могут держать без проблем даже миллионы тредов и выбор thread/poll не всегда столь очевиден, как вы описали.
У вас точно такая же точка зрения :) Дело в том, что переключения контекста и стека — это всегда затратно. Тут надо искать золотую середину между количеством тредов и эффективностью работы всего алгоритма. Можно хоть 10 тыс тредов создать, по одному на соединение, но работать они будут едва ли не медленее, чем 100 тредов и ассинхронное IO.
я, разрабатывая сервер для большого количества постоянных соединений остановился на смешанной модели пул процессов (не тредов) + асинхронная работа с сокетами.
> У вас точно такая же точка зрения
Откуда вы узнали мою точку зрения? Я её не публиковал :)
Я не говорил, что poll или треды это панацея. Есть задачи, где «рулит» poll, а есть — где «рулят» треды. Есть и такие, где «рулит» золотая середина.
Просто могу посоветовать посмотреть на затраты переключения и размеры стека для треда, к примеру, в том же линуксе. В последнее время всё не столь печально, как раньше, треды стали достаточно легковестными в плане переключения задач.
Откуда вы узнали мою точку зрения? Я её не публиковал :)
Я не говорил, что poll или треды это панацея. Есть задачи, где «рулит» poll, а есть — где «рулят» треды. Есть и такие, где «рулит» золотая середина.
Просто могу посоветовать посмотреть на затраты переключения и размеры стека для треда, к примеру, в том же линуксе. В последнее время всё не столь печально, как раньше, треды стали достаточно легковестными в плане переключения задач.
> У вас точно такая же точка зрения
Откуда вы узнали мою точку зрения? Я её не публиковал :)
Я не говорил, что poll или треды это панацея. Есть задачи, где «рулит» poll, а есть — где «рулят» треды. Есть и такие, где «рулит» золотая середина.
Просто могу посоветовать посмотреть на затраты переключения и размеры стека для треда, к примеру, в том же линуксе. В последнее время всё не столь печально, как раньше, треды стали достаточно легковестными в плане переключения задач.
Откуда вы узнали мою точку зрения? Я её не публиковал :)
Я не говорил, что poll или треды это панацея. Есть задачи, где «рулит» poll, а есть — где «рулят» треды. Есть и такие, где «рулит» золотая середина.
Просто могу посоветовать посмотреть на затраты переключения и размеры стека для треда, к примеру, в том же линуксе. В последнее время всё не столь печально, как раньше, треды стали достаточно легковестными в плане переключения задач.
> У вас точно такая же точка зрения
Откуда вы узнали мою точку зрения? Я её не публиковал :)
Я не говорил, что poll или треды это панацея. Есть задачи, где «рулит» poll, а есть — где «рулят» треды. Есть и такие, где «рулит» золотая середина.
Просто могу посоветовать посмотреть на затраты переключения и размеры стека для треда, к примеру, в том же линуксе. В последнее время всё не столь печально, как раньше, треды стали достаточно легковестными в плане переключения задач.
Откуда вы узнали мою точку зрения? Я её не публиковал :)
Я не говорил, что poll или треды это панацея. Есть задачи, где «рулит» poll, а есть — где «рулят» треды. Есть и такие, где «рулит» золотая середина.
Просто могу посоветовать посмотреть на затраты переключения и размеры стека для треда, к примеру, в том же линуксе. В последнее время всё не столь печально, как раньше, треды стали достаточно легковестными в плане переключения задач.
> У вас точно такая же точка зрения
Откуда вы узнали мою точку зрения? Я её не публиковал :)
Я не говорил, что poll или треды это панацея. Есть задачи, где «рулит» poll, а есть — где «рулят» треды. Есть и такие, где «рулит» золотая середина.
Просто могу посоветовать посмотреть на затраты переключения и размеры стека для треда, к примеру, в том же линуксе. В последнее время всё не столь печально, как раньше, треды стали достаточно легковестными в плане переключения задач.
Откуда вы узнали мою точку зрения? Я её не публиковал :)
Я не говорил, что poll или треды это панацея. Есть задачи, где «рулит» poll, а есть — где «рулят» треды. Есть и такие, где «рулит» золотая середина.
Просто могу посоветовать посмотреть на затраты переключения и размеры стека для треда, к примеру, в том же линуксе. В последнее время всё не столь печально, как раньше, треды стали достаточно легковестными в плане переключения задач.
> У вас точно такая же точка зрения
Откуда вы узнали мою точку зрения? Я её не публиковал :)
Я не говорил, что poll или треды это панацея. Есть задачи, где «рулит» poll, а есть — где «рулят» треды. Есть и такие, где «рулит» золотая середина.
Просто могу посоветовать посмотреть на затраты переключения и размеры стека для треда, к примеру, в том же линуксе. В последнее время всё не столь печально, как раньше, треды стали достаточно легковестными в плане переключения задач.
Откуда вы узнали мою точку зрения? Я её не публиковал :)
Я не говорил, что poll или треды это панацея. Есть задачи, где «рулит» poll, а есть — где «рулят» треды. Есть и такие, где «рулит» золотая середина.
Просто могу посоветовать посмотреть на затраты переключения и размеры стека для треда, к примеру, в том же линуксе. В последнее время всё не столь печально, как раньше, треды стали достаточно легковестными в плане переключения задач.
Сори… имхо хабр должен бороться с дубляжом
НЛО прилетело и опубликовало эту надпись здесь
www.kegel.com/c10k.html#threaded конкретно NPTL есть ссылка про «10^6 threads»
Спасибо за информацию. Сейчас как раз занимаемся переносом трекера с php на xbtt.
А можно пояснить про актеров в Erlang-е? Что-то я там ни чего подобного не припомню…
Странно, что никто не упомянул такой недостаток описанной модели, как использование только одного ядра процессора. С некоторой натяжкой можно признать что второе ядро загрузит MySQL. Но если ядер больше двух, то модель с неблокирующим I/O в одном процессе начинает проигрывать модели с несколькими такими процессами.
Кроме того, помимо производительности есть фактор простоты кода (т.е. поддерживаемости приложения). Я тоже много лет занимаюсь неблокирующим I/O, epoll, etc. и могу искренне заявить, что этот код никогда не будет таким же простым как код блокирующего I/O в нитях.
Если для разработки таких серверов использовать языки/системы с очень лёгкими нитями (вроде Inferno), то производительность нитей с блокирующим I/O будет сравнима с производительностью epoll (сам проверял :)). При этом код будет значительно проще, плюс сервер будет автоматически масштабироваться при использовании многоядерных CPU (а в ближайшее время кол-во ядер скорее всего очень сильно увеличится).
Кроме того, помимо производительности есть фактор простоты кода (т.е. поддерживаемости приложения). Я тоже много лет занимаюсь неблокирующим I/O, epoll, etc. и могу искренне заявить, что этот код никогда не будет таким же простым как код блокирующего I/O в нитях.
Если для разработки таких серверов использовать языки/системы с очень лёгкими нитями (вроде Inferno), то производительность нитей с блокирующим I/O будет сравнима с производительностью epoll (сам проверял :)). При этом код будет значительно проще, плюс сервер будет автоматически масштабироваться при использовании многоядерных CPU (а в ближайшее время кол-во ядер скорее всего очень сильно увеличится).
похожую схему я использовал на tradebox
ну и др проектах
правда это к трекеру не относится,
ну и др проектах
правда это к трекеру не относится,
Для больших вставок в базу данных я использую механизм load data in file. Непревзойденная скорость вставки. Майскуэль парсит только один запрос, полезные данные в файле почти все, и дополнительных только разделители. Легко справляется с тысячами, десятками и сотнями тысяч строк в секунду. Если структуры таблиц не повзоляют такого делать, то можно делать отдельную таблицу для вставки и из нее делать необходимые инсерты-апдейты по другим таблицам. Эту временную таблицу так же можно создавать в памяти.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обслуживание тысяч запросов в секунду на примере XBT Tracker