איך לזהות צוואר בקבוק בשרת, לתקן אותו במהירות, לשפר את ביצועי השרת ולמנוע רגרסיות.
סקירה כללית
במדריך הזה נסביר איך לפתור בעיה של עומס יתר בשרת ב-4 שלבים:
- הערכה: זיהוי צוואר הבקבוק של השרת.
- ייצוב: הטמעת תיקונים מהירים כדי לצמצם את ההשפעה.
- שיפור: הגדלה וביצוע אופטימיזציה של יכולות השרת.
- מעקב: משתמשים בכלים אוטומטיים כדי למנוע בעיות בעתיד.
הערכה
כשהתנועה יוצרת עומס יתר על השרת, אחד או יותר מהגורמים הבאים יכולים להפוך לצוואר בקבוק: מעבד (CPU), רשת, זיכרון או קלט/פלט (I/O) של דיסק. אם תזהו איזה מהגורמים האלה הוא צוואר הבקבוק, תוכלו להתמקד בפתרונות שהכי משפיעים.
- מעבד (CPU): אם השימוש במעבד הוא באופן עקבי מעל 80%, צריך לבדוק את הבעיה ולתקן אותה. ביצועי השרת בדרך כלל יורדים כשהשימוש ב-CPU מגיע ל-80-90%, והירידה בביצועים בולטת יותר ככל שהשימוש מתקרב ל-100%. ניצול המעבד (CPU) של הצגת בקשה אחת הוא זניח, אבל ביצוע הפעולה הזו בקנה מידה שנתקלים בו במהלך עליות חדות בתנועה יכול לפעמים להעמיס על השרת. כדי להפחית את ניצול המעבד (CPU), אפשר להעביר את העיבוד לתשתית אחרת, לצמצם פעולות יקרות ולהגביל את כמות הבקשות.
- רשת: בתקופות של תנועה גבוהה, קצב העברת הנתונים ברשת שנדרש כדי למלא את בקשות המשתמשים יכול לחרוג מהקיבולת. באתרים מסוימים, בהתאם לספק האירוח, יכולות להיות גם מגבלות על העברת נתונים מצטברת. כדי להסיר את צוואר הבקבוק הזה, צריך להקטין את הגודל והכמות של הנתונים שמועברים אל השרת וממנו.
- זיכרון: כשאין למערכת מספיק זיכרון, צריך להעביר נתונים לדיסק לאחסון. הגישה לדיסק איטית בהרבה מהגישה לזיכרון, וזה יכול להאט את כל האפליקציה. אם הזיכרון נגמר לגמרי, יכולות להופיע שגיאות נגמר הזיכרון (OOM). כדי להסיר את צוואר הבקבוק הזה, אפשר לשנות את הקצאת הזיכרון, לתקן דליפות זיכרון ולשדרג את הזיכרון.
- קלט/פלט של דיסק: הקצב שבו אפשר לקרוא נתונים מהדיסק או לכתוב אליו מוגבל על ידי הדיסק עצמו. אם הקלט/פלט של הדיסק הוא צוואר בקבוק, הגדלת כמות הנתונים שנשמרים במטמון בזיכרון יכולה להקל על הבעיה הזו (על חשבון ניצול מוגבר של הזיכרון). אם זה לא עובד, יכול להיות שתצטרכו לשדרג את הדיסקים.
השיטות במדריך הזה מתמקדות בטיפול בצווארי בקבוק במעבד (CPU) וברשת. ברוב האתרים, המעבד והרשת יהיו צווארי הבקבוק הרלוונטיים ביותר במהלך עלייה חדה בתנועה.
הפעלת top בשרת המושפע היא נקודת התחלה טובה לבדיקת צווארי בקבוק. אם יש לכם נתונים היסטוריים מספק האירוח או מכלי המעקב, כדאי להוסיף אותם.
ייצוב
שרת עמוס מדי יכול להוביל במהירות לכשלים משורשרים במקומות אחרים במערכת. לכן, חשוב לייצב את השרת לפני שמנסים לבצע שינויים משמעותיים יותר.
הגבלת קצב של יצירת בקשות
הגבלת קצב של יצירת בקשות מגינה על התשתית על ידי הגבלת מספר הבקשות הנכנסות. זה חשוב במיוחד כשהביצועים של השרת יורדים: ככל שזמני התגובה מתארכים, המשתמשים נוטים לרענן את הדף באופן אגרסיבי, מה שמגביר עוד יותר את העומס על השרת.
תיקון
למרות שדחיית בקשה היא פעולה זולה יחסית, הדרך הטובה ביותר להגן על השרת היא לטפל בהגבלת הקצב של יצירת הבקשות במקום כלשהו במעלה הזרם – למשל, באמצעות מאזן עומסים, שרת proxy הפוך או CDN.
הוראות:
קריאה נוספת:
שמירה במטמון של HTTP
חפשו דרכים לשמור תוכן במטמון באופן אגרסיבי יותר. אם אפשר להציג משאב ממטמון HTTP (בין אם זה המטמון של הדפדפן או CDN), אין צורך לבקש אותו משרת המקור, וכך העומס על השרת פוחת.
כותרות HTTP כמו Cache-Control, Expires ו-ETag מציינות איך לשמור משאב במטמון HTTP. בדיקה ותיקון של הכותרות האלה ישפרו את השמירה במטמון.
אפשר להשתמש גם בקובצי שירות (service workers) לשמירה במטמון, אבל הם משתמשים במטמון נפרד והם תוספת לשמירה תקינה במטמון של HTTP, ולא תחליף לה. לכן, כשמטפלים בשרת עמוס, צריך להתמקד באופטימיזציה של שמירת HTTP במטמון.
אבחון
מריצים את Lighthouse ומסתכלים על הביקורת הצגת נכסים סטטיים עם מדיניות מטמון יעילה כדי לראות רשימה של משאבים עם זמן חיים (TTL) קצר עד בינוני. לכל משאב שמופיע ברשימה, כדאי לבדוק אם צריך להגדיל את ה-TTL. ככלל אצבע:
- משאבים סטטיים צריכים להישמר במטמון עם TTL ארוך (שנה אחת).
- משאבים דינמיים צריכים להישמר במטמון עם TTL קצר (3 שעות).
תיקון
מגדירים את ההוראה max-age של הכותרת Cache-Control למספר השניות המתאים.
הוראות:
הפחתה חיננית (graceful degradation)
הפחתה חיננית (graceful degradation) היא אסטרטגיה של הפחתה זמנית של הפונקציונליות כדי להוריד עומס עודף מהמערכת. אפשר ליישם את הרעיון הזה בהרבה דרכים שונות: למשל, להציג דף טקסט סטטי במקום אפליקציה עם כל התכונות, להשבית את החיפוש או להחזיר פחות תוצאות חיפוש, או להשבית תכונות מסוימות שהן יקרות או לא חיוניות. חשוב להתמקד בהסרת פונקציות שאפשר להסיר בקלות ובבטחה, עם השפעה מינימלית על העסק.
שיפור
שימוש ברשת להעברת תוכן (CDN)
אפשר להעביר את הצגת הנכסים הסטטיים מהשרת שלכם לרשת להעברת תוכן (CDN), וכך להפחית את העומס.
התפקיד העיקרי של CDN הוא להעביר תוכן למשתמשים במהירות, באמצעות רשת גדולה של שרתים שנמצאים קרוב למשתמשים. עם זאת, רוב רשתות ה-CDN מציעות גם תכונות נוספות שקשורות לביצועים, כמו דחיסה, איזון עומסים ואופטימיזציה של מדיה.
הגדרת CDN
רשתות CDN נהנות מהיתרונות של קנה מידה, ולכן הפעלה של CDN משלכם היא לא תמיד הגיונית. הגדרה בסיסית של CDN היא מהירה יחסית (כ-30 דקות) וכוללת עדכון של רשומות ה-DNS כך שיפנו אל ה-CDN.
אופטימיזציה של השימוש ב-CDN
אבחון
מריצים את WebPageTest כדי לזהות משאבים שלא מוצגים מ-CDN (אבל צריכים להיות מוצגים ממנו). בדף התוצאות, לוחצים על הריבוע שמעל Effective use of CDN (שימוש יעיל ב-CDN) כדי לראות את רשימת המשאבים שצריך להציג מ-CDN.
תיקון
אם משאב לא נשמר במטמון על ידי ה-CDN, צריך לוודא שהתנאים הבאים מתקיימים:
- יש לו כותרת
Cache-Control: public. - יש לו כותרת
Cache-Control: s-maxage,Cache-Control: max-ageאוExpires. - יש לו
Content-Length,Content-RangeאוTransfer-Encoding header.
שינוי משאבי המחשוב
צריך להחליט בזהירות אם להגדיל את משאבי המחשוב. למרות שלעיתים קרובות צריך להרחיב את משאבי המחשוב, אם עושים את זה מוקדם מדי, זה יכול לגרום למורכבות מיותרת בארכיטקטורה ולעלויות כספיות.
אבחון
המהירות שבה מגיע בייט התגובה הראשון (TTFB) יכולה להיות סימן לכך שהשרת מתקרב לקיבולת שלו. המידע הזה מופיע בבדיקה Reduce server response times (TTFB) (צמצום זמני התגובה של השרת) ב-Lighthouse.
כדי לבדוק את הבעיה לעומק, השתמשו בכלי מעקב כדי להעריך את השימוש במעבד (CPU). אם השימוש הנוכחי או הצפוי ב-CPU חורג מ-80%, כדאי לשקול להגדיל את השרתים.
תיקון
הוספה של מאזן עומסים מאפשרת לפזר את התנועה בין כמה שרתים. מאזן עומסים נמצא לפני מאגר של שרתים ומנתב את התנועה לשרת המתאים. לספקי שירותי ענן יש מאזני עומסים משלהם (GCP, AWS, Azure), או שאתם יכולים להגדיר מאזן עומסים משלכם באמצעות HAProxy או NGINX. אחרי שמגדירים מאזן עומסים, אפשר להוסיף עוד שרתים.
בנוסף לאיזון עומסים, רוב ספקי שירותי הענן מציעים התאמה אוטומטית לעומס (GCP, AWS, Azure). התאמה אוטומטית לעומס פועלת בשילוב עם איזון עומסים – התאמה אוטומטית לעומס מגדילה ומקטינה באופן אוטומטי את משאבי המחשוב בהתאם לביקוש בזמן נתון. עם זאת, התאמה אוטומטית לעומס היא לא קסם – לוקח זמן עד שמופעים חדשים מתחילים לפעול, וצריך להגדיר אותם בצורה משמעותית. בגלל המורכבות הנוספת שכרוכה בהתאמה אוטומטית לעומס (automatic scaling), כדאי קודם לשקול הגדרה פשוטה יותר שמבוססת על מאזן עומסים (LB).
הפוך דחיסה לפעילה
צריך לדחוס משאבים שמבוססים על טקסט באמצעות gzip או brotli. Gzip יכול להקטין את גודל ההעברה של המשאבים האלה בכ-70%.
אבחון
כדי לזהות משאבים שצריך לדחוס, אפשר להשתמש בבדיקה Enable text compression (הפעלת דחיסת טקסט) של Lighthouse.
תיקון
כדי להפעיל דחיסה, צריך לעדכן את הגדרות השרת. הוראות:
אופטימיזציה של תמונות ומדיה
ברוב האתרים, התמונות מהוות את רוב גודל הקובץ. אופטימיזציה של התמונות יכולה להקטין את גודל האתר במהירות ובאופן משמעותי.
אבחון
ב-Lighthouse יש מגוון בדיקות שמסמנות אופטימיזציות פוטנציאליות של תמונות. אסטרטגיה אחרת היא להשתמש בכלי הפיתוח כדי לזהות את קובצי התמונות הגדולים ביותר – סביר להניח שהתמונות האלה יהיו מועמדות טובות לאופטימיזציה.
בדיקות רלוונטיות של Lighthouse:
- התאמת גודל התמונות
- עיכוב הטעינה של תמונות שלא מופיעות מיד במסך
- קידוד תמונות ביעילות
- הצגת תמונות בפורמטים מהדור הבא
- שימוש בפורמטים של וידאו לתוכן עם אנימציה
תהליך העבודה בכלי הפיתוח ל-Chrome:
- תיעוד הפעילות ברשת
- לוחצים על Img כדי לסנן משאבים שהם לא תמונות.
- לוחצים על העמודה גודל כדי למיין את קובצי התמונות לפי גודל.
תיקון
אם אין לכם הרבה זמן…
כדאי להקדיש זמן לזיהוי תמונות גדולות שנטענות לעיתים קרובות ולבצע אופטימיזציה ידנית שלהן באמצעות כלי כמו Squoosh. תמונות ראשיות (Hero) הן בדרך כלל מועמדות טובות לאופטימיזציה.
נקודות שכדאי לזכור:
- גודל: התמונות לא צריכות להיות גדולות יותר מהנדרש.
- דחיסה: באופן כללי, רמת איכות של 80-85 תשפיע באופן מינימלי על איכות התמונה, ותקטין את גודל הקובץ ב-30-40%.
- פורמט: השתמשו ב-JPEG לתמונות במקום ב-PNG, וב-MP4 לתוכן מונפש במקום ב-GIF.
אם יש לכם עוד זמן…
אם התמונות מהוות חלק משמעותי מהאתר, כדאי להגדיר CDN לתמונות. רשתות CDN לתמונות נועדו להצגה ולאופטימיזציה של תמונות, והן יורידו את העומס של הצגת התמונות משרת המקור. הגדרת CDN לתמונות היא פשוטה, אבל צריך לעדכן את כתובות ה-URL של התמונות הקיימות כך שיפנו ל-CDN לתמונות.
קריאה נוספת:
הקטנת הנפח של JS ו-CSS
הקטנה מסירה תווים מיותרים מ-JavaScript ומ-CSS.
אבחון
כדי לזהות משאבים שצריך להקטין את הנפח שלהם, אפשר להשתמש בבדיקות Minify CSS ו-Minify JavaScript של Lighthouse.
תיקון
אם אין לכם הרבה זמן, כדאי להתמקד בהקטנה של קובצי JavaScript. ברוב האתרים יש יותר JavaScript מאשר CSS, ולכן זה ישפיע יותר.
מעקב
כלים למעקב אחרי שרתים מספקים איסוף נתונים, לוחות בקרה והתראות לגבי ביצועי השרת. השימוש בהם יכול לעזור למנוע ולצמצם בעיות עתידיות בביצועי השרת.
הגדרת המעקב צריכה להיות פשוטה ככל האפשר. לאיסוף נתונים ולהתראות מוגזמים יש מחיר: ככל שההיקף או התדירות של איסוף הנתונים גדולים יותר, כך האיסוף והאחסון יקרים יותר. התראות מוגזמות מובילות בהכרח להתעלמות מדפים.
ההתראות צריכות להשתמש במדדים שמזהים בעיות באופן עקבי ומדויק. זמן התגובה של השרת (זמן אחזור) הוא מדד שמתאים במיוחד למטרה הזו: הוא מזהה מגוון רחב של בעיות וקשור ישירות לחוויית המשתמש. התראות שמבוססות על מדדים ברמה נמוכה יותר, כמו שימוש ב-CPU, יכולות להיות תוספת שימושית, אבל הן יתפסו קבוצת משנה קטנה יותר של בעיות. בנוסף, ההתראות צריכות להתבסס על הביצועים שנצפו בקצה (במילים אחרות, האחוזון ה-95 או ה-99), ולא על ממוצעים. אחרת, ממוצעים יכולים בקלות להסתיר בעיות שלא משפיעות על כל המשתמשים.
תיקון
כל ספקי שירותי הענן הגדולים מציעים כלי מעקב משלהם (GCP, AWS, Azure). בנוסף, Netdata היא חלופה מצוינת בקוד פתוח ובחינם. לא משנה באיזה כלי תבחרו, תצטרכו להתקין את סוכן המעקב של הכלי בכל שרת שתרצו לעקוב אחריו. בסיום, חשוב להגדיר התראות.
הוראות: