Ну это по сути и есть паблик пентест, там даже отводящее слово «beta» есть :-)
причем пентест не только днс, но и того же zf2 — к которому, несмотря на его использование, мы относимся очень скептически.
p.s. уже реализована запись статистики запросов, но пока это просто бинарная структура в памяти, постараемся все таки вывести ее в виде графиков на морду в ближайшее время
вопрос к знатокам: что бы вы выбрали для хранения аггрегированной статистики — rrd (минимально по месту) или mongo (максимально удобно)?
Немного подробностей конечно же можно. Это были синтетические замеры на отдачу А записей без участия сетевого стека, то есть при условии включения сюда работы драйвера сетевой — qps уже значительно падает. Но — смотря какой сетевой карты, продукт писался не как user-space именно по причине работы на кластере в среде infiniband — и пришлось немного подпиливать rdma
В случае дополнительных вычислений вроде проверки acl при отдаче AXFR запроса результаты тоже значительно падают (два чтения из памяти) — до 2.5-3 раз. Даже была мысль в реализации «сложных» запросов (AXFR, рекурсивных, DNSSEC с проверкой подписи) в отдельном модуле, но не сложилось — поэтому просто не реализовывали рекурсию и сделали только костыльный AXFR смирившись с необходимостью.
По поводу производительности — она растет нелинейно, в первую очередь это связано с тем что при увеличении количества процессоров/ядер увеличивается нагрузка на ht/qpi на не-numa системах (а их большинство к сожалению в нашем парке), в случае numa доступа к памяти — падение уже не такое значительное. Это касается только синтетических тестов. 3М запросов — 1.4 гбита — это совершенно небольшая цифра, непонятно чем она так удивляет. Для того чтобы была небольшая ясность — opteron 250 прогоняет «по даташиту» до 6 ГБ/с — на практике эта цифра на двухпроцессорной системе падает до 3 ГБ/с на чтение и 1.6 ГБ/с на запись, при лейтенси доступа к «своей» памяти около 40 нс и к «чужой» порядка 70 нс (разницы по скорости своя/чужая нету, только по времени доступа).
Когда мы спускаемся уже на уровень медиасреды — вот тут пожалуй самая большая загвоздка в производительности, и пока что бороться приходится именно с ней — тут уже вступают в силу другие факторы, как то: старенькие 6500 каталисты можно завалить 3.6 mpps мелкими пакетами — она просто умирает, при этом это даже не 100 мбит траффика.
fix: когда все ответы попадают в кеш процессора думаю что можно достичь максимума по тактам — но мне кажется что это фантастика ))
касаемо memcached — мы его выбрали как быстрый костыль вместо read+write модулей ядра под rdma, потому что своей инфраструктуры аналогичной заказчику — у нас просто нету, и надо было заюзать «что-то» под tcp стек, и для фришного сервиса решили — почему нет, мы все равно упираемся в сеть в результате
вобщем нету погони за «циферками», да и сервера на которых размещен сервис сейчас виртуальные (что добавляет очень неслабо к лейтенси). Цель паблик проекта — получить живой стресстест, ну и ловить баги потихоньку. Но будем рады тестам (особенно например скорости репликации — на данный момент по идее она лучше чем у всех паблик сервисов, ну может кроме гугла — не знаем как его замерить :-)
причем пентест не только днс, но и того же zf2 — к которому, несмотря на его использование, мы относимся очень скептически.
решали локальную проблему, по дороге решили сделать маленькую экосистему, вроде получилось — и в таком духе и думаем продолжать развивать
в данном случае производительность — это наша экономия на инфраструктуре для сервиса, что конкурентное преимущество перед аналогами :-)
вопрос к знатокам: что бы вы выбрали для хранения аггрегированной статистики — rrd (минимально по месту) или mongo (максимально удобно)?
В случае дополнительных вычислений вроде проверки acl при отдаче AXFR запроса результаты тоже значительно падают (два чтения из памяти) — до 2.5-3 раз. Даже была мысль в реализации «сложных» запросов (AXFR, рекурсивных, DNSSEC с проверкой подписи) в отдельном модуле, но не сложилось — поэтому просто не реализовывали рекурсию и сделали только костыльный AXFR смирившись с необходимостью.
По поводу производительности — она растет нелинейно, в первую очередь это связано с тем что при увеличении количества процессоров/ядер увеличивается нагрузка на ht/qpi на не-numa системах (а их большинство к сожалению в нашем парке), в случае numa доступа к памяти — падение уже не такое значительное. Это касается только синтетических тестов. 3М запросов — 1.4 гбита — это совершенно небольшая цифра, непонятно чем она так удивляет. Для того чтобы была небольшая ясность — opteron 250 прогоняет «по даташиту» до 6 ГБ/с — на практике эта цифра на двухпроцессорной системе падает до 3 ГБ/с на чтение и 1.6 ГБ/с на запись, при лейтенси доступа к «своей» памяти около 40 нс и к «чужой» порядка 70 нс (разницы по скорости своя/чужая нету, только по времени доступа).
Когда мы спускаемся уже на уровень медиасреды — вот тут пожалуй самая большая загвоздка в производительности, и пока что бороться приходится именно с ней — тут уже вступают в силу другие факторы, как то: старенькие 6500 каталисты можно завалить 3.6 mpps мелкими пакетами — она просто умирает, при этом это даже не 100 мбит траффика.
fix: когда все ответы попадают в кеш процессора думаю что можно достичь максимума по тактам — но мне кажется что это фантастика ))
касаемо memcached — мы его выбрали как быстрый костыль вместо read+write модулей ядра под rdma, потому что своей инфраструктуры аналогичной заказчику — у нас просто нету, и надо было заюзать «что-то» под tcp стек, и для фришного сервиса решили — почему нет, мы все равно упираемся в сеть в результате
вобщем нету погони за «циферками», да и сервера на которых размещен сервис сейчас виртуальные (что добавляет очень неслабо к лейтенси). Цель паблик проекта — получить живой стресстест, ну и ловить баги потихоньку. Но будем рады тестам (особенно например скорости репликации — на данный момент по идее она лучше чем у всех паблик сервисов, ну может кроме гугла — не знаем как его замерить :-)