У документації UBD понад 200 параметрів конфігурації. Експерименти на тест-стенді Xeon Gold 6248R 24c×2 / 192GB / NVMe показали: 7 з них дають близько 80% усього виграшу продуктивності. Інші 193 — корисні в окремих випадках, але для більшості систем їх дефолтні значення оптимальні. Стаття описує саме ці 7 з конкретними значеннями і мікро-бенчмарками.
Тест-стенд і методологія
Усі цифри нижче — з референсного стенду: 2× Intel Xeon Gold 6248R (24 ядра кожен, 48 потоків загалом), 192 GB RAM, локальний NVMe (Samsung PM1733), 10 Gbit мережа, MS SQL Server 2019. Базовий сценарій навантаження: 5000 одночасних користувачів, mixed workload (70% читання / 30% запис) з повною авторизацією на кожний запит.
Базова продуктивність на дефолтних налаштуваннях: близько 6000 прикладних операцій на хвилину. Мета tuning — досягти 20 000 операцій на хвилину без зміни заліза.
Параметр 1: Connection pool size
Default: 50 з'єднань. Оптимально для стенду: 200-300.
Розмір пулу з'єднань між UBD-сервером і СУБД. Замалий пул — запити чекають у черзі. Завеликий — overhead на context switching і навантаження на СУБД.
Формула першого наближення: (кількість логічних ядер × 2) + кількість дискових шпинделів. Для NVMe «шпинделі» рахуються як 4-8.
| Pool size | операцій/хв | p99 latency |
|---|---|---|
| 50 (default) | 6 200 | 180 мс |
| 100 | 9 800 | 120 мс |
| 200 | 14 500 | 80 мс |
| 300 | 15 100 | 75 мс |
| 500 | 14 200 | 110 мс (overhead) |
Параметр 2: Query cache
Default: вимкнено. Оптимально: увімкнено, 2-4 GB.
Кеш результатів повторюваних запитів. Особливо ефективний для довідників (списки країн, статусів, ролей) і метаданих моделі — їх читають десятки тисяч разів на хвилину, а змінюються рідко.
Важливо: для змінюваних даних кеш має invalidation-логіку — записи в таблиці автоматично інвалідують відповідні запити. Для рідко-змінюваних даних — TTL (наприклад, 5 хвилин).
Виграш: +30% пропускної здатності на типовому workload, +60% на read-heavy.
Параметр 3: AuthZ policy compilation cache
Default: 100 політик. Оптимально: 5000-10000.
UBD виконує авторизацію на кожний запит через policy engine. Політики (особливо ABAC) обчислюються — це не дешева операція. Компільовані політики кешуються; повторне обчислення для тієї ж комбінації (роль × ресурс × контекст) береться з кешу.
На read-heavy workload з повторюваними патернами доступу цей кеш дає найбільший ефект — від нього один залежить ~25% всього tuning gain.
| Cache size | Hit rate | операцій/хв |
|---|---|---|
| 100 (default) | 34% | 9 800 |
| 1 000 | 78% | 13 200 |
| 5 000 | 94% | 16 800 |
| 10 000 | 97% | 17 300 |
| 50 000 | 98% | 17 100 (RAM overhead) |
Параметр 4: Transaction batch size
Default: 1 (кожна операція — окрема транзакція). Оптимально для масових операцій: 100-500.
При імпорті даних, масових оновленнях, генерації звітів — кожна окрема транзакція має overhead (BEGIN, COMMIT, журналювання). Об'єднання у батчі скорочує overhead у 50-100 разів.
Обмеження: великі батчі (>1000) утримують locks довше, блокуючи інших користувачів. Для онлайн-операцій (інтерактивна робота) batch size = 1 правильний; для офлайн-операцій — 100-500.
Параметр 5: File storage strategy
Default: файли у БД (BLOB). Оптимально: файли на файловій системі / S3, посилання у БД.
BLOB-и у БД — найпростіший варіант, але вбиває продуктивність при великих обсягах: BLOB-и потрапляють у backup, реплікацію, кеш СУБД. Файлове сховище окремо — швидше і дешевше.
Для UBD: налаштувати file storage path або S3-сумісне сховище (MinIO, AWS S3, Wasabi). У БД — тільки метадані файлу (ім'я, розмір, хеш, посилання). Це окремо корисно для регуляторики: WORM-сховище для документів реалізується на рівні файлового сховища.
Виграш на типовому документообігу: +40% пропускної здатності, -60% розмір БД.
Параметр 6: Log buffer size
Default: 4 MB. Оптимально: 64-256 MB для активних систем.
WORM-журнал подій пишеться у буфер у пам'яті, потім періодично flush на диск. Замалий буфер — частий flush, що блокує запис. Завеликий — ризик втрати останніх подій при аварійному падінні (хоча для WORM це менш критично, ніж для звичайних логів — журнал реплікується).
Для систем з активним аудитом (5000+ подій на хвилину) — 128 MB. flush кожні 1-5 секунд або при заповненні буфера.
Параметр 7: GC profile
Default: general-purpose. Оптимально: low-latency (G1GC або ZGC).
Stop-the-world паузи garbage collector — джерело p99-latency спайків. На default GC паузи можуть бути 200-500 мс при великій heap (>16 GB), що видно користувачам як «лаги».
G1GC з налаштуванням -XX:MaxGCPauseMillis=50 — стандартний компроміс. ZGC (Java 17+) — для систем з heap >32 GB, дає sub-10ms паузи навіть на 100+ GB heap.
Підсумкова таблиця
| Параметр | Виграш пропускної здатності | Виграш p99 |
|---|---|---|
| Connection pool 50→200 | +135% | -55% |
| Query cache off→on | +30% | -25% |
| AuthZ cache 100→5000 | +72% | -30% |
| Batch size для масових операцій | +10× (тільки batch) | — |
| BLOB→file storage | +40% | -30% |
| Log buffer 4MB→128MB | +8% | -15% |
| GC general→G1 | +5% | -70% (p99) |
| Кумулятивно | ~3.2× (6k→20k операцій/хв) | ~5× |
Послідовність впровадження
- Виміряти baseline на проді (без змін).
- Connection pool — швидка зміна, велика користь, низький ризик.
- AuthZ cache — швидка зміна, велика користь, низький ризик.
- GC profile — потребує рестарту, але швидко відкочується.
- Query cache — потребує тестування invalidation для специфічних таблиць.
- Log buffer — низький пріоритет, малий виграш для більшості систем.
- File storage strategy — найбільша зміна, окремий проєкт міграції.
Чого НЕ варто tuning'увати без потреби
- Розмір thread pool — UBD сам адаптується.
- TCP-параметри ядра — лише для систем з 50k+ одночасних з'єднань.
- JVM heap size — більше = краще тільки до певної межі; за 64 GB GC пауз більше, ніж виграшу.
- Кількість worker-процесів — оптимум = ядра × 1.5, дефолт зазвичай добрий.
На тест-стенді 2×Xeon Gold 6248R / 192GB / NVMe з усіма 7 параметрами на оптимумі UBD досягає 20 000 прикладних операцій на хвилину з повною авторизацією. Бенчмарки і конфігураційні файли надаються партнерам за запитом. Це не маркетингова цифра — це повторюваний результат на ідентичному залізі.
UnityBaseDefense — технічна довідка →