🖥️ IT ಕಾರ್ಯಾಚರಣೆಗಳು — ಸೈಟ್ ವಿಶ್ವಾಸಾರ್ಹತೆ ಲೈವ್ ಮಾದರಿ
ನೀವು ವೆಬ್ ಸೇವೆಗೆ ಆನ್-ಕಾಲ್ ಇದ್ದೀರಿ: ಇನ್ಸ್ಟೆನ್ಸ್ಗಳ ಫ್ಲೀಟ್ ಮುಂದೆ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್, ಡೇಟಾಬೇಸ್ ಮುಂದೆ ಕ್ಯಾಷ್, ಮತ್ತು 99.9 % ಲಭ್ಯತೆ ಉದ್ದೇಶ. ಪ್ರತಿ ನಿಮಿಷ ಮಾದರಿ ಪಠ್ಯಪುಸ್ತಕ ಸೂತ್ರಗಳಿಂದ ಸರತಿ ವಿಳಂಬ, ಟೈಮ್ಔಟ್ಗಳು, ಕ್ಯಾಷ್ ಹಿಟ್ಗಳು ಮತ್ತು ಡೇಟಾಬೇಸ್ ಹೊರೆಯನ್ನು ಲೆಕ್ಕ ಹಾಕುತ್ತದೆ — ಮತ್ತು ನಿಮ್ಮ ನಿರ್ಧಾರಗಳ ವೆಚ್ಚವನ್ನು.
ನೀವು ಏನು ಕಲಿಯುವಿರಿ
ಪೂರ್ಣ ಬಳಕೆಯ ಹತ್ತಿರ ವಿಳಂಬ ಏಕೆ ಸ್ಫೋಟಗೊಳ್ಳುತ್ತದೆ (ಎರ್ಲಾಂಗ್ C), ಮತ್ತು ಬೂಟ್ ವಿಳಂಬದೊಂದಿಗೆ ಸ್ವಯಂ ಸ್ಕೇಲಿಂಗ್ ಯಾವಾಗಲೂ ತಡವಾಗಿ ಏಕೆ ಬರುತ್ತದೆ.
SLOಗಳು, ದೋಷ ಬಜೆಟ್ಗಳು ಮತ್ತು ಬರ್ನ್-ರೇಟ್ ಎಚ್ಚರಿಕೆಗಳು ಯಾವಾಗ ಹಿಂದಕ್ಕೆ ಪಡೆಯಬೇಕೆಂದು ಹೇಗೆ ನಿರ್ಧರಿಸುತ್ತವೆ.
ತಣ್ಣನೆಯ ಕ್ಯಾಷ್ ಡೇಟಾಬೇಸ್ ವೈಫಲ್ಯವಾಗಿ ಹೇಗೆ ಬದಲಾಗುತ್ತದೆ, ಮತ್ತು ಯಾವ ನಿಯಂತ್ರಣಗಳು ಸಮಯ ಕೊಳ್ಳುತ್ತವೆ: ತಗ್ಗಿಸುವುದು, ಅವನತಿಗೊಳಿಸುವುದು, ವಾರ್ಮ್ ಮಾಡುವುದು.
ಸಿಮ್ಯುಲೇಟರ್
ಸಮಯ 0 ನಿಮಿ
▶ಸೇವೆ ನೀಡುತ್ತಿರುವ ಇನ್ಸ್ಟೆನ್ಸ್
⚙ಬೂಟ್ ಆಗುತ್ತಿರುವ ಇನ್ಸ್ಟೆನ್ಸ್
!ಕೆಟ್ಟ ಬಿಲ್ಡ್ನಲ್ಲಿರುವ ಇನ್ಸ್ಟೆನ್ಸ್
·ಖಾಲಿ ಸ್ಲಾಟ್
•ಒಳಬರುವ ವಿನಂತಿಗಳು
ನಿಯಂತ್ರಣಗಳು
ಫ್ಲೀಟ್ಗೆ ಕನಿಷ್ಠ ಮಿತಿ. ಅದನ್ನು ಏರಿಸಿದರೆ ಇನ್ಸ್ಟೆನ್ಸ್ಗಳು ತಕ್ಷಣ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ — ಸೇವೆ ನೀಡುವ ಮೊದಲು ಅವಕ್ಕೆ ಬೂಟ್ ವಿಳಂಬ ಬೇಕು.
ಬಳಕೆಯ ಮೇಲೆ ಗುರಿ ಟ್ರ್ಯಾಕಿಂಗ್; ಇನ್ಸ್ಟೆನ್ಸ್ಗಳು ಇನ್ನೂ ಬೂಟ್ ಆಗುತ್ತಿರುವಾಗ ಹೊಸ ಸ್ಕೇಲ್-ಔಟ್ ಇಲ್ಲ. ಆಫ್ = ನಿಖರವಾಗಿ ಕನಿಷ್ಠ.
ಕಡಿಮೆ = ಹೆಚ್ಚು ಅಂತರ ಮತ್ತು ಹೆಚ್ಚು ವೆಚ್ಚ. ಅಳೆದ ಬಳಕೆ 100 % ಮೀರಲಾರದು, ಆದ್ದರಿಂದ ಸ್ಯಾಚುರೇಟ್ ಆದ ಫ್ಲೀಟ್ ಹಂತಹಂತವಾಗಿ ಮಾತ್ರ ಬೆಳೆಯುತ್ತದೆ.
ಹೆಚ್ಚು TTL = ಹೆಚ್ಚು ಹಿಟ್ಗಳು, ಆದರೆ ಉತ್ತರಗಳು ಹಳೆಯದಾಗಿರಬಹುದು (ಸರಾಸರಿ ವಯಸ್ಸು ≈ TTL/2).
6 ನಿಮಿಷ ಹಾಟ್ ಕೀಗಳನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ (ನಿಮಿಷಕ್ಕೆ ಕ್ಯಾಷ್ನ +12 %) 600 ಹೆಚ್ಚುವರಿ ಡೇಟಾಬೇಸ್ ಪ್ರಶ್ನೆಗಳು/s ಬೆಲೆಯಲ್ಲಿ.
ಕಡಿಮೆ ಆದ್ಯತೆಯ 30 % ರ (ಪ್ರಿಫೆಚ್, ಬ್ಯಾಚ್, ಕ್ರಾಲರ್ಗಳು) ಪಾಲು, ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ನಲ್ಲಿ "ನಂತರ ಪ್ರಯತ್ನಿಸಿ" ಎಂದು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ.
ಭಾರೀ ವೈಶಿಷ್ಟ್ಯ ಪ್ರತಿ ವಿನಂತಿಗೆ 20 ms CPU ಮತ್ತು ಒಂದು ಡೇಟಾಬೇಸ್ ಪ್ರಶ್ನೆ ಸೇರಿಸುತ್ತದೆ. ಆಫ್ = ಸೌಮ್ಯ ಅವನತಿ.
ಕೊನೆಯ ಉತ್ತಮ ಬಿಲ್ಡ್ ಅನ್ನು ಹೊಸ ಸರ್ವರ್ ಸಮೂಹದಲ್ಲಿ ಮರು-ನಿಯೋಜಿಸುತ್ತದೆ (5 ನಿಮಿಷ, ಎರಡು ಬಾರಿ ಬಿಲ್), ನಂತರ ಟ್ರಾಫಿಕ್ ಬದಲಿಸುತ್ತದೆ. ಮತ್ತೆ ಒತ್ತಿದರೆ ಸಿದ್ಧತೆ ಮತ್ತೆ ಶುರುವಾಗುತ್ತದೆ; ಕೆಟ್ಟ ಬಿಲ್ಡ್ ಲೈವ್ ಇಲ್ಲದಿದ್ದರೆ ಅದು ಕೇವಲ ಹಣ ಖರ್ಚು ಮಾಡುತ್ತದೆ.
ಸೂಚಕಗಳು
ದೋಷ ದರ
0.00%
ಸಾಮಾನ್ಯ
p99 ವಿಳಂಬ
342ms
ಸಾಮಾನ್ಯ
ಉಳಿದ ದೋಷ ಬಜೆಟ್ (30 ದಿನ)
50.0%
ಸಾಮಾನ್ಯ
ಫ್ಲೀಟ್ ಬಳಕೆ
52%
ಸಾಮಾನ್ಯ
ಬರ್ನ್ ರೇಟ್ (1 ಗಂ)
0.0 ×
ವಿನಂತಿಗಳು
1125 req/s
ಸೇವೆ ನೀಡುತ್ತಿರುವ ಇನ್ಸ್ಟೆನ್ಸ್ಗಳು
10
ಬೂಟ್ ಆಗುತ್ತಿರುವ ಇನ್ಸ್ಟೆನ್ಸ್ಗಳು
0
ಕ್ಯಾಷ್ ಹಿಟ್ ದರ
77 %
ಡೇಟಾಬೇಸ್ ಬಳಕೆ
19 %
ತಗ್ಗಿಸಿದ ಟ್ರಾಫಿಕ್
0 %
ಫ್ಲೀಟ್ ವೆಚ್ಚ
4.00 $/h
ಇಲ್ಲಿಯವರೆಗಿನ ವೆಚ್ಚ
0.00 $
ಕ್ಯಾಷ್ ಮಾಡಿದ ಉತ್ತರಗಳ ಸರಾಸರಿ ವಯಸ್ಸು
30 s
ಕೆಟ್ಟ ಬಿಲ್ಡ್ನಲ್ಲಿ ಟ್ರಾಫಿಕ್
0 %
ಶಿಫಾರಸುಗಳು ಲಭ್ಯ
100 %
ಪ್ರವೃತ್ತಿ
ಬಿಕ್ಕಟ್ಟಿನ ಸನ್ನಿವೇಶಗಳು
ಹಂತ 1 · ಕೆಟ್ಟ ಬಿಡುಗಡೆ
09:10 ಕ್ಕೆ ಹೊಸ ಬಿಲ್ಡ್ ಹೊರಬರುತ್ತದೆ. ತಿಂಗಳು ಈಗಾಗಲೇ ಕಠಿಣವಾಗಿದೆ: ದೋಷ ಬಜೆಟ್ನ ಕೇವಲ 20 % ಉಳಿದಿದೆ. ನಿಯೋಜನೆಯ ನಿಮಿಷಗಳ ನಂತರ ಬರ್ನ್-ರೇಟ್ ಪೇಜ್ ಹೊಡೆಯುತ್ತದೆ. ಬಜೆಟ್ ಅನ್ನು ರಕ್ಷಿಸಿ.
ಕೊನೆಯಲ್ಲಿ ಉಳಿದ ದೋಷ ಬಜೆಟ್ ≥ 18.5 %
ನಿಯೋಜನೆಯ ನಂತರ ಸರಾಸರಿ ದೋಷ ದರ ≤ 0.65 %
ಫ್ಲೀಟ್ ವೆಚ್ಚ ≤ $9.50
ಹಂತ 2 · ಫ್ಲ್ಯಾಶ್ ಕ್ರೌಡ್
ಸೇವೆಗೆ ಒಂದು ಲಿಂಕ್ ವೇಗವಾಗಿ ಹರಡುತ್ತಿದೆ ಮತ್ತು ಈ ಬೆಳಿಗ್ಗೆ ಯಾವಾಗಲೋ ಸಂಚಾರದ ಏರಿಕೆ ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ — ಯಾವಾಗ ಅಥವಾ ಎಷ್ಟು ದೊಡ್ಡದು ಎಂದು ಯಾರಿಗೂ ತಿಳಿದಿಲ್ಲ. ಇಂದು ಹೊಸ ಇನ್ಸ್ಟಾನ್ಸ್ಗಳು ಆರಂಭವಾಗಲು 8 ನಿಮಿಷ ಹಿಡಿಯುತ್ತವೆ. ಅದು ಬಂದಾಗ, ನಿಷ್ಕ್ರಿಯ ಸಾಮರ್ಥ್ಯಕ್ಕೆ ಹಣ ಸುಡದೆ ದೋಷಗಳು ಮತ್ತು ಲೇಟೆನ್ಸಿಯನ್ನು ಕಡಿಮೆ ಇರಿಸಿ.
ಸರಾಸರಿ ದೋಷ ದರ ≤ 0.2 %
ಸರಾಸರಿ p99 ವಿಳಂಬ ≤ 400 ms
ಸರಾಸರಿ ತಗ್ಗಿಸಿದ ಟ್ರಾಫಿಕ್ ≤ 5 %
ಒಟ್ಟು ವೆಚ್ಚ ≤ $21
ಶಿಫಾರಸುಗಳು ≥ 85 % ಸಮಯ ಲಭ್ಯ
ಹಂತ 3 · ತಣ್ಣನೆಯ ಕ್ಯಾಷ್
ಮಧ್ಯಾಹ್ನದ ಉತ್ತುಂಗದಲ್ಲಿ ನಿರ್ವಹಣಾ ಸ್ಕ್ರಿಪ್ಟ್ ಇಡೀ ಕ್ಯಾಷ್ ಅನ್ನು ಫ್ಲಶ್ ಮಾಡುತ್ತದೆ. ಈಗ ಪ್ರತಿ ವಿನಂತಿ ಡೇಟಾಬೇಸ್ಗೆ ಹೋಗುತ್ತದೆ, ಅದು ಸಾಮಾನ್ಯ 85 % ಹಿಟ್ ದರಕ್ಕೆ ಗಾತ್ರ ಮಾಡಲಾಗಿತ್ತು. ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅತಿಭಾರ ಮಾಡದೆ ಸೇವೆಯನ್ನು ಮರಳಿ ತನ್ನಿ.
ಸರಾಸರಿ ದೋಷ ದರ ≤ 1.5 %
ಮೊದಲ ನಿಮಿಷದ ನಂತರ ಡೇಟಾಬೇಸ್ ಬಳಕೆ ಎಂದಿಗೂ 90 % ಮೇಲೆ ಇಲ್ಲ
ಕ್ಯಾಷ್ ಮಾಡಿದ ಉತ್ತರಗಳ ಸರಾಸರಿ ವಯಸ್ಸು ಸರಾಸರಿಯಾಗಿ ≤ 90 s
ಒಟ್ಟು ವೆಚ್ಚ ≤ $9
ಶಿಫಾರಸುಗಳು ≥ 80 % ಸಮಯ ಲಭ್ಯ
ಸರಾಸರಿ ತಗ್ಗಿಸಿದ ಟ್ರಾಫಿಕ್ ≤ 5 %
ಆಧಾರ — ಸಂಖ್ಯೆಗಳ ಹಿಂದಿನ ಮಾದರಿ
ಸಿಮ್ಯುಲೇಟರ್ ಬಳಸುವ ಪ್ರತಿ ಸಂಬಂಧ, ಅದರ ಮೂಲದೊಂದಿಗೆ. ಊಹೆಗಳೆಂದು ಗುರುತಿಸಿದ ಸ್ಥಿರಾಂಕಗಳು ವಿವರಣಾತ್ಮಕ ಮಾಪನಾಂಕಗಳು.
ವಿನಂತಿಗಳು ದೈನಂದಿನ ವಕ್ರರೇಖೆ ಮತ್ತು ಅಡಚಣೆಗಳನ್ನು ಅನುಸರಿಸುತ್ತವೆ; ನಿಮಿಷದ ಎಣಿಕೆ ಯಾದೃಚ್ಛಿಕ (ಪಾಯ್ಸನ್, ಸಾಮಾನ್ಯ ಅಂದಾಜು) ಸ್ವಲ್ಪ ಸ್ಫೋಟಕತೆಯೊಂದಿಗೆ.
λ(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]ಊಹೆ: ವರ್ಕರ್ ಸಂಖ್ಯೆಗಳು, ಸೇವಾ ಸಮಯಗಳು, ಡೇಟಾಬೇಸ್ ಸಾಮರ್ಥ್ಯ, ಕ್ಯಾಷ್ ಗಾತ್ರ, ಮರುತುಂಬುವ ವೇಗ, ಬೆಲೆಗಳು ಮತ್ತು ಕೆಟ್ಟ ಬಿಲ್ಡ್ನ ದೋಷ ದರ ಮಧ್ಯಮ ಗಾತ್ರದ ವೆಬ್ ಸೇವೆಗೆ ವಿವರಣಾತ್ಮಕ ಮೌಲ್ಯಗಳು.
ಎರ್ಲಾಂಗ್ C: M/M/N ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ವಿನಂತಿ ಮುಕ್ತ ವರ್ಕರ್ಗಾಗಿ ಕಾಯಬೇಕಾದ ಸಂಭವನೀಯತೆ.
N = instances × 16 workers, a = λ·S; C(a, N) = B / (1 − (a/N)(1 − B)), B = Erlang B[3][6]
ಕಾಯುವ ಸಮಯದ ಬಾಲ: t ಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಕಾಯುವ ಸಂಭವನೀಯತೆ ಘಾತೀಯವಾಗಿ ಕುಸಿಯುತ್ತದೆ; 2-s ಟೈಮ್ಔಟ್ನಲ್ಲಿ ಇನ್ನೂ ಕಾಯುತ್ತಿರುವ ವಿನಂತಿಗಳು ವಿಫಲವಾಗುತ್ತವೆ. ಸಾಮರ್ಥ್ಯ ಮೀರಿದರೆ ಹೆಚ್ಚುವರಿ ವಿಫಲವಾಗುತ್ತದೆ.
ಸೇವಾ ಸಮಯ ಮತ್ತು ಕಾಯುವ ಸಮಯದ ಕ್ವಾಂಟೈಲ್ಗಳಿಂದ p99 ವಿಳಂಬ.
p99 ≈ S·ln 100 + ln(C/0.01)/(N/S − λ) (service + waiting quantile, an approximation)[3][6]ಅಂದಾಜು: ಸೇವೆ ಮತ್ತು ಕಾಯುವಿಕೆ ಕ್ವಾಂಟೈಲ್ಗಳನ್ನು ಕೂಡಿಸುವುದು ಅವುಗಳ ಮೊತ್ತದ ನಿಖರ p99 ಅಲ್ಲ (ಅದು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಇರಬಹುದು); ವಿನಂತಿಗಳು ಮಿಲಿಸೆಕೆಂಡ್ಗಳಲ್ಲಿ ಮುಗಿಯುವುದರಿಂದ ಸರತಿಯನ್ನು ಪ್ರತಿ ನಿಮಿಷದೊಳಗೆ ಸ್ಥಿರವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.
ಲಿಟಲ್ನ ನಿಯಮ: ಕಾರ್ಯನಿರತ ವರ್ಕರ್ಗಳು = ಆಗಮನ ದರ × ಸೇವೆಯಲ್ಲಿನ ಸಮಯ.
TTL ಕ್ಯಾಷ್: ಯಾದೃಚ್ಛಿಕ ವಿನಂತಿಗಳೊಂದಿಗೆ, ಪ್ರತಿ ಮಿಸ್ ವಿನಂತಿಗಳು ಹಿಟ್ ಆಗುವ TTL ಅವಧಿಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
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]ಊಹೆ: ವರ್ಕರ್ ಸಂಖ್ಯೆಗಳು, ಸೇವಾ ಸಮಯಗಳು, ಡೇಟಾಬೇಸ್ ಸಾಮರ್ಥ್ಯ, ಕ್ಯಾಷ್ ಗಾತ್ರ, ಮರುತುಂಬುವ ವೇಗ, ಬೆಲೆಗಳು ಮತ್ತು ಕೆಟ್ಟ ಬಿಲ್ಡ್ನ ದೋಷ ದರ ಮಧ್ಯಮ ಗಾತ್ರದ ವೆಬ್ ಸೇವೆಗೆ ವಿವರಣಾತ್ಮಕ ಮೌಲ್ಯಗಳು.
SLO ಮತ್ತು ದೋಷ ಬಜೆಟ್: ಬರ್ನ್ ರೇಟ್ ಬಜೆಟ್ ಅನುಮತಿಸಿದ್ದಕ್ಕಿಂತ ಎಷ್ಟು ಪಟ್ಟು ವೇಗವಾಗಿ ಖರ್ಚಾಗುತ್ತಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ.
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 ಜನರೇಟರ್; ಬಳಸಿದ ವಿತರಣೆಗಳು — ಏಕರೂಪ, ಘಾತೀಯ (ವಿಲೋಮ CDF), ಸಾಮಾನ್ಯ (Box–Muller), ಪಾಯಿಸಾನ್ (Knuth). ಸೀಡ್ ತೋರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಹಂಚಿಕೊಳ್ಳಬಹುದು.
M. Harchol-Balter — Performance Modeling and Design of Computer Systems: Queueing Theory in Action (M/M/k, server farms, capacity provisioning) — Cambridge University Press, 2013