זה טקסט מרגיע במשפך מכירות, לא הבטחה טכנית. כשמארח מדפיס "ללא הגבלה" על כרטיס התוכנית, הם לא מבטיחים העברה אינסופית על פני הפיזיקה והתקציבים; הם מבטיחים לא למדוד פריט שורה ספציפי בחשבונית שלך תוך שליטה על כל שאר הדברים שבאמת קובעים אם האתר שלך נשאר מהיר ונגיש. האמת המעשית היא פשוטה וקצת מרגיזה: התוכנית שלך אולי לא תמדוד העברה חודשית, אבל היא בהחלט תמדוד אותך בדרכים אחרות ברגע שהשימוש שלך ייראה לא רגיל, קופצני או יקר לשרת.
ראיתי את זה קורה מספיק פעמים כדי לזהות את הדפוס מהשרשור התמיכה הראשון. האתר מתחיל חזק, הדירוגים עולים, קמפיין פוגע, ואז תוכנית ה"ללא הגבלה" מפתחת אישיות. הבקשות לוקחות יותר זמן. הנכסים הסטטיים זוחלים. העובדים מצטברים. שגיאות מופיעות בכיסים כי המארח מתחיל להגן על הסביבה המשותפת, לא על ההצלחה שלך. זה לא רשעות; זו מציאות כלכלית. מארחים מוכרים "ללא הגבלה" כדי למשוך אתרים קטנים שהשימוש האמיתי שלהם הוא קטן וצפוי. החריגים—וידאו, הורדות, ממשקי API ציבוריים, אפליקציות עם מטמון גרוע—הופכים ל"התעללות" ברגע שהגרפים זזים. תנאי השימוש ומתזמני המשאבים נכנסים לתוקף. אם קנית "ללא הגבלה" בציפייה שהמסלול יגדל, תרגיש מופתע. אם תתייחס אליו כאל לא מדוד על הנייר אבל מאוד מדוד בפועל, תקבל החלטות ארכיטקטורה חכמות יותר ותמנע את הודעת ההשעיה שתמיד מגיעה בזמן הכי לא נוח.
רוחב פס, העברה, תפוקה ומהירות פורט הם לא אותו דבר
לא אכפת לי כמה פעמים התעשייה מטשטשת את המונחים - אם אנחנו רוצים להיות כנים לגבי מה שאתה יכול למעשה לדחוף, אנחנו צריכים להפריד את אוצר המילים. רוחב פס הוא גודל הצינור ברגע נתון. תפוקה היא מה שאתה באמת משיג דרך הצינור הזה לאחר תקורה, תחרות והגבלת מהירות. העברת נתונים היא הסכום הכולל שהועבר על פני תקופה מסוימת, בדרך כלל חודש. מהירות פורט היא התקרה הקשה על זרימה מיידית, בדרך כלל מבוטאת כ-10 Mbps, 100 Mbps, 1 Gbps או יותר.
"ללא מדידה" הוא הבטחת חיוב לגבי העברה חודשית, לא על הקצב המיידי שהחבילות שלך מקבלות בצהריים ביום שני. "ללא הגבלה" הוא תוספת שיווקית שמרמזת שאין תקרה, אבל מה שיש לך באמת הוא תוכנית שלא מחשבת גיגות נוספות בזמן שמגבילה הכל דרך כל השאר: מניות מעבד, קלט/פלט, ספירות תהליכים, חיבור מקבילי, ולבסוף הפורט שהחבילות שלך חייבות לעבור דרכו. פורט של 1 Gbps יכול, בתיאוריה, להעביר כמות עצומה בחודש, אבל אם המארח מעצב את הפורט שלך ל-100 Mbps אחרי חמש דקות של תפוקה מתמשכת - או פשוט נותן לך נתיב "מתפרץ" שיורד תחת עומס - ההעברה התיאורטית שלך מתאדה לזמן המתנה אמיתי ולבקשות שנכשלות. הצינור שחשבת שקנית הוא הצינור שאתה תופס רק כשאתה שקט.
כשאני סוקר תוכנית, אני לא שואל "האם רוחב הפס ללא הגבלה?" אני שואל שאלה אחרת, מכוערת יותר: "מה התפוקה המיידית הגרועה ביותר שאני מובטח כששכני ואני עסוקים?" זה המספר ששומר על הקופה שלך מלהיתקע, על התמונות שלך מלהתעכב ועל עבודות הרקע שלך מלהצטבר למסלול של ניסיונות חוזרים שתשלם עליהם מאוחר יותר.
כיצד אירוח משותף מתוכנן להיראות בלתי מוגבל (עד שזה לא)
אירוח משותף הוא טריק קרנבל המבוסס על ממוצעים. רוב האתרים קטנים. רוב התעבורה היא ברסטית בדרכים ידידותיות. רוב הדפים נשמרים במטמון לאחר הזחילה הראשונה. כך מארחים יכולים להירשם יתר על המידה במעבדים, בזיכרון, באחסון I/O ובנתיבי רשת ועדיין לשרת לוחות מחוונים עליזים לאלפי לקוחות. המכונה מאחורי האשליה הזו היא קן של מתזמנים ווסתים של חלוקה הוגנת ומערכות הקצאה. שיתופי CPU מונעים מחשבון יחיד לקחת ליבה מלאה לזמן ממושך. עיצוב IOPS מונע משכנים רעשניים לרעוב את ה-SAN. כיפות תהליכי PHP-FPM ו-Node מבטיחות שרק קומץ בקשות יכולות להתבצע באופן דינמי בו זמנית. תקרות inode מגבילות בשקט את מספר הקבצים שאתה יכול לשמור על הדיסק, חונקות אתרים עשירים במדיה לפני שההעברה אי פעם מופיעה בגרף.
הדבר הקריטי לשים לב אליו הוא שאף אחת מהמערכות הללו לא נוגעת בפריט השורה של "רוחב פס". זה נשאר ללא מדידה, כך שהטענה נשארת כנה מבחינה טכנית. ברגע שהאפליקציה שלך מתחילה להיראות עסוקה יותר מרגע, כללי החלוקה ההוגנת אוכפים "שימוש טיפוסי" על ידי האטת החלקים של ערימתך שהם שולטים עליהם. תראה בקשות דינמיות נכנסות לתור בעוד שהנכסים הסטטיים מרגישים בסדר. לאחר מכן הנכסים הסטטיים מאטים מכיוון שהמקור הופך לצוואר הבקבוק ש-CDN לא יכול להסתיר במלואו. המארח עדיין לא מחייב אותך על העברה. הם פשוט גורמים לך להשתמש פחות מזה על ידי הפחתת מהירות ההגשה.
אני לא חושב שהמארחים המשותפים הם נבלים על כך. המודל עובד עבור הרוב המכריע של האתרים, והוא שמר על האינטרנט בזול עבור מפרסמים קטנים. אבל הביטוי "רוחב פס ללא הגבלה" נותן מודל מנטלי שגוי. הוא מזמין אותך לארכיטקט כאילו יש לך נתיב ייעודי, ואין לך. יש לך רשות לשפוך מים לדלי מבלי לשלם לפי ליטר, אבל אתה עדיין משתף את הברז.
האותיות הקטנות שבאמת מכתיבות את השימוש שלך
אם אתה רוצה את האמת, אל תקרא את טבלת המחירים; קרא את מדיניות השימוש המקובלת. תמצא ביטויים מצופים סוכר כמו "אתרים טיפוסיים" ו"שימוש הוגן", שמתרגמים ל"אם אתה מתחיל להיראות כמו צומת שיתוף קבצים, אתר סטרימינג, מראה מדיה או מרכז הורדות, אנו שומרים לעצמנו את הזכות להאט, להעביר או להשעות אותך." תמצא איסורים על סטרימינג של שמע ווידאו מהמקור, הפצת קבצים בקנה מידה, ארכיוני גיבוי המאוחסנים במרחב האינטרנט, אוספי ZIP זמינים לציבור ותסריטים "אינטנסיביים במשאבים" שרצים יותר מכמה שניות כל אחד. תמצא מגבלות שניות CPU יומיות, תקרות שאילתות מסד נתונים וספירת חיבורים שגורמות לזחילת האסינכרונית האהובה עליך להיראות כמו התקפה.
מגבלות תהליך כניסה הן במיוחד ערמומיות. בסביבות בסגנון cPanel, "תהליך כניסה" לעיתים קרובות פירושו "מספר הבקשות הדינמיות בו זמנית המורשות להתחיל." הגע לתקרה זו והמבקר הבא לא נכנס לתור; הם מקבלים שגיאות. מגבלות I/O ומספרי IOPS עושים את אותו הדבר לדיסק. מגבלות inode חותכות אותך כשיש לך "יותר מדי קבצים", ספריות מדיה שאפתניות נתקלות בזה לפני שהן נוגעות בתפוקה. אף אחד מהדברים הללו לא מפר "רוחב פס ללא הגבלה." הם פשוט מבטיחים שתשתמש במעט ממנו כשהאתר שלך מתחיל לגדול.
איבדתי ספירה של התכניות שטוענות "ללא הגבלה" בעודן קובעות בשקט את ה-CPU ל-"100% של ליבה אחת לכמה שניות", את ה-I/O ל-"כמה מגה בייט לשנייה מתמשכים", ואת התהליכים ל-"קומץ בכל פעם." זה חגורה, שלייקס וחבל. אם תגיע לכל השלושה, אתה לא רץ; אתה משתרך.
איך נראה "ללא הגבלה" ביום שני עמוס
תארו לעצמכם יום שני רגיל לאחר אזכור בסוף שבוע שמביא לכם תשומת לב חדשה. ה-HTML שלכם הוא די קל, התמונות שלכם הן סבירות, אתם נשענים על CDN לנכסים סטטיים, והמוצא שלכם מטפל בחלקים הדינמיים. התנועה עולה פי חמישה. בהתחלה, הכל בסדר כי המטמונים חמים וה-CDN אוכל את רוב בקשות התמונה. ואז נקודות הקצה הדינמיות שלכם מפגרות מאחור. מגבלת התהליכים של המארח שומרת על מספר קטן של עובדים PHP או Node פעילים במקביל. התורים מתחילים, וזמני התגובה מתארכים מספיק כדי לשבור את פסקי הזמן בין השירותים. ה-CDN עדיין עוזר, אבל החמצות מטמון ב-HTML מתחילות לנשוך. מסד הנתונים שלכם הופך לפטפטן יותר, ומתזמן ה-I/O מחסיר נתח נוסף כי עכשיו אתם "אינטנסיביים במשאבים". הלקוחות שלכם, בתזמון מושלם, לוחצים על תמונות שלא היו חמות ב-CDN, מושכים פרצים מהמוצא שמתנגשים עם עבודה דינמית איטית.
מה שקורה אחר כך תלוי במארח. כמה מארחים מאטים אתכם באופן פרוגרסיבי עד שהביצועים כל כך גרועים שהמבקרים מתייאשים וה"ממוצע" שלכם חוזר לנורמל. אחרים מפעילים חוקים אוטומטיים לניצול יתר ומעבירים את החשבון שלכם לבריכה ברמה נמוכה יותר או ל-VLAN בהסגר. יש כאלה שעדיין זורקים את התגובה הקלאסית 509, "חריגה ממגבלת רוחב פס", למרות שהם לא סופרים בתים - 509 הוא רק תמרור עצור שימושי לקנות זמן בזמן שהם בודקים. התוצאה מרגישה זהה: ההבטחה ל"ללא הגבלה" מתפוגגת בדיוק כשאתם צריכים את זה.
אתר שמשרת בעיקר HTML מטמון ונכסים סטטיים עשוי לשרוד עם מבקרים מעוצבנים. חנות עמוסת עגלה או אפליקציה שמבוססת על חיפוש ייקחו את זה בראש. הכאב לעיתים רחוקות מופיע כמדד אחד נקי. זהו פסיפס של האטות קטנות שמצטברות לכישלונות בקופה ולעלייה בנטישה.
לפני שנעמיק יותר, אני רוצה לעשות משהו קונקרטי וניתן לשימוש חוזר כך שתוכלו לראות את התקרה המעשית גם כאשר התוכנית טוענת שהיא לא קיימת.
אני הולך לצלול למספרים מוחשיים לכמה דקות. זהו קטע פרימיום שמתמקד ישירות במתמטיקה שתוכלו לעשות על מפית כדי לתרגם מהירות פורט להעברה חודשית ואז למספר צפיות. אם אי פעם נאבקתם למפות "1 Gbps ללא מדידה" ל"כמה ביקורים אני יכול לשרת בפועל?" כאן זה מתחדד לפוקוס.
Premium content
התחבר כדי להמשיך
הרוצחים השקטים: הגבלת מעבד, עיצוב IOPS, והגבלת תהליכים
אם אי פעם הרגשתם שעמוד מאט בזמן שהגרפים נראים "נורמליים," פגשתם את הרוצחים השקטים. הגבלת מעבד היא הנראית ביותר כשאתם יודעים היכן לחפש. מארחים משותפים מקצים חלק מליבת מעבד להתפרצויות ואז מפחיתים אתכם תחת עומס מתמשך. האפליקציה שלכם לא קורסת; היא נגררת. זה מספיק כדי להפיל דירוגי חיפוש ושיעורי המרה בלי להפעיל אזעקות שיגרמו לתמיכה להתערב.
עיצוב IOPS הוא עדין יותר. בסיסי נתונים חיים ומתים לפי השהיית אחסון. אפליקציות כבדות קבצים גם כן. מארחים משתמשים ב-cgroups וב-QoS אחסון כדי למנוע מהכבדות להרעיב את המערך. אתם לא רואים שגיאה; אתם רואים המתנה לדיסק של עשרים מילישניות שמתהפכת לשמונים, מה שמוביל את זמני הבקשות להתפלגות חדשה ומכוערת יותר. שלבו זאת עם הגבלת תהליכים נמוכה והקמתם קופסת לחיצה מושלמת. בקשות לוקחות יותר זמן, כך שיותר בקשות מקבילות, מה שפוגע בתקרה מוקדם יותר, מה שמשליך מבקרים חדשים על הרצפה.
הגבלת תהליכים, בסופו של דבר, היא הגיליוטינה. תוכניות רבות מגבילות את PHP-FPM או דומה למספר קטן של ילדים. חלקן מוסיפות מגבלה על סך כל התהליכים המקבילים למשתמש. שתיהן מאפשרות למארח לחייך ולהבטיח "רוחב פס בלתי מוגבל" תוך ודאות שלא תוכלו, למעשה, לשלוח הרבה. אם אי פעם רדפתם אחרי צוואר בקבוק דמיוני ב-CDN או בקוד האפליקציה שלכם רק לגלות שהמארח מאפשר שמונה עובדים וקורא לזה יום, הרגשתם את המלכודת.
אני לא רושם "רוחב פס בלתי מוגבל" בספר הסיכונים שלי כבעיה לתקן. אני מפחית את התלות שלי בזה. המודל שעובד עבור רוב האתרים הקטנים והבינוניים הוא משעמם ויעיל. אכסנו HTML בקצה כל עוד התוכן שלכם מאפשר. העבירו תמונות, CSS ו-JS ל-CDN שאתם באמת מאמתים בייצור עם שיעור פגיעות גבוה, לא רק לוגו. העבירו מדיה כבדה לאחסון אובייקטים והפנו את ה-CDN לשם כך שהמקור לא יראה זאת לעולם. שמרו על המקור ממוקד בקריאות וכתיבות דינמיות שצריכות באמת חישוב, וגרמו להן להיות כמה שיותר נטולות מצב ומהירות.
כשאתם עושים זאת, תוכנית "רוחב פס בלתי מוגבל" הופכת לקבילה כי אתם לא מבקשים ממנה לשאת בעומס שהיא לא יכולה לשאת בלי דרמה. גם אם המארח מעצב את המקור שלכם, ה-CDN סופג את האקראיות של התנועה. ה-p95 שלכם מתייצב, ואתם קונים זמן לבחור מהלך כשהצמיחה אמיתית במקום להגיב בזמן נפילה. כל האותיות הקטנות עדיין קיימות, אבל אתם לא דורכים עליהן. בניתם מקור קטן וזריז במקום מחסן.
אני אף פעם לא שם סטרימינג וידאו, הורדות קבצים, מראות תוכנה ציבוריות או הפצת גיבויים על תוכנית שאומרת "בלתי מוגבל." אני אומר את זה כמישהו שניסה לסחוט אותם ואז ניהל משא ומתן עם שפת ToS לאחר מעשה. עומסים אלו אינם מה שהאירוח המשותף נבנה עבורו, והמארח יסגור אתכם בשם הגנה על כולם. גם אם תצליחו בכך לזמן קצר, אתם במרחק אזכור אחד מעמודים של אימיילים כועסים והעברה באמצע הלילה.
ארכיוני ZIP כבדים של נכסי מוצרים או חומרי למידה יפעילו את אותם האזעקות. APIs ציבוריים שמעודדים שאילתות לקוח יעשו זאת גם כן. וכל דבר שמעודד משתמשים להוריד את אותו קובץ מולטי-מגה בייט שוב ושוב על חיבורים חדשים יפגע בעיצוב פורטים מהר משאתם חושבים. החוט שמחבר את המקרים הללו פשוט: הם עומסים גבוהי יציאת נתונים, נמוכי חישוב שתוקפים את חשבון המעבר של המארח בלי לצרוך את ה-CPU או ה-I/O שהמתזמנים שלהם מכוונים למדוד. חוסר התאמה זה הוא בדיוק הסיבה ש"רוחב פס בלתי מוגבל" קיים כנסח. זו הבטחה רכה שנבנתה כדי להתבטל ברגע שהשימוש שלכם מפסיק להיראות כמו בלוג קטן.
אני רוצה לתת לכם מדריך תרגום עם עורך דין ומדדים שתוכלו לשמור. החלק הבא הוא חלק פרימיום שבו אני מתרגם את הסעיפים הנפוצים ביותר שמארחים משתמשים במציאות תפעולית. אם לא תקראו שום דבר אחר, קראו את זה כשאתם סורקים תוכנית ב-1 בלילה ותוהים אם "בלתי מוגבל" ישא את ההשקה הבאה שלכם.
Premium content
התחבר כדי להמשיך
ניטור מה שחשוב כדי שתדע לפני שהמייל על ההשעיה יגיע
לוח הבקרה שמספק לך המארח לא יתריע בפניך על הכשלון המתקרב. הוא ידווח על ממוצעים וסה"כ בזמן שהכאב מסתתר בזנב הארוך. אני צופה בסימנים שונים. מעבר מקור מול מעבר CDN אומר לי האם הקאש שלי עושה את עבודתו. אם מעבר המקור עולה מהר יותר מהביקורים, אני יודע שמשהו עוקף או נמחק באגרסיביות יתרה. תחרות חיבור היא קנרית עבור גבולות תהליך; אם חיבורים במקביל מתקרבים לתקרה שטוחה, אני מצפה לשגיאות מיידיות למבקרים חדשים. רוחב הפס והזמן לבקשה ב-95 האחוז העליון חשובים יותר מהממוצעים כי הם מנבאים את חלקי היום שבהם המארח יגביל אותך והמשתמשים שלך ייכשלו בהשלמת מסע.
זמן גניבת CPU הוא מבחן ריח לסביבה משותפת. אם אני רואה גניבה עולה בשעות השקטות שלי, אני יודע שאני מתמודד עם שכנים ושהפיצוץ שלי ינחת על צומת עייף. שאילתות איטיות תמיד שוות את הזמן שאתה חושב שאין לך; תיקון אינדקס רע יכול להיות ההבדל בין לשרוד אזכור לבין לשרוף יום בהתנצלות. תקציבי שגיאות—מספר השגיאות שאתה מתיר בחלון לפני שאתה רואה את חוויית המשתמש כמתדרדרת—מחברים את כל זה יחד. אם השגיאות שלך מטפסות לפני שהתנועה עושה זאת, יש לך חיכוך בלתי נראה ו"ללא הגבלה" לא ירכך דבר.
עקוב אחרי הכסף והסיפור מפסיק להיות מסתורי. מעבר יקר אם אינך יכול לנהל משא ומתן על חיבורי peering מעולים ואם המשתמשים שלך יושבים רחוק מנקודות הנוכחות שלך (POPs). אירוח משותף מפזר את העלות הזו על פני אלפי חשבונות שרובם בקושי משתמשים במשהו. "ללא הגבלה" הוא כלי לרכישת לקוחות. הוא מפחית חיכוך ומשווה טוב בטבלה שבה התוכנית הזולה יותר "כוללת" יותר. המארח מניח שתהיה קטן, או שתעשה את הדבר ההגיוני ותעביר את התנועה הכבדה שלך ל-CDN ואחסון אובייקטים ברגע שתגדל, מה שמעביר את המעבר לספק שעושה רק מעבר.
עננים הופכים את המודל. הם מודדים מעבר כי זה מרכז הרווח שלהם וכי הרשתות שלהם יקרות לתפעול בקנה מידה עולמי. הם לא מבטיחים "ללא הגבלה" כי התמריץ שונה; הם רוצים שתתכנן בתבונה ותשלם על מה שאתה משתמש. מארחים משותפים רוצים שתביא את האתר הקטן שלך ותשאר מרוצה עד שלא תהיה קטן, בנקודה זו הם רוצים שתעשה אופטימיזציה או תשדרג. אף אחד מזה לא ציני; זה איך החשבונות משתלמים. אבל זה מסביר למה תנאי השירות נכתבים בשפה קטיפה ולמה הגבולות הטכניים נאכפים במגע קל עד שהם לא.
נקודות החלטה: מתי "ללא הגבלה" זה בסדר, מתי זה פזיז, וכיצד לבצע הגירה
אני לא זורק "ללא הגבלה" מהיד. עבור אתר שיווק קטן עם דפים סטטיים בעיקר ובלוג צנוע, זה לגמרי בסדר אם אתה שם CDN לפניו. עבור חנות עם תעבורה קלה וקשור הגיוני, זה יכול לעבוד בזמן שאתה מוצא התאמה בין המוצר לשוק. עבור פרסום שמקבל פסגות בלתי צפויות, זה מסוכן אלא אם כן אתה מבצע קשור אגרסיבי ומרנדר מראש. עבור כל דבר שפולט קבצים גדולים, זה הכלי השגוי ביום ההשקה.
עץ ההחלטות שלי הוא בוטה. אם זמן התגובה הדינמי שלך ב-p95 נמוך ונשאר נמוך תחת לחץ קל, אתה יכול לרכוב על תוכנית משותפת יותר זמן ממה שאתה חושב. אם שיעור הפגיעה ב-CDN שלך באמת גבוה והיציאה מהמקור נשארת שטוחה כאשר התעבורה מכפילה, אתה מספיק בטוח. אם אחת מהתנאים הללו לא מתקיימת, תכנן את המעבר עכשיו. VPS קטן עם שני vCPUs וזיכרון מספיק כדי להימנע מהחלפה הוא משעמם ואמין. זה נותן לך חיזוי במשימות מקבילות, ביצועי אחסון טובים יותר, ונתיב רשת שאתה יכול להבין בפועל. אתה עדיין יכול להשתמש באותה אסטרטגיית CDN ואחסון אובייקטים. כאשר אתה גדל מעבר לכך, תרגיש את זה בדרכים שתוכל למדוד ולתכנן סביבן, ותעבור לקלסטרים ייעודיים או מנוהלים כי אתה בוחר בכך, לא כי סעיף בתנאי השירות הכריח אותך.
נתיב ההגירה לא צריך להיות דרמטי. שמור על המקור שלך חסר מצב ככל האפשר כדי שההעברות DNS יהיו נקיות. שמור את הסשנים בבסיס משותף שתוכל להצביע אליו גם מהמקור הישן וגם מהחדש במהלך חפיפה קצרה. חמם את הקשורים לפני שאתה הופך את המתג כדי שהמקור החדש לא ייקח את כל המכה. הנקודה היא לא להיות מושלם; היא להיות חיזוי. "ללא הגבלה" מאכזב אותך בצורה בלתי צפויה. המטרה שלך היא להפסיק להיות מופתע.
הבטחתי תרחישים מעשיים, חיים כי כך הקצוות של הנושא הזה נעשים ברורים. החלק הבא הוא חלק פרימיום עם שלושה סיפורי עולם אמיתיים, שכל אחד מהם מתחיל ב"ללא הגבלה", כל אחד מהם פוגע בקיר שונה, והשינויים המדויקים שיצבו אותם.
Premium content
התחבר כדי להמשיך
העמדה שלי, בבוטות: זה ללא מדידה, לא בלתי מוגבל — התייחסו לזה כך
אני לא מתנגד ל"רוחב פס בלתי מוגבל" כל עוד אנחנו מסכימים שזה אומר "לא נספור בתים" ולא יותר מזה. זה ללא מדידה, לא אינסופי. הבקרות שמעצבות את החוויה שלכם נמצאות בחלוקת CPU, גבולות I/O, מגבלות תהליך, תקרות תחרות וצבירת פורטים זמניים כשאתם נעשים עסוקים. אם תתכננו כמו מבוגרים—CDN מקדימה, העברת נכסים, צמצום עבודה דינמית ומהירות—תוכלו לחיות באושר בתוכנית שמשווקת כ"בלתי מוגבל" כי לעיתים נדירות תצטרכו לבדוק זאת. אם תתכננו כאילו קניתם נתיב ייחודי, תלמדו את המשמעות של "שימוש הוגן" בפעם הראשונה שמישהו יעניין באתר שלכם.
כך אני פועל. אני מתייחס למקור כמו API קטן שמגיע לו כבוד. אני מעביר בתים כבדים למקומות שנבנו לשחרור, ואני משלם על השחרור כי זו עלות הסקלה. אני עוקב אחרי p95, לא ממוצעים. אני שומר עין אחת על תחרות ועין שנייה על הזנב הארוך של זמני הבקשות. אני קורא את ה-ToS כאילו זה מסמך טכני ומתרגם כל יופמיזם למספר. אני מקבל ששרת משותף הוא סביבה מרובת משתמשים עם הצעת ערך מבריקה לאתרים קטנים ומגבלות קשות לכל דבר שאפתני. כששאפתנות מגיעה, אני עובר כי אני בוחר בכך, לא בגלל סעיף קטיפה שאומר לי שאני חייב.
אם נשרפתם מ"בלתי מוגבל", אל תכעסו על עצמכם. הניסוח נועד להיות מרגיע, וזה עובד. בנו את המקור הקטן והעמיד. שימו CDN מקדימה. העבירו את הדברים הכבדים. דעו את המספרים ואת נקודות החסימה שלכם. כשיגיע היום שתצטרכו VPS או משהו גדול יותר, עשו את המעבר עם זיכרון מטמון חם וראש צונן. לעולם לא תסתכלו על "רוחב פס בלתי מוגבל" באותה צורה שוב, וזה הנקודה. זו לא הייתה הבטחה. זו הייתה הזמנה לעשות את העבודה הנכונה.