דף זה תורגם על ידי Cloud Translation API.

תיקון שרת עמוס

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

Katie Hempenius

סקירה כללית

במדריך הזה מוסבר איך לתקן שרת בעומס יתר ב-4 שלבים:

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

הערכה

כשעומסים תעבורת נתונים על שרת, הם עלולים להפוך לצוואר בקבוק: מעבד (CPU), רשת, זיכרון או קלט/פלט (I/O) בדיסק. אם תזהו מהו צוואר הבקבוק הזה, תוכלו למקד את המאמצים בטיפול במיטיגציות בעלות ההשפעה הרבה ביותר.

CPU: יש לבדוק ולתקן את השימוש במעבד (CPU) הגבוה מ-80% באופן עקבי. לרוב, ביצועי השרת יורדים ברגע שהשימוש במעבד (CPU) מגיע לכ-80-90%, ובולט יותר ככל שהצריכה מתקרבת ל-100%. הניצול של המעבד (CPU) למילוי בקשה יחידה הוא זניח, אבל ביצוע כזה בקנה מידה נרחב שבו נתקלים בעליות חדות בתעבורת נתונים יכול לפעמים להעמיס על השרת. הורדת השירות לתשתיות אחרות, צמצום הפעולות היקרות והגבלת כמות הבקשות יפחיתו את ניצול המעבד (CPU).
רשת: בתקופות של תנועה רבה, תפוקת הרשת הנדרשת למילוי בקשות משתמשים עשויה לחרוג מהקיבולת. אתרים מסוימים, בהתאם לספק האירוח, עשויים גם להגיע למכסות של העברת נתונים מצטברים. הקטנת הגודל והכמות של הנתונים שמועברים לשרת וממנו תסיר את צוואר הבקבוק הזה.
זיכרון: כאשר אין מספיק זיכרון במערכת, יש להוריד את הנתונים לדיסק לצורך אחסון. הגישה לדיסק איטית יותר באופן משמעותי מהזיכרון, והיא עלולה להאט את היישום כולו. אם הזיכרון מתמלא לגמרי, עלולות להיות לכך שגיאות של אין מספיק זיכרון (OOM). שינוי של הקצאת הזיכרון, תיקון דליפות זיכרון ושדרוג הזיכרון עשויים להסיר את צוואר הבקבוק הזה.
קלט/פלט של הדיסק: מוגבל על ידי הדיסק עצמו, שבו ניתן לקרוא או לכתוב נתונים מהדיסק. אם קלט/פלט (I/O) בדיסק הוא צוואר בקבוק, הגדלת כמות הנתונים במטמון בזיכרון יכולה לפתור את הבעיה הזו (בעלות שימוש מוגבר בזיכרון). אם הבעיה לא נפתרה, ייתכן שצריך לשדרג את הדיסקים.

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

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

ייצוב

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

הגבלת הקצב של יצירת הבקשות

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

תיקון

למרות שדחיית בקשה היא לא יקרה, הדרך הטובה ביותר להגן על השרת היא לטפל בהגבלת קצב של המקום במעלה הזרם - למשל באמצעות מאזן עומסים, שרת proxy הפוך או CDN.

הוראות:

קריאה נוספת:

שיטות וטכניקות להגבלת מחירים

שמירת HTTP במטמון

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

כותרות HTTP כמו Cache-Control, Expires ו-ETag מציינות איך משאב צריך להישמר במטמון באמצעות מטמון HTTP. הביקורת והתיקון של הכותרות האלה ישפרו את השמירה במטמון.

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

אבחון

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

משאבים סטטיים צריכים להישמר במטמון עם TTL ארוך (שנה אחת).
משאבים דינמיים צריכים להישמר במטמון עם TTL קצר (3 שעות).

תיקון

מגדירים את הוראת max-age של הכותרת Cache-Control למספר השניות המתאים.

הוראות:

ירידה חיננית

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

שיפור

שימוש ברשת להעברת תוכן (CDN)

ניתן להעביר נכסים סטטיים מהשרת לרשת להעברת תוכן (CDN), וכך להפחית את העומס.

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

הגדרת CDN

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

אופטימיזציה של השימוש ב-CDN

אבחון

כדי לזהות משאבים שלא מוצגים מ-CDN (אבל אמורים להיות מוצגים), מריצים את WebPageTest. בדף התוצאות, לחץ על הריבוע שמעל 'שימוש אפקטיבי ב-CDN' כדי לראות את רשימת המשאבים שיש להציג מ-CDN.

חץ שמצביע על הלחצן 'שימוש אפקטיבי ב-CDN' — תוצאות של WebPageTest

תיקון

אם משאב לא נשמר במטמון על ידי ה-CDN, צריך לבדוק שהתנאים הבאים מתקיימים:

יש בו כותרת Cache-Control: public.
יש לו כותרת Cache-Control: s-maxage, Cache-Control: max-age, או Expires.
יש בו Content-Length, Content-Range, או Transfer-Encoding header.

התאמה לעומס של משאבי המחשוב

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

אבחון

ערך גבוה של Time To First Byte (TTFB) יכול להיות סימן לכך שהשרת מתקרב לקיבולת שלו. המידע הזה מופיע בביקורת צמצום זמני התגובה של השרת (TTFB) של Lighthouse.

כדי לבצע חקירה לעומק, אפשר להשתמש בכלי מעקב כדי לבדוק את השימוש במעבד (CPU). אם השימוש הנוכחי או הצפוי במעבד (CPU) חורג מ-80%, כדאי להגדיל את השרתים.

תיקון

הוספת מאזן עומסים מאפשרת לחלק את התנועה בין שרתים מרובים. מאזן עומסים יושב מול מאגר שרתים ומנתב את התנועה לשרת המתאים. ספקי שירותי ענן מציעים מאזני עומסים משלהם (GCP, AWS, Azure) או להגדיר איזוני עומסים משלכם באמצעות HAProxy או NGINX. ברגע שמאזן העומסים מוגדר, ניתן להוסיף שרתים נוספים.

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

להפעיל דחיסה

משאבים מבוססי טקסט צריכים להיות דחוסים באמצעות gzip או brotli. Gzip יכול להקטין את גודל ההעברה של משאבים אלה בכ-70%.

אבחון

אפשר להשתמש בביקורת Enable text compression (הפעלת דחיסת טקסט) של Lighthouse כדי לזהות משאבים שצריך לדחוס.

תיקון

כדי להפעיל דחיסה, צריך לעדכן את הגדרות השרת. הוראות:

אופטימיזציה של תמונות ומדיה

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

אבחון

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

ביקורות רלוונטיות של Lighthouse:

תהליך עבודה של כלי פיתוח ל-Chrome:

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

תיקון

אם יש לכם זמן מוגבל...

תוכלו להתמקד בזיהוי תמונות גדולות שנטענות בתדירות גבוהה ולבצע אופטימיזציה שלהן באופן ידני באמצעות כלי כמו Squoosh. תמונות ראשיות הן בדרך כלל מועמדים טובים לאופטימיזציה.

מה כדאי לזכור:

גודל: הגודל של התמונות לא יכול להיות גדול מהנדרש.
דחיסה: באופן כללי, לרמת איכות של 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 היא חלופה מעולה בחינם בקוד פתוח. לא משנה באיזה כלי תבחרו, תצטרכו להתקין את סוכן המעקב של הכלי בכל שרת שאחריו תרצו לעקוב. בסיום התהליך, צריך להגדיר את ההתראות.

הוראות: