madf: (Default)
[personal profile] madf
Машина, на якій тестував: AMD Duron 1400 MHz, 512 Mb
Тестував на пропускну задтність, бо зараз Stargazer лажає в моменти запису статистики - через блокування пропускає пакети.
Для тесту генерував правила (rules) і пакети. Трафік генерували 3 "юзера". від кожного було по 512 * 512 рандомних пакетів в обидва боки (upload/download). Всього 512 * 512 * 2 * 3 = 1572864 пакети.
Далі буде багато літер, цифр, і жодного графіка або картинки.

1 тест - на "голих" правилах (всього 3 правила):

  • пакети приготовано за 656461 мікросекунд (пів секунди);

  • пакети прийнято за 38692826 мікросекунд (38.7 секунди);

  • якщо пакети "пусті" (по 0 байт - лише заголовки) маємо (160 + 64) * 1572864 = 352321536 байт (336 Мб);

  • пропускна здатність: 8.7 Мб/с або 69.5 Мбіт/с;

  • максимальна кількість пакетів у вхідному буфері: 1.


Зауважу, що у реальності це дуже специфічний трафік - його можна створити лише спеціально. Якщо канал буде "ширше" - система просто почне їсти пам'ять, буферизуючи трафік для обробки.

2 тест - намагався ускладнити життя системі (4096 правил - приблизно як для UA-IX):

  • пакети приготовано за 673587 мікросекунд (ті ж пів секунди);

  • пакети прийнято за 37972600 мікросекунд (38 секунд);

  • ті-ж самі 336 Мб на "пустих" пакетах;

  • пропускна здатність: 8.8 Мб/с або 70.7 Мбіт/с;

  • максимальна кількість пакетів у вхідному буфері: 1.


Відпрацювала трошки швидше, але спишемо це на інструментальну похибку (згадав лаби по Твердоступу - він би мене вигнав з аудиторії за таке :).

3 тест - виріши вбити систему (4096000 правил - такого просто небуває):

  • пакети приготовано за 647688 мікросекунд (ті ж пів секунди);

  • пакети прийнято за 37744982 мікросекунд (37.7 секунди);

  • ті-ж 336 Мб "пустих" пакетів;

  • пропускна здатність 8.9 Мб/с або 71.3 Мбіт/с;

  • максимальна кількість пакетів у вхідному буфері: 5341.


Ооо! Нарешті! Тепер йому стало вже не так просто обробляти трафік, але він справився за той-же час.
А тепер трішки про те, що це все означає.

Трафік в середині трафкаунтера групується за "сесіями". "Сесія" - це обмін даними в одному напрямі між двома хостами через 2 порти по одному протоколу. коли пакет потрапляє до трафкаунтера для нього шукається підходяща сесія. Якщо такої не знайдено - він створює нову сесію. Створення сесії - ресурсоємна операція, бо включає в себе класифікацію трафіку за напрямом (правила rules). Найкращий варіант для обліку - мала кількість сесій з великим об'ємом даних. Я спеціально генерував пакети з випадковими адресами щоб створити найгіршу ситуацію: велика кількість сесій з 1-2 пакетами на сесію. Майже кожен пакет потрапляв на класифікацію.

Прийом і обробка пакетів працюють максимально незалежно. Коли обробка заблочена запитом на отримання трафіку - пакети продовжують прийматись у вхідний буфер (максимальна кількість пакетів у вхідному буфері). Сьогодні у тестах я не перевіряв цю ситуацію - лише "ускладнював життя" великою кількістю правил обліку. Крім того є ще один параметр: кількість IP адрес що зареєстровано на облік у трафкаунтері - цей параметр впливає і на прийом пакетів. Сьогодні їх було лише 3. Типове навантаження на сервер для поточної версії Stargazer - 4000 користувачів.
Я планую разом із 2.407 випустити тестову версію 2.5 - перевірити у "бойових" умовах.

Profile

madf: (Default)
madf

April 2018

S M T W T F S
1234567
891011121314
15161718192021
22232425262728
2930     

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 7th, 2026 05:44 am
Powered by Dreamwidth Studios