מדובר ב-2 מושגים, די דומים במהותם, שיוצא לנו להתקל בהם במועדים שונים.

בניגוד לאנגלית (bandwidth), בעברית יש 2 מונחים למילה. זה לא שחברות אחסון בחו"ל לא עושות את ההבדלה – הן עושות, אבל שם ההבדלה היא בין Monthly bandwidth לבין Metred/Unmetred bandwidth.

בפועל לא מדובר בנתון שאנחנו יכולים "לבחור", אלה נתון שמתייחס לסוג האחסון (שיתופי או יעודי) איתו אנו עובדים.

תעבורה

תעבורה היא מושג עתיק מעולם אחסון האתרים השיתופי, שמהותה למדוד את כמות העומס שמשתמש מסויים יוצר על השרת ובהתאם לכך – לחייב אותו.

אם מסתכלים על חבילות האירוח של חברות אחסון שונות, אכן ניתן לראות שעדין מתייחסים לנושא זה בתמכור (חבילה עם 30GB תעבורה חודשית תעלה יותר מחבילה הכוללת 20GB תעבורה חודשית בלבד).

ערכי המדידה הם ב-GB, לחודש.

מה אומרת השיטה?

נחזור כמה צעדים לאחור:
בכל פעם שאנחנו גולשים לאתר אנחנו למעשה מורידים את ה-html ורכיבים שונים (css, javascript ותמונות) אלינו למחשב.
לכל רכיב כזה יש משקל (לדוגמא: הגודל של תמונה ספציפית).

השיטה בעצם אומרת שככול שיותר גולשים מורידים יותר אובייקטים, הם בעצם מייצרים יותר עומס על השרת (מה שיכול עקרונית להשמע הגיוני, אתר עם 1000 מבקרים בשעה כנראה "מעמיס" יותר מאתר עם מבקר אחד בשעה) – מה שאומר, שאם נמדוד את כמות המידע שהורדה מכל אתר (כמות האלמנטים שהורדו X גודל האלמנטים) נוכל לקבוע, פחות או יותר, מי מהאתרים מעמיס יותר ומי מעמיס פחות.

הקשר בין השיטה למדדים טכנולוגיים הוא מקרי בהחלט, בעיקר כי ייתכנו לא מעט מצבים הפוכים, לדוגמא:

כפי שהסברתי במאמר הזה, ייתכן מצב שבו אתר עם מעט מאוד גולשים מייצר הרבה מאוד עומס על השרת.
אתר המציע להורדה סרטון וידאו (במשקל 500 מגה), כאשר גולש אחד יוריד את הסרטון, הוא "ינצל" 500 מגה ממכסת התעבורה שלו, דבר שהוא כלל לא פרופורציונלי לכמות העומס שהבקשה שלו גרמה לשרת (עומס אפסי כמעט).
אתר עם אלפי גולשים בשעה, אבל מכיוון שהוא לא מכיל כמעט תמונות ועובד עם HTML "רזה" מאוד, הדבר לא מתבטא בכמות המידע שהגולשים "מושכים" מהשרת.

מכשיר למדידת תעבורה

אם נרצה לתת "תאור גרפי" לרעיון, הצורה הפשוטה ביותר לדמות זאת היא באמצעות שעון מים.

תחשבו על צינור שעוברים בתוכו מים, במקביל, ישנו שעון המודד את כמות המים שעברו בשעון.
מעבר לכך, תחשבו שהשעון יודע לעצור את זרימת המים ברגע שחציתם את "חבילת השימוש במים" שרכשתם מספק המים שלכם.

אם השיטה כל כך לא טובה, למה השתמשו בה עד היום?

ובכך, התשובה מעט מביכה- פשוט כי טכנולוגית לא היה פתרון אחר.

היום לשמחתנו, הנושא שונה לחלוטין, ויש פתרונות טכנולוגים (דוגמאת CloudLinux) המאפשרים הגבלה מדוייקת יותר של המשאבים PER לקוח גם בשרת שיתופי.

איך בעצם השיטה עובדת?

התעבורה נמדדת באופן מצטבר חודשי.

כלומר, פעם ביום (סביבות השעה 12 בלילה) מתבצע בשרת חישוב של כמות התעבורה שמשתמש ספציפי ניצל באותו היום, ובסוף החודש, הספירה מתאפסת ומתחילים את הספירה מחדש.

מה סופרים? הכול, הספירה מתבצעת ע"י סכימה של כלל הערכים בקבצים הבאים:

Apache: לוג ה-Bytes של ה-Apache (מדובר בקובץ הקיים בכלל ממשקי הניהול המסחריים, ומכיל בעצם את גודל הבקשה שבוצעה ע"י הגולש – זאת בניגוד ללוגים אחרים המכילים גם מידע אותו כתובות הIP, אילו עמודים הגולשים ביקש, Referrer וכו').
FTP: בלוג ה-FTP מופיע מהו המשקל של כל קובץ שהועלה / הורד – גם מידע זה נספר.
ממשק ניהול: מכיוון שהעלאה או הורדה של קבצים יכולה להתבצע גם באמצעות ממשק הניהול, גם נתון זה נספר.

במילים אחרות, כל תנועה שלכם מול השרת נספרת.

מה קורה אם אני חורג מהמגבלה?

זה מאוד תלוי בחברת האחסון איתה אתה עובד ובמדיניות שלה בנושא.

חלק מהחברות יסגרו את החשבון באופן אוטומטי ברגע שחציתם את המגבלה, החלק האחראי יותר של אותה חברות ידאג לעדכן אתכם (לרוב במייל) לפני ביצוע פעולה יזומה שכזו.

החלק השני של החברות פשוט יתריע לכם על הנושא ויבקש מכם להגדיל את חבילת האחסון השיתופי שלכם בהתאם.

בכלליות, מכיוון שמדובר בשיטה שבעצם לא מודדת שום דבר יעיל ומכיוון שישנם פתרונות טכניים אחרים למדידת העומס – דרשו מחברת האחסון שלכם להוריד את מגבלת התעבורה.

רוחב פס

המונח רוחב פס לעומת זאת מסתכל על הדברים קצת אחרת.

רוחב פס

זוכרים את השעון עליו דיברנו קודם? תחשוב שהשעון הזה לא קיים עכשיו, יש רק צינור וברז.
כלומר, אנחנו לא מודדים את כמות המים שעוברת (כי זה לא מעניין אותנו, אסביר בהמשך), אבל אנחנו כן מודדים מהי כמות המים המקסימלית שיכולה לעבור בזמן נתון (תלוי ברוחב הצינור, והאם הברז פתוח).

וזאת בדומה מאוד לספק האינטרנט שלנו – החבילות הנמדדות מציינות את מהירות ההורדה המקסימלית בו"ז (למשל: חבילת ה-100 מגה [ביט] מציינת כי זו מהירות ההורדה המקסימלית שלנו בזמן נתון) – את ספקית האינטרנט לא מעניין כמה הורדנו (טוב, לפחות הן לא מציינות זאת בפנינו) במהלך החודש, אלה רק מה אנחנו עושים ברגע נתון.

וחזרה לעולם אחסון האתרים.

בעולם אחסון האתרים המונח רוחב פס משמש לרוב בשרתים יעודיים (למרות שקיים גם בשרתים שיתופיים, אבל לרוב נתון זה לא חשוף ללקוח), ובתוך עולם זה מתחלק ל-2:

Unmetred bandwidth:
בשיטה זו אתם רוכשים רוחב פס מסויים במסגרת חוזה השרת היעודי שלכם (נגיד, 10Mbit) ואינכם מוגבלים לכמות התעבורה המועברת.
במילים אחרות, מבחינת הספק שלנו, אין לו בעיה שנוריד ב-100% מהזמן בחודש ב-100% מרוחב הפס שלנו.
אם נחשב מתמטית, זה עקרונית שווה ל-10mbit (מגה ביט לשניה) X מספר השניות בחודש (2592000) = 2592000 (מגה) = 25 טרה תעבורה בחודש.
לטעמי, השיטה ההוגנת ביותר (וכנראה שלא רק אני חושב כך, שיטה זו היא גם המקובלת ביותר בישראל).
Metered bandwidth:
השיטה השניה, בה משתמשים חברות מעטות יחסית בתחום אחסון האתרים (וכל החברות בתחום הסלולר) אומרת משהו אחר:
אני אגביל אותך גם ברוחב הפס שאתה מקבל, וגם בתעבורה שאתה יכול להעביר ברוחב הפס שלך מידי חודש.
במילים אחרות, אם נחזור לדוגמה הגרפית – קיבלנו גם את הצינור, וגם את הברז (תרתי משמע, סליחה על הבוטות).כלומר, מדובר בערבוב כלשהו בין שיטת רוחב הפס לשיטת התעבורה.

ההמלצה האישית שלי היא לדחוף את הספק שלכם לעבוד בשיטה של UNMetered bandwidth ולהיות עם ראש שקט (ובלי הפתעות של "תשלומי חריגה" בסוף החודש).

סימטריות מול א-סימטריות

הנושא מוכר בעיקר מהאינטרנט הביתי שלנו, קצב ההעלאה שונה לחלוטין מקצב ההורדה.

לדוגמא (ואני לא חושב שאני מחדש למישהו), באחד המבצעים של ספקיות האינטרנט המוכרות מציעים 100mbit – נהדר לא? מתברר שה-100mbit הוא לא בדיוק 100mbit, אלה יותר "100mbit יורד, ו-10mbit עולה, אבל רגע – לא במקביל").

כלומר, לא רק שרוחב הפס שלנו הוא לא באמת כפי שמתפרסם, גם אנחנו לא באמת יכולים להשתמש בו באופן שכן מתפרסם.

המצב הזה, לצערי, קיים גם בעולם אחסון האתרים – ואם בעולם ספקיות האינטרנט ניתן לתת לו מעט לגיטימיות (כי אם היינו משתמשים באינטרנט רק בתצורה שספקיות האינטרנט היו רוצות, באמת שכמעט ולא היה לנו שימוש ב-Upload), בעולם אחסון האתרים הוא כלל לא לגיטימי.

הנתון החשוב בעולם אחסון האתרים הוא דווקא ה-upload וזאת מכיוון שמדובר בתמונת מראה למשתמש – אם המשתמש מוריד את המידע, סימן שמישהו (ובמקרה הזה, שרת האחסון) צריך להעלות את המידע אליו.
יחד עם זאת ובמיוחד לאור כך שמהירויות ה-upload הבייתיות עולות, עולה גם החשיבות של מהירות ה-download של השרת (שוב, תמונת מראש).

אני אולי ארחיב בעניין בפוסט נפרד, אבל על מנת לסכם את הנושא בפוסט זה – אל תלכו על עסקה בה רוחב הפס המוצע לכם הוא אינו סימטרי – אין בזה הגיון, מדובר ב"טריק תמחורי" ותו לא.

Best Effort

מונח זניח, שכמעט ונעלם מהעולם, אבל עדין יש חברות שמרשות לעצמם לעבוד בצורה הזו (בעיקר מכיוון שמדובר ב"אותיות קטנות" בחוזים – או מונח שרוב האנשים לא יודע לפענח).

נסביר בדוגמא: תחשבו שאתם עובדים מול חברת הכבלים שלכם וקניתם חבילת ערוצים מסויימת, חברת הכבלים שלכם נותנת לכם את תנאי האספקה הבאים: "תראה, אני אשתדל מאוד שרוב הזמן השירות יעבוד, אבל במקרה ובו 2 שכנים שלך בבנין יסתכלו באותו הזמן בערוץ הספורט, יש סיכוי שלא תוכל לצפות במקביל אליהם וכל פעם שיש גול השידור יפסק" – האם תחתמו על חוזה שכזה? סביר להניח שלא.

וזה גם הרעיון ברוחב הפס, Best Effort היא שיטה שאומרת (לדוגמא): "אני כחברת אחסון נותן לך 1000mbit רוחב פס, אתה יכול להשתמש ב-100% מרוחב הפס הזה במשך 100% מהזמן בחודש, אבל האמת? כמו שמכרתי לך מכרתי גם לעוד 1000 איש במקביל, מה שאומר שאני לא בטוח אעמוד בהתחייבות שלי, אבל אני מבטיח לעשות את המקסימום על מנת לעמוד בהתחייבות"

מן הסתם, מדובר בהתחייבות ריקה מתוכן, וסביר להניח – שגם אם הכול יעבוד תקין במשך תקופה מסויימת (בכל זאת, לוקח זמן למכור את המוצר ל-1000 איש נוספים), תבוא תקופה שבה דברים יעבדו בצורה מאוד לא תקינה.

מכיוון שרוחב פס הוא דבר קריטי לעיתים (לדוגמא: יש לכם קמפיין בYNET), חשוב לוודא כי אתם יכולים לקבל 100% מהמוצר שקניתם ב-100% מהזמן.

About
Latest Posts

מנהל מערכת

חלק מחברת SPD Hosting החל משנת 2006.
כחלק מהתפקידים שלי בחברה, אני אחראי על תוכניות ההכשרה של עובדים חדשים.
חי ונושם Hosting, קוד פתוח ו-Linux (ויש גם מילה טובה ל-Windows)

Latest posts by מנהל מערכת (see all)