איך אנחנו מודדים
המספרים שהאתר מציג כתוצאות מדידה נמדדו על שרת פיזי, עם המעבד ששרתי הייצור שלנו משתמשים בו: שינה, התעוררות ותמונת מצב, ומבחן הביצועים של ה-CPU. הנה כל אחד מהם, עם המכונה, היום, אופן המדידה והמקום שבו נמצאות התוצאות הגולמיות שלו.
- שרת פיזי. מכונה פיזית שלמה, לא מכונה וירטואלית על מכונה של מישהו אחר, כך ששום דבר שאנחנו לא רואים לא חולק אותה איתנו.
- חציונים, עם הפיזור שלהם. הערך האמצעי של הרצות רבות, ולצידו האחוזון ה-95 ומספר ההרצות.
- כשמדובר במקרה הטוב ביותר, אנחנו אומרים זאת. רוב המדידות האלה בוצעו כששום דבר אחר לא עבד על המכונה; במקומות שבהם זה כך, הדף מציין זאת.
- התוצאות הגולמיות נשמרות. כל נתון מציין את הקובץ שממנו נקרא, במאגר הקוד יחד עם הקוד שהפיק אותו.
שינה, התעוררות ותמונת מצב
- מכונה
- Cherry Servers, סינגפור: AMD Ryzen 9 9950X (Zen 5, 16 ליבות), 128 GB, Ubuntu 26.04.1, קרנל 7.0.0-34
- יום
- 3 באוקטובר 2026
- ארגז חול
- ארגז חול עם 4 vCPU / 8 GiB, node:24-bookworm
- צומת
- sandboxd עם ברירות המחדל של אותו יום: Firecracker עם תיקונים, זיכרון בשתי שכבות, תהליך שמוחזק מוכן לכל ארגז חול רדום, התקנים על PCI
- הצד הקורא
- על אותה מכונה, בחיבור אחד שנשאר פתוח, כך שכל נתון הוא הבקשה עצמה ולא לחיצת יד
| מה נמדד | איך נמדד הזמן | חציון | p95 | הרצות | מקור |
|---|---|---|---|---|---|
| הרדמה | POST …/sleep, כפי שנמדד אצל הצד הקורא | 2.3 ms | 2.8 ms | 30 | wake.txt cycle sleep |
| התעוררות, אחרי שנרדם מעצמו | המדידה של הצומת עצמו לזמן השחזור (בכותרת Server-Timing שלו), עבור הקריאה הבאה | 3.5 ms | 3.9 ms | 29 | wake.txt auto wake |
| אותה קריאה, עד התשובה | כל הבקשה שהעירה אותו, משליחה ועד תשובה | 6.7 ms | 7.1 ms | 29 | wake.txt auto call |
| התעוררות, מיד אחרי שינה | התהליך שמוחזק מוכן להתעוררות הבאה עדיין עולה, ולכן ההתעוררות ממתינה לו | 5.6 ms | 6.3 ms | 30 | wake.txt cycle wake |
| תמונת מצב של ארגז חול שרץ | דרך ה-API: זיכרון, תהליכים ודיסק, בזמן שהוא רץ | 32 ms | — | 4 | snapshot.txt 31.5 to 31.9 ms |
| יצירה, מהמאגר | עותק של תבנית שכבר רצה | 1.3 ms | — | 100 | tti-sequential.txt create median |
| יצירה, עד התשובה לפקודה הראשונה | אחד אחרי השני, מאה פעמים | 11.0 ms | 12.0 ms | 100 | tti-sequential.txt sequential x100 |
| 30 בבת אחת: כולם נרדמים | שלושים ארגזי חול שמרדימים באותו רגע, עד האחרון שבהם | 49.0 ms | — | 1 | wake.txt concurrent 30 sleep_all |
| 30 בבת אחת: כולם מתעוררים | אותם שלושים, שמעירים אותם באותו רגע, עד האחרון שבהם | 61.4 ms | — | 1 | wake.txt concurrent 30 wake_all |
הקבצים נמצאים ב-sandboxd/bench/results/2026-10-03-s3-ryzen9950x/4c8g-layers-final/; הסיכום הוא sandboxd/bench/results/README.md, סבב 2, סעיף 二. שאר דפי האתר קוראים את נתוני השינה וההתעוררות שלהם (3.5 מילישניות להתעוררות, 2.3 מילישניות להירדמות) מאותו קובץ כמו הטבלה הזו, כך שהם של הסבב הזה. תמונת המצב נבדקה דף אחר דף מול הזיכרון המלא ש-Firecracker עצמו כתב: 3 בתים בדף אחד, מתוך 2,097,152 דפים, היו שונים.
את אותו נתון אפשר לראות גם בארגזי החול שלכם: כל קריאת API שנאלצה להעיר ארגז חול מציינת כמה זמן זה לקח, במילישניות, בכותרת Server-Timing: wake;dur=… שלה.
CPU: מבחן הביצועים הפתוח של StarSling
StarSling מפרסמת מבחן ביצועים פתוח של ספקי ארגזי חול (github.com/starslingdev/hpc-sandbox-benchmarks). ציון ה-CPU שלו הוא מבחן web tooling של Node.js בארגז חול עם 4 vCPUs ו-8 GiB, במספר הרצות לשנייה. הרצנו את חבילת המבחנים שלו בארגז חול של Glac והשווינו את התוצאה לספקים שבהרצה האחרונה שפורסמה ושמופיעים בעותק הנתונים שלנו.
- Glac, הרצות לשנייה
- 29.0
- החציון של 13 ספקים
- 17.26
- מהיר יותר מהחציון הזה
- 68%
שלנו
- שרת הייצור הראשון שלנו, בקובנטרי, בריטניה: AMD Ryzen 9 9950X עם 128 GB, ב-10 באוקטובר 2026, במהלך מבחן הקבלה שלו, כששום ארגז חול אחר לא עבד עליו.
- חבילת המבחנים והאימג׳ של StarSling עצמה (
sandbox-benchmarks-toolchain:v8), בארגז חול עם 4 vCPUs ו-8 GiB, מורצים כמו שהמוצר מריץ אותם. - שלושה סבבים של חבילת המבחנים; כל סבב הוא החציון של שלושת הניסיונות שלו: 28.97, 29.27, 29.00. הנתון הוא החציון שלהם, 29.00.
שלהם
- ההרצה 36498291449 של StarSling: ההרצה שטבלת הדירוג שלה הציגה ב-2 באוקטובר 2026, כששמרנו עותק של הנתונים שלה, והאחרונה מבין תשע ההרצות שבעותק הזה (23–29 בספטמבר 2026).
- הערך של ספק הוא החציון, על פני ארגזי החול שלו, של הניסיון החציוני של כל ארגז חול: הכלל של טבלת הדירוג עצמה.
- העותק שלנו שומר כל ערך כיחס לערך של ספק אחד באותה הרצה, בדיוק של שלוש ספרות אחרי הנקודה, כך שכל ערך שלמטה שונה בכ-0.02 לכל היותר מהערך של StarSling עצמה.
התוצאה שלנו ו-13 הערכים, בהרצות לשנייה, מהגבוה לנמוך
29.0 ÷ 17.26 = 1.68, כלומר מהיר ב-68% מהחציון. שמות הספקים מופיעים בנתונים ש-StarSling פרסמה; הערכים כאן נקראים בזמן הבנייה מ-reports/providers/sources/performance-bar/starsling-metrics.tsv, שנוצר מהנתונים האלה על ידי analyse.py שלצידו.
מה המבחן לא אומר
- המבחן שלנו רץ כששום דבר אחר לא עבד על המכונה; המבחנים שלהם רצו לצד כל מה שהשרתים המארחים שלהם הריצו באותו יום. מכונה עמוסה מורידה את הציון: על 9950X עם 1.25 vCPUs עמוסים אחרים לכל ליבה, אותה חבילת מבחנים קיבלה 10.4 בארגז החול שלנו (8 באוקטובר 2026). השכנים האלה הריצו את אותו מבחן בלולאה, העומס הכי תובעני למטמון שיש, כבד יותר מכל צי אמיתי.
- זה מבחן ביצועים אחד של סוג עבודה אחד, Node.js שמריץ כלי JavaScript, והוא תלוי במהירות הליבות. הוא לא אומר דבר על דיסקים או על רשתות.
הקבצים
sandboxd/bench/results/2026-10-10-cvt-01-accept/: מבחן הקבלה, הפלט הגולמי שלו ו-results.jsonreports/providers/sources/performance-bar/starsling-metrics.tsvreports/providers/sources/performance-bar.md: איך העותק נוצר ונקראsandboxd/bench/results/README.md: סעיפים 40 ו-42
איפה נמצאות התוצאות הגולמיות
כל נתיב בדף הזה הוא קובץ במאגר הקוד של Glac עצמה, לצד הקוד שביצע את המדידה. המאגר אינו ציבורי; הנתיבים מציינים מאיזו הרצה מגיע כל נתון, והסיכום של כל סבב מפרט מה הורץ, על מה, ומה השתבש.