מה זה Load Testing לAPI¶
ה-API עובד מצוין כשאתם בודקים אותו לבד, בקשה אחת בכל פעם. אבל מה קורה כשאלף משתמשים שולחים בקשות בו זמנית? אולי הכל ימשיך לעבוד חלק, ואולי השרת יקרוס, זמני התגובה יזנקו, או מסד הנתונים יתחיל לזרוק שגיאות. הדרך היחידה לדעת מראש, לפני שזה קורה למשתמשים אמיתיים, היא load testing.
אז מה זה בעצם Load Testing¶
בדיקת עומס היא תהליך שבו מדמים תעבורה מציאותית מול ה-API - הרבה בקשות בו זמנית, בדפוס שדומה לאיך שמשתמשים אמיתיים היו משתמשים במערכת - ובודקים איך המערכת מתמודדת. במקום לחכות שהעומס יגיע בפועל ולגלות בעיות בדיעבד, מייצרים אותו בכוונה בסביבת בדיקה, ומודדים את התוצאות.
המדדים המרכזיים שבודקים הם זמן תגובה (כמה זמן לוקח לכל בקשה לקבל תשובה), throughput (כמה בקשות המערכת מצליחה לעבד בשנייה), ואחוז השגיאות (כמה בקשות נכשלות תחת העומס). מדדים אלה יחד נותנים תמונה ברורה - האם המערכת מתמודדת עם העומס בצורה יציבה, או שהיא מתחילה להישבר בנקודה מסוימת.
סוגי בדיקות שונים לשאלות שונות¶
לא כל בדיקת עומס בודקת את אותו הדבר. בדיקת עומס רגילה (load test) בודקת איך המערכת מתפקדת תחת עומס צפוי - למשל, הכמות המקסימלית של משתמשים שאתם מצפים בשעות עומס רגילות.
בדיקת קיצון (stress test) הולכת מעבר לעומס הצפוי, ומעלה את התעבורה בהדרגה עד שהמערכת נשברת, כדי לגלות איפה בדיוק נקודת הכשל, ואיך המערכת מתנהגת כשהיא נכשלת - האם היא נופלת בצורה מבוקרת, או קורסת לגמרי.
בדיקת פרץ (spike test) בודקת מה קורה כשהעומס קופץ פתאום, מבלי עלייה הדרגתית - למשל כשקישור לאתר שלכם מתפרסם ברשת חברתית וכל התנועה מגיעה תוך דקות ספורות. זה בודק לא רק אם המערכת שורדת, אלא גם כמה מהר היא מתאוששת אחרי שהעומס יורד בחזרה.
מה בדרך כלל נשבר ראשון¶
בניסיון של רוב הצוותים, מסד הנתונים הוא בדרך כלל הצוואר בקבוק הראשון שמתגלה - חיבורים שנתקעים בתור, שאילתות שהופכות איטיות תחת עומס, ונעילות בטבלאות שמתחילות להתנגש. אחריו, לרוב מתגלות בעיות בניהול חיבורים לשירותים חיצוניים, וזיכרון שאוזל בגלל אובייקטים שלא משתחררים כמו שצריך. בדיקת עומס טובה לא רק אומרת "המערכת נשברה", היא עוזרת לזהות בדיוק איפה, וזה מה שהופך אותה משלב פורמלי בתהליך לכלי אבחון אמיתי.
כלים נפוצים לביצוע בדיקות עומס¶
יש כמה כלים מוכרים בתחום. k6 הוא כלי מודרני שמאפשר לכתוב תסריטי בדיקה בקוד JavaScript, ומתאים לשילוב בתהליכי CI-CD. JMeter הוא כלי ותיק ועשיר ביכולות עם ממשק גרפי. Locust מאפשר לכתוב את התסריטים בפייתון ומתאים למי שכבר עובד בסביבה הזאת. הבחירה בין הכלים תלויה בעיקר בנוחות ובשפה שהצוות כבר מכיר, כי כולם פותרים בעיקרון את אותה בעיה.
מתי כדאי להריץ בדיקת עומס¶
בדיקת עומס לא צריכה לקרות רק פעם אחת לפני השקה. שינויים במערכת - endpoint חדש, שאילתה חדשה, תלות חיצונית חדשה - יכולים לשנות איך המערכת מתנהגת תחת עומס. צוותים בשלים מריצים בדיקות עומס באופן קבוע, ולעתים גם משלבים אותן בתהליך ה-CI-CD, כדי לתפוס נסיגה בביצועים לפני שהיא מגיעה לייצור, ולא אחרי שהמשתמשים כבר הרגישו אותה.
איך לומדים לבצע בדיקות עומס נכון¶
הבנת המושגים היא התחלה, אבל לדעת לתכנן תרחיש בדיקה מציאותי, לפרש נכון את התוצאות, ולזהות את הצוואר בקבוק האמיתי - זה נלמד רק על מערכת אמיתית. בקורס צד-שרת לומדים לבנות מערכות שעומדות בעומס, ומבינים איך לבדוק את זה נכון לפני שמשתמשים אמיתיים עושים את זה בשבילכם.
עברתם בדיקת עומס וגיליתם שמשהו נשבר בצורה מפתיעה? זה בדיוק סוג הדיון שקורה בדיסקורד שלנו.
לסיכום¶
בדיקת עומס היא הדרך היחידה לדעת מראש איך ה-API שלכם יתנהג תחת תעבורה אמיתית, במקום לגלות את זה מלקוחות כועסים בייצור. בין אם זו בדיקת עומס רגילה, בדיקת קיצון שמוצאת את נקודת השבירה, או בדיקת פרץ שבודקת התאוששות - המטרה זהה, לתפוס בעיות ביצועים לפני שהן הופכות לתקלה אמיתית.