Дежурен сте за уеб услуга: балансьор на натоварването пред парк от инстанции, кеш пред база данни и цел за наличност от 99,9 %. Всяка минута моделът изчислява закъснението в опашката, тайм-аутите, попаденията в кеша и натоварването на базата по учебникарски формули — и колко струват решенията ви.
Долна граница на парка. Повишаването пуска инстанции веднага — те все пак се нуждаят от закъснението на зареждане, преди да обслужват.
Следене на целта по използване; няма ново разширяване, докато инстанциите още се зареждат. Изкл. = точно минимумът.
По-ниско = повече запас и повече разход. Измереното използване не може да надхвърли 100 %, затова наситеният парк расте само стъпка по стъпка.
По-дълъг TTL = повече попадения, но отговорите може да са по-стари (средна възраст ≈ TTL/2).
Зарежда горещи ключове за 6 минути (+12 % от кеша на минута) срещу 600 допълнителни заявки към базата/s.
Дял от нископриоритетните 30 % (prefetch, пакетен, краулери), отхвърлен на балансьора на натоварването със „опитайте по-късно“.
Тежката функция добавя 20 ms CPU и една заявка към базата на всяка заявка. Изкл. = плавна деградация.
Внедрява отново последния добър билд на свеж парк (5 мин, таксува се двойно), след което превключва трафика. Повторно натискане рестартира подготовката; ако няма пуснат лош билд, струва само пари.
| Скорост на изгаряне (1 h) | 0,0 × |
|---|---|
| Заявки | 1125 req/s |
| Инстанции, които обслужват | 10 |
| Инстанции в зареждане | 0 |
| Дял на попаденията в кеша | 77 % |
| Използване на базата данни | 19 % |
| Отхвърлен трафик | 0 % |
| Разход на парка | 4,00 $/h |
| Разход досега | 0,00 $ |
| Средна възраст на кешираните отговори | 30 s |
| Трафик на лошия билд | 0 % |
| Препоръките са налични | 100 % |
Нов билд излиза в 09:10. Месецът вече беше труден: остава само 20 % от бюджета за грешки. Минути след внедряването се задейства сигналът за скорост на изгаряне. Пазете бюджета.
Връзка към услугата се разпространява бързо и се очаква пик на трафика някъде тази сутрин — никой не знае кога, нито колко голям. Новите инстанции днес се нуждаят от 8 минути, за да стартират. Когато дойде, поддържайте грешките и забавянето ниски, без да харчите пари за неизползван капацитет.
На обедния пик скрипт за поддръжка изчиства целия кеш. Всяка заявка вече отива към базата, оразмерена за обичайния дял на попадения от 85 %. Върнете услугата, без да претоварите базата.
Всяка зависимост, която симулаторът използва, с нейния източник. Константите, отбелязани като допускания, са илюстративни калибрации.
λ(t) = base × (1 + 0.25·sin(2π(t + clock − 6 h)/24 h)) × surge(t), clock = time of day at the start (peak at 12:00); count/min ≈ N(60λ, √(60λ)) × (1 + N(0, 0.02))[6]Допускане: броят на работниците, времената на обслужване, капацитетът на базата, размерът на кеша, скоростта на пълнене, цените и честотата на грешки на лошия билд са илюстративни стойности за уеб услуга със среден размер.N = instances × 16 workers, a = λ·S; C(a, N) = B / (1 − (a/N)(1 − B)), B = Erlang B[3][6]P(W > t) = C·e^(−(N/S − λ)·t); timeouts = P(W > 2 s); a ≥ N ⇒ failed share = 1 − N/a[3]p99 ≈ S·ln 100 + ln(C/0.01)/(N/S − λ) (service + waiting quantile, an approximation)[3][6]Приближение: сборът от квантилите на обслужването и чакането не е точният p99 на сбора им (може да е малко по-висок или по-нисък); опашката се третира като стабилна в рамките на всяка минута, защото заявките отнемат милисекунди.busy workers L = λ·S ⇒ utilization = λ·S / N[4]hit = warm × rT/(1 + rT), r = λ / 20,000 objects; mean age of a cached answer ≈ T/2[5]DB load = λ·q·(1 − hit); query time = 5 ms/(1 − ρ_db) (≤ 250 ms); S = S_app + (1 − hit)·q·query time[6]Допускане: броят на работниците, времената на обслужване, капацитетът на базата, размерът на кеша, скоростта на пълнене, цените и честотата на грешки на лошия билд са илюстративни стойности за уеб услуга със среден размер.budget = 1 − SLO = 0.1 %; burn = error rate / 0.1 %; Δbudget per min = burn / 43,200; burn (1 h) = mean error rate over the last 60 min / 0.1 % (window pre-filled with the opening minute)[1][2]desired = ⌈serving × utilization / target⌉ (utilization saturates at 100 %); new instances serve after the boot delay[6]Допускане: броят на работниците, времената на обслужване, капацитетът на базата, размерът на кеша, скоростта на пълнене, цените и честотата на грешки на лошия билд са илюстративни стойности за уеб услуга със среден размер.16 workers/instance · app time 50 ms (+20 ms and +1 query with the feature on) · 2 queries/request · DB 4,000 queries/s · 20,000 hot objects · cache refill τ = 30 min (slower while the DB is saturated) · warm-up job +12 %/min for 6 min, +600 queries/s · timeout 2 s · 30 % low-priority traffic · bad build +5 % errors, ×1.25 CPU · rollback 5 min · $0.40 per instance-hour · scale-in by ≤ 20 % of the fleet after 10 quiet minutes · up to 40 instancesДопускане: броят на работниците, времената на обслужване, капацитетът на базата, размерът на кеша, скоростта на пълнене, цените и честотата на грешки на лошия билд са илюстративни стойности за уеб услуга със среден размер.Случайност: генератор mulberry32 със seed; използвани разпределения — равномерно, експоненциално (обратна CDF), нормално (Box–Muller), на Поасон (Knuth). Seed се показва и може да се споделя.
Образователен модел — не за оперативни решения. Реалните обекти калибрират всяка константа към собственото си оборудване и данни.