Ju jeni në detyrë për një shërbim ueb: një balancues ngarkese përpara një flote instancash, një cache përpara një baze të dhënash, dhe një objektiv disponueshmërie 99,9 %. Çdo minutë modeli llogarit vonesën e radhës, afatet e skaduara, goditjet e cache dhe ngarkesën e bazës së të dhënave nga formula teksti — dhe sa kushtojnë vendimet tuaja.
Dyshemeja e flotës. Rritja e saj nis instanca menjëherë — ato kanë ende nevojë për vonesën e ndezjes para se të shërbejnë.
Ndjekje e objektivit sipas shfrytëzimit; nuk ka shkallëzim të ri përderisa instancat ende ndizen. Fikur = saktësisht minimumi.
Më i ulët = më shumë rezervë dhe më shumë kosto. Shfrytëzimi i matur nuk mund të kalojë 100 %, kështu që një flotë e ngopur rritet vetëm hap pas hapi.
TTL më i gjatë = më shumë goditje, por përgjigjet mund të jenë më të vjetra (mosha mesatare ≈ TTL/2).
Ngarkon çelësat e nxehtë për 6 minuta (+12 % e cache në minutë) me çmimin e 600 pyetjeve shtesë në bazën e të dhënave/s.
Pjesa e 30 %-it me përparësi të ulët (prefetch, batch, crawlers) që refuzohet në balancuesin e ngarkesës me “provo më vonë”.
Veçoria e rëndë shton 20 ms CPU dhe një pyetje në bazën e të dhënave për kërkesë. Fikur = degradim i butë.
Rivendos ndërtimin e fundit të mirë në një flotë të re (5 min, e faturuar dy herë), pastaj kalon trafikun. Shtypja përsëri e fillon përgatitjen nga e para; nëse nuk ka ndërtim të keq në punë, kushton vetëm para.
| Shkalla e djegies (1 h) | 0,0 × |
|---|---|
| Kërkesa | 1125 req/s |
| Instanca që shërbejnë | 10 |
| Instanca që po ndizen | 0 |
| Shkalla e goditjeve të cache | 77 % |
| Shfrytëzimi i bazës së të dhënave | 19 % |
| Trafik i hequr | 0 % |
| Kostoja e flotës | 4,00 $/h |
| Kostoja deri tani | 0,00 $ |
| Mosha mesatare e përgjigjeve në cache | 30 s |
| Trafiku në ndërtimin e keq | 0 % |
| Rekomandime të disponueshme | 100 % |
Një ndërtim i ri del në 09:10. Muaji ka qenë tashmë i vështirë: ka mbetur vetëm 20 % e buxhetit të gabimeve. Minuta pas vendosjes bie alarmi i shkallës së djegies. Mbro buxhetin.
Një lidhje drejt shërbimit po përhapet shpejt dhe pritet një shpërthim trafiku diku këtë mëngjes — askush nuk e di kur, apo sa i madh. Instancat e reja kanë nevojë për 8 minuta për t'u nisur sot. Kur të vijë, mbaji gabimet dhe vonesën të ulëta pa djegur para për kapacitet të papunë.
Në pikun e mesditës një skenar mirëmbajtjeje e shpëlan gjithë cache-n. Çdo kërkesë tani shkon te baza e të dhënave, e dimensionuar për shkallën e zakonshme të goditjeve 85 %. Ktheje shërbimin pa mbingarkuar bazën e të dhënave.
Çdo marrëdhënie që përdor simulatori, me burimin e saj. Konstantet e shënuara si supozime janë kalibrime ilustruese.
λ(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]Supozim: numri i punëtorëve, kohët e shërbimit, kapaciteti i bazës së të dhënave, madhësia e cache, shpejtësia e mbushjes, çmimet dhe shkalla e gabimeve e ndërtimit të keq janë vlera ilustruese për një shërbim ueb të mesëm.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]Përafrim: mbledhja e kuantileve të shërbimit dhe pritjes nuk është p99 i saktë i shumës së tyre (mund të dalë pak i lartë ose i ulët); radha trajtohet si e qëndrueshme brenda çdo minute sepse kërkesat zgjasin milisekonda.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]Supozim: numri i punëtorëve, kohët e shërbimit, kapaciteti i bazës së të dhënave, madhësia e cache, shpejtësia e mbushjes, çmimet dhe shkalla e gabimeve e ndërtimit të keq janë vlera ilustruese për një shërbim ueb të mesëm.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]Supozim: numri i punëtorëve, kohët e shërbimit, kapaciteti i bazës së të dhënave, madhësia e cache, shpejtësia e mbushjes, çmimet dhe shkalla e gabimeve e ndërtimit të keq janë vlera ilustruese për një shërbim ueb të mesëm.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 instancesSupozim: numri i punëtorëve, kohët e shërbimit, kapaciteti i bazës së të dhënave, madhësia e cache, shpejtësia e mbushjes, çmimet dhe shkalla e gabimeve e ndërtimit të keq janë vlera ilustruese për një shërbim ueb të mesëm.Rastësia: një gjenerator mulberry32 me farë; shpërndarjet e përdorura — uniforme, eksponenciale (CDF e anasjellë), normale (Box–Muller), Poisson (Knuth). Fara shfaqet dhe mund të ndahet.
Model edukativ — jo për vendime operacionale. Vendet reale i kalibrojnë të gjitha konstantet sipas pajisjeve dhe të dhënave të tyre.