អ្នកត្រៀមលក្ខណៈសម្រាប់សេវាវេប៖ load balancer នៅមុខចម្រៀក instance, cache នៅមុខមូលដ្ឋានទិន្នន័យ និងគោលដៅភាពអាចរកបាន 99.9 %។ រាល់នាទី ម៉ូដែលគណនាការពន្យាពេលជួរ timeout cache hit និងបន្ទុកមូលដ្ឋានទិន្នន័យពីរូបមន្តសៀវភៅសិក្សា — និងអ្វីដែលការសម្រេចចិត្តរបស់អ្នកចំណាយ។
ជាន់ក្រោមសម្រាប់ចម្រៀក។ ការលើកវាចាប់ផ្ដើម instance ភ្លាមៗ — ពួកគេនៅតែត្រូវការការពន្យាពេលចាប់ផ្ដើមមុនបម្រើ។
ការតាមដានគោលដៅលើការប្រើប្រាស់។ គ្មានការពង្រីកថ្មីពេល instance នៅកំពុងចាប់ផ្ដើម។ បិទ = អប្បបរមាពិតប្រាកដ។
ទាបជាង = ទំហំបម្រុងច្រើនជាង និងថ្លៃជាង។ ការប្រើប្រាស់ដែលវាស់មិនអាចលើស 100 % ដូច្នេះចម្រៀកឆ្អែតលូតលាស់តែម្ដងមួយជំហាន។
TTL វែងជាង = hit ច្រើនជាង ប៉ុន្តែចម្លើយអាចចាស់ជាង (អាយុមធ្យម ≈ TTL/2)។
ផ្ទុកគ្រាប់ចុចក្ដៅ 6 នាទី (+12 % នៃ cache ក្នុងមួយនាទី) ក្នុងតម្លៃសំណួរមូលដ្ឋានទិន្នន័យបន្ថែម 600/s។
ចំណែកនៃ 30 % អាទិភាពទាប (prefetch batch crawler) ដែលបដិសេធនៅ load balancer ជាមួយ «សាកល្បងម្ដងទៀតពេលក្រោយ»។
លក្ខណៈពិសេសធ្ងន់បន្ថែម CPU 20 ms និងសំណួរមូលដ្ឋានទិន្នន័យមួយក្នុងមួយសំណើ។ បិទ = ការថយចុះដោយទន់ភ្លន់។
ដាក់ពង្រាយឡើងវិញនូវ build ល្អចុងក្រោយនៅលើក្រុមម៉ាស៊ីនថ្មី (5 នាទី គិតថ្លៃពីរដង) បន្ទាប់មកប្ដូរចរាចរណ៍។ ការចុចម្ដងទៀតចាប់ផ្ដើមការរៀបចំឡើងវិញ។ បើគ្មាន build អាក្រក់កំពុងដំណើរការ វាខាតតែលុយប៉ុណ្ណោះ។
| អត្រាដុត (1 ម៉ោង) | 0.0 × |
|---|---|
| សំណើ | 1125 req/s |
| instance កំពុងបម្រើ | 10 |
| instance កំពុងចាប់ផ្ដើម | 0 |
| អត្រា cache hit | 77 % |
| ការប្រើប្រាស់មូលដ្ឋានទិន្នន័យ | 19 % |
| ចរាចរណ៍ដែលបានកាត់បន្ថយ | 0 % |
| ថ្លៃចម្រៀក | 4.00 $/h |
| ថ្លៃរហូតមកដល់ពេលនេះ | 0.00 $ |
| អាយុមធ្យមនៃចម្លើយក្នុង cache | 30 s |
| ចរាចរណ៍លើ build អាក្រក់ | 0 % |
| ការណែនាំអាចរកបាន | 100 % |
build ថ្មីចេញនៅ 09:10។ ខែនេះលំបាករួចហើយ៖ នៅសល់តែ 20 % នៃថវិកាកំហុស។ ប៉ុន្មាននាទីក្រោយការ deploy ការជូនដំណឹងអត្រាដុតបន្លឺ។ ការពារថវិកា។
តំណភ្ជាប់ទៅសេវាកំពុងរីករាលដាលលឿន ហើយការកើនឡើងនៃចរាចរណ៍ត្រូវបានរំពឹងទុកនៅពេលណាមួយព្រឹកនេះ — គ្មានអ្នកណាដឹងថាពេលណា ឬធំប៉ុនណាទេ។ ថ្ងៃនេះ instance ថ្មីត្រូវការ 8 នាទីដើម្បីចាប់ផ្តើម។ នៅពេលវាមកដល់ រក្សាកំហុស និងភាពយឺតឱ្យទាប ដោយមិនដុតលុយលើសមត្ថភាពទំនេរ។
នៅកំពូលថ្ងៃត្រង់ ស្គ្រីបថែទាំលុប cache ទាំងមូល។ ឥឡូវសំណើទាំងអស់ទៅមូលដ្ឋានទិន្នន័យ ដែលត្រូវបានកំណត់ទំហំសម្រាប់អត្រា hit 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]ការសន្មត៖ ចំនួន worker ពេលសេវា សមត្ថភាពមូលដ្ឋានទិន្នន័យ ទំហំ cache ល្បឿនបំពេញ តម្លៃ និងអត្រាកំហុសនៃ build អាក្រក់ គឺជាតម្លៃបង្ហាញសម្រាប់សេវាវេបទំហំមធ្យម។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]ការប៉ាន់ស្មាន៖ ការបូកquantile នៃសេវា និងការរង់ចាំមិនមែនជា 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]ការសន្មត៖ ចំនួន worker ពេលសេវា សមត្ថភាពមូលដ្ឋានទិន្នន័យ ទំហំ cache ល្បឿនបំពេញ តម្លៃ និងអត្រាកំហុសនៃ build អាក្រក់ គឺជាតម្លៃបង្ហាញសម្រាប់សេវាវេបទំហំមធ្យម។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]ការសន្មត៖ ចំនួន worker ពេលសេវា សមត្ថភាពមូលដ្ឋានទិន្នន័យ ទំហំ cache ល្បឿនបំពេញ តម្លៃ និងអត្រាកំហុសនៃ build អាក្រក់ គឺជាតម្លៃបង្ហាញសម្រាប់សេវាវេបទំហំមធ្យម។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ការសន្មត៖ ចំនួន worker ពេលសេវា សមត្ថភាពមូលដ្ឋានទិន្នន័យ ទំហំ cache ល្បឿនបំពេញ តម្លៃ និងអត្រាកំហុសនៃ build អាក្រក់ គឺជាតម្លៃបង្ហាញសម្រាប់សេវាវេបទំហំមធ្យម។ភាពចៃដន្យ៖ ម៉ាស៊ីនបង្កើត mulberry32 ដែលមានគ្រាប់ពូជ ការចែកចាយដែលប្រើ — ឯកសណ្ឋាន អិចស្ប៉ូណង់ស្យែល (CDF បញ្ច្រាស) ធម្មតា (Box–Muller) Poisson (Knuth)។ គ្រាប់ពូជត្រូវបានបង្ហាញ និងអាចចែករំលែកបាន។
គំរូអប់រំ — មិនសម្រាប់ការសម្រេចចិត្តប្រតិបត្តិការទេ។ ទីតាំងពិតកែតម្រូវរាល់ថេរទៅតាមឧបករណ៍ និងទិន្នន័យផ្ទាល់ខ្លួន។