"Вкусняшки" про новий TRAFFCOUNTER
Mar. 27th, 2009 06:45 pmМашина, на якій тестував: AMD Duron 1400 MHz, 512 Mb
Тестував на пропускну задтність, бо зараз Stargazer лажає в моменти запису статистики - через блокування пропускає пакети.
Для тесту генерував правила (rules) і пакети. Трафік генерували 3 "юзера". від кожного було по 512 * 512 рандомних пакетів в обидва боки (upload/download). Всього 512 * 512 * 2 * 3 = 1572864 пакети.
Далі буде багато літер, цифр, і жодного графіка або картинки.
1 тест - на "голих" правилах (всього 3 правила):
Зауважу, що у реальності це дуже специфічний трафік - його можна створити лише спеціально. Якщо канал буде "ширше" - система просто почне їсти пам'ять, буферизуючи трафік для обробки.
2 тест - намагався ускладнити життя системі (4096 правил - приблизно як для UA-IX):
Відпрацювала трошки швидше, але спишемо це на інструментальну похибку (згадав лаби по Твердоступу - він би мене вигнав з аудиторії за таке :).
3 тест - виріши вбити систему (4096000 правил - такого просто небуває):
Ооо! Нарешті! Тепер йому стало вже не так просто обробляти трафік, але він справився за той-же час.
А тепер трішки про те, що це все означає.
Трафік в середині трафкаунтера групується за "сесіями". "Сесія" - це обмін даними в одному напрямі між двома хостами через 2 порти по одному протоколу. коли пакет потрапляє до трафкаунтера для нього шукається підходяща сесія. Якщо такої не знайдено - він створює нову сесію. Створення сесії - ресурсоємна операція, бо включає в себе класифікацію трафіку за напрямом (правила rules). Найкращий варіант для обліку - мала кількість сесій з великим об'ємом даних. Я спеціально генерував пакети з випадковими адресами щоб створити найгіршу ситуацію: велика кількість сесій з 1-2 пакетами на сесію. Майже кожен пакет потрапляв на класифікацію.
Прийом і обробка пакетів працюють максимально незалежно. Коли обробка заблочена запитом на отримання трафіку - пакети продовжують прийматись у вхідний буфер (максимальна кількість пакетів у вхідному буфері). Сьогодні у тестах я не перевіряв цю ситуацію - лише "ускладнював життя" великою кількістю правил обліку. Крім того є ще один параметр: кількість IP адрес що зареєстровано на облік у трафкаунтері - цей параметр впливає і на прийом пакетів. Сьогодні їх було лише 3. Типове навантаження на сервер для поточної версії Stargazer - 4000 користувачів.
Я планую разом із 2.407 випустити тестову версію 2.5 - перевірити у "бойових" умовах.
Тестував на пропускну задтність, бо зараз 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 - перевірити у "бойових" умовах.