פתרונותצד שרת לכל משתמש
מופע לכל משתמש
מפתח בבקשה מנתב כל משתמש, דייר או סוכן למופע משלו, ששומר את הזיכרון והדיסק שלו ונרדם בין בקשות.
from glac import Glac
glac = Glac()
app = glac.cube.deploy(
"ghcr.io/acme/notes:2", name="notes", port=8080,
keys={"from": {"header": "X-User"}, # the key
"delete_after_idle_ms": 30 * 86_400_000},
scale={"suspend_after_ms": 1000}) # sparse traffic: asleep a second after
# a request with X-User: ada reaches ada's own instance
ada = app.instance("ada") # or make or wake it from codeמצב לכל משתמש, ותשלום על כל שעה
תהליך לכל משתמש הוא התכנון הפשוט ביותר, וכשהוא נשאר פועל משלמים עליו גם כשהמשתמשים לא שם. כאן, המופע של כל מפתח נרדם בין בקשות ומשלם רק על מה שהוא שומר.
איך מפתח מנתב
הגדירו את keys.from לכותרת או לקטע בנתיב. הבקשה הראשונה של מפתח חדש יוצרת את המופע שלו; כל בקשה אחריה מגיעה לאותו מופע, עם הזיכרון והדיסק שלו. בקשות בלי מפתח חולקות את המופעים של האפליקציה.
מה המופע של כל משתמש מקבל
בחרו את המבנה: מופעים משותפים, או מופע לכל מפתח של משתמש.
מפתח מהבקשה, בכותרת או בנתיב; הבקשה הראשונה יוצרת את המופע שלו.
מצב לכל משתמש: זיכרון שנשמר לאורך השינה, דיסק משלו, ואמצעי אחסון.
כמה זה עולה: בזמן שינה אין חיוב על CPU, רק על מה שהוא שומר.
משך חיים לבחירתכם: נמחק אחרי שישן פרק זמן שאתם קובעים, ונוצר מחדש לפי המפתח שלו.
שימוש לכל מפתח, לפי המפתח שכל מופע נושא כתווית.
תצוגות להמחשה
נמדד, לא מובטח
חציונים על שרת פיזי שלא רץ עליו שום דבר אחר: התרחיש הטוב ביותר, ואנחנו אומרים את זה במפורש. המופע של מפתח הוא מאותו סוג כמו ארגז חול, שעליו נמדדו הנתונים האלה. איך אנחנו מודדים
- להעיר מופע רדום2
- 3.5 ms
- לקריאה שהעירה אותו, משליחה ועד תשובה2
- 6.7 ms
- להרדים אותו, עם הזיכרון והתהליכים שלו2
- 2.3 ms
תוכלו לראות את זה במפתחות שלכם כשהשירות ייפתח: שורת הלוג של בקשה שהעירה מופע מציינת כמה זמן ההתעוררות לקחה.
glac cube logs notes -f
# one line a request; one that woke an instance says how long it tookהמוצרים שבשימוש
חודש, בחישוב מפורט
עשרת אלפים משתמשים, לכל אחד מופע משלו, במחירי המחירון. לחישוב העלות שלכם
תרחיש השימוש
- 10,000 משתמשים, לכל אחד מופע משלו, עם 256 MiB בשימוש.
- כל משתמש שולח 300 בקשות ביום במשך 30 ימים, כל אחת עם 20 מילישניות CPU ותשובה של 5 KB, בזמנים אקראיים.
- האפליקציה מוגדרת כך שמופע נרדם באמת שנייה אחרי שהוא נעצר (scale.suspend_after_ms 1000), ההגדרה שמתאימה לתעבורה דלילה כזו: הבקשות של משתמש מגיעות בהפרשים של דקות, ומופע שנשאר מושהה בזיכרון בין בקשה לבקשה מחויב על הזיכרון הזה כל הזמן. לכן כל מופע ער בזמן שהוא עונה ועוד 1 שנייה אחר כך, מושהה עוד 1 שנייה, ואז ישן כשהזיכרון שלו שמור, ותופס כ-100 MB.
- המחיר של זה: בקשה שמוצאת את המופע שלה ישן נענית תוך 6.7 מילישניות, ובקשה שמוצאת אותו מושהה נענית תוך 0.43 עד 1.72 מילישניות; וכל שינה והתעוררות צורכות 25.6 מילישניות CPU, שנכללות ב-CPU של החודש.
חודש במחירי המחירון
- CPU4.3 מיליארד מילישניות CPU × $0.01 למיליון$42.95
- זיכרון12,581 GiB-שעה × $0.008$100.65
- בקשות90 מיליון × $0.30 למיליון$27.00
- תעבורה יוצאת450 GB × $0.004$1.80
- אחסון בזמן שינה1,000 GB-חודש × $0.02$20.00
בתוכנית בתשלום החודש הזה עולה $189.60: דמי המנוי של $5, ועוד $184.60 מעבר למה שהכמויות הכלולות מכסות, מהיתרה שלכם באותם מחירים.
תנו לכל משתמש מופע משלו
מפתח, ואחר כך אפליקציה עם keys.from, שנפרסת בקריאה אחת.