שיפור מהירות האתר – טכניקות מתקדמות לביצועי שיא

שוקי מן

5 שנים ago

פוסט זה הינו פוסט אורח שנכתב על ידי בן שריד, מפתח אתרים נלהב שאוהב לשחק עם קוד ותוכנה – בין אם ב-back-end או ב-front-end.

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

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

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

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

אז נכון, כולנו מכירים את הבסיס – כיווץ תמונות באמצעות תוסף או כלי מתאים, והורדת תוסף מטמון (caching) כלשהו.

אבל האם זה מספיק? אז זהו שממש לא.

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

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

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

בצורה כזו, כאשר אתם מקליקים בשורת הכתובת של הדפדפן lixfix.co.il אתם פונים לשרת מרוחק ומבקשים ממנו את הדף ששמור אצלו על כתובת הדומיין הזו. השרת שולח לכם את העמוד והדפדפן שלכם מציג אותו בצורה ויזואלית.

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

למה זה כל כך חשוב?

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

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

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

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

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

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

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

מה אתם הולכים ללמוד בפוסט

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

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

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

לפני שנתחיל, חשוב לי לציין שעל אף חשיבותה, אופטימיזציה לא יכולה להוות תחליף לחברת אחסון איכותית.

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

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

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

מוכנים? הנה אנחנו מתחילים

התחברות לשרת – דרישות בסיסיות

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

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

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

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

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

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

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

בנוסף, אני ממליץ על ביצוע בדיקות ביצועים לאתר שלכם דרך שירותים כמו GTmetrix או Sucuri Load Time Tester.

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

איך מתחברים לשרת ועובדים עם שורת הפקודה

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

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

במידה והמחשב האישי שלכם הוא מחשב Windows, כמוני, עליכם להוריד תוכנה המאפשרת התחברות ב-SSH. אני ממליץ על התוכנה PuTTY, אבל אם אתם עובדים ממחשב Mac או לינוקס, חסכתם לעצמכם הורדה. פשוט חפשו את ה-Terminal בכלי המערכת.

ל-PuTTY יש ממשק גרפי פשוט, בו תוכלו להזין את כתובת האתר ואת הפורט:

אין צורך לערוך את ההגדרות האחרות. לאחר הזנת הכתובת והפורט, לחצו Open.

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

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

אזין את שם המשתמש שלי, ולאחר מכן את הסיסמא:

אם הופיע שם המשתמש שלכם @ שם השרת, עם סימן ה-$ בסוף, סימן שהצלחתם להכנס בהצלחה.

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

כל פקודה שנכתוב מעכשיו תתחיל במילה sudo, קיצור של superuser do. בצורה זו נוכל להשתמש בהרשאות המתקדמות שלנו ולבצע את השינויים שאנחנו רוצים.

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

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

בקיצור, אם תשתמשו ב-sudo – הכל יעבוד. לסיום ההתחברות שלנו, נשאר לבדוק ש-Ngnix פועל. נכתוב:
sudo systemctl status nginx

ואכן, אפשר לראות שהוא active וירוק ושמח. אם לא מופיעה לכם שורת הפקודה עם ה-$ בסוף הפלט, לחצו על מקש q במקלדת.

זהו. עכשיו אתם מוכנים לעבודה האמיתית.

אופטימיזציה #1 – כיווץ gzip

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

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

gzip מאפשר לנו לצמצם באופן משמעותי את הגודל של קבצי json, css, javascript ועוד, ולחסוך עד מעל 60% מהגודל המקורי! מכיוון שאתרים מודרניים עם תוספים יכולים להכיל בקלות עשרות קבצי javascript, בהחלט יש לנו מה להרוויח.

שימו לב שלא נרצה לכווץ ב-gzip תמונות, שכן פורמטי תמונה ברשת כמעט ולא יושפעו מהכיווץ.

כדי לערוך את הגדרת כיווץ ה-gzip, יש להכנס לקובץ הקונפיגורציות הראשי של Nginx. כדי לעשות זאת נכתוב:
sudo nano /etc/nginx/nginx.conf

הקובץ יפתח לנו בעורך הטקסט nano, גרסת שורת הפקודה של לינוקס ל-Word. שמירת שינויים מתבצעת בעזרת ctrl+s, יציאה מהקובץ חזרה לשורת הפקודה בעזרת ctrl+x. דפדוף בעמוד מתבצע בעזרת מקשי החצים.

בצעו חיפוש להגדרות ה-gzip בעזרת ctrl+w. נכתוב gzip, ואז מקש אנטר.

כך נראו הגדרות ברירת המחדל שלי:

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

קיימות מספר קונפיגורציות הגדרה שונות, אך אני ממליץ על:

gzip on;

gzip_comp_level 1;
gzip_min_length 1000;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript application/json application/x-javascript application/xml;
gzip_disable "MSIE [1-6]\.";

gzip on;

gzip_comp_level 1;

gzip_min_length 1000;

gzip_proxied expired no-cache no-store private auth;

gzip_types text/plain text/css text/xml text/javascript application/json application/x-javascript application/xml;

gzip_disable "MSIE [1-6]\.";

בהגדרת gzip_comp_level, אנחנו מכוונים את הכיווץ ל-1, הרמה הנמוכה מתוך 9 רמות. הסיבה לכך היא שההבדל בין הרמה הגבוהה והנמוכה ביותר הוא לא משמעותי מאוד מבחינת התוצאה הסופית, אך ברמה 9 השרת שלכם יעבוד קשה יותר.

ההגדרות האחרות נועדו לקבוע גודל מינימלי לכיווץ, סוגי קבצים שיכווצו, והגדרה ספציפית על מנת שהשרת שלנו לא יבזבז זמן ויכווץ קבצים עבור דפדפני Internet Explorer 1-6.

למה? כי באופן מדהים אנשים עדיין משתמשים ב-IE6, והוא לא מתמודד טוב עם gzip.

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

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

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

נחזור לטרמינל, ונשמור את השינויים בקובץ ההגדרות בעזרת ctrl+s. נצא עם ctrl+x, ונבצע אתחול מחדש ל-Nginx באמצעות הפקודה:

sudo systemctl restart nginx

1	sudo systemctl restart nginx

אם לא קיבלתם הודעת שגיאה, הכל עבר בהצלחה. הודעות מקבלים רק כשמשהו רע קורה, אז תתרגלו להנות מהשקט.אני מציע לשחק קצת עם רמות הכיווץ של gzip, להריץ בדיקה חוזרת ב-GTmetrix, ולראות את התוצאות בלייב.

אופטימיזציה #2 – תהליכים וחיבורי worker

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

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

נתחיל בתהליכי worker, או בשמם הרשמי – worker_processes.

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

תהליך ה-worker הוא זה שדואג לעיבוד הבקשות שמגיעות לשרת. כשמבקר מקליד את שם האתר שלכם בשורת הכתובת, הוא מבקש לקבל מהשרת את העמוד המתאים. ה-worker הוא זה שמקבל את הבקשה, מעבד אותה, שולף או מייצר את העמוד, ושולח אותו חזרה.

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

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

Maximum visitors = (number of worker_processes)*(worker_connections)*0.5

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

ההגדרה של worker_processes (כברירת מחדל מדובר ב-auto, אוטומטי) תלויה בעיקר במספר ליבות העיבוד בשרת. אם אנחנו במצב רוח שמרני, נגדיר אותה לפי מספר הליבות פחות אחת. Nginx יודע להשתמש היטב בליבות עיבוד מרובות, וכך מתאפשר לו להקדיש ליבה אחת עבור תהליך ה-master, ואת שאר הליבות עבור תהליכי ה-worker.

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

כדי לבדוק את מספר הליבות בשרת שלכם, יש לכתוב בשורת הפקודה:

grep processor /proc/cpuinfo | wc -l

1	grep processor /proc/cpuinfo \| wc -l

הפלט יהיה מספר יחיד שמבטא את מספר הליבות. 1 במקרה שלנו:

במקרה שלי, ליבה אחת מובילה לכך שאגדיר worker_processes שווה ל-1.

להגדרה של worker_connections יש ברירת מחדל, והיא 768. מספר המקסימום המומלץ הוא 1024 – בערך 512 מבקרים לכל תהליך worker. באתרים מסויימים, בהם כל בקשה דורשת כוח עיבוד משמעותי מהשרת, יתכן שתרצו להקטין את מספר ה-worker_connections. עדיף לתת שירות טוב ומהיר לפחות אנשים משירות איטי וגרוע ליותר.

כדי להגדיר את worker_processes ו-worker_connections, נכנס לאותו קובץ הגדרות שערכנו בו את gzip באמצעות הפקודה:

sudo nano /etc/nginx/nginx.conf

1	sudo nano /etc/nginx/nginx.conf

נערוך את ההגדרות:

worker_processes 1;
worker_connections 1024;

1 2	worker_processes 1; worker_connections 1024;

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

נשמור את השינויים עם ctrl+s, ואז נצא מהקובץ עם ctrl+x, ונעשה ריסטרט ל-Nginx עם:

sudo systemctl restart nginx

1	sudo systemctl restart nginx

זהו, סיימתם.

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

אופטימיזציה #3 – באפרים

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

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

בשביל שרת VPS בסיסי, הגדרות באפר טובות עבור מידע מהמבקר אל השרת הן:

client_body_buffer_size 10k;
client_max_body_size 8m;

עבור מידע מהשרת אל המבקר:

client_header_buffer_size 1k;
large_client_header_buffers 2 1k;

נפתח שוב את קובץ ההגדרות שלנו:
sudo nano /etc/nginx/nginx.conf

ומתחת ל-Basic Settings נוסיף את ארבעת השורות (שלא מוגדרות כברירת מחדל).

וכרגיל, לשמור עם ctrl+s, לצאת מהקובץ עם ctrl+x, וריסטרט עם:
sudo systemctl restart nginx

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

שווה להצטייד בהגנה מתאימה, ולתת לשרת שלכם הרבה מרווח בטחון.
אופטימיזציה #4 – timeouts
הגדרת ה-timeouts באה לפתור בעיה נפוצה מאוד – מה עושים כשהשרת באמצע התקשרות עם מבקר, מנסה לשלוח לו עמוד באתר, אך ההתקשרות לפתע נפסקת. האם שומרים את ההתקשרות פתוחה ומחכים לו, ואם כן – עד מתי?

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

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

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

הזמנים מוגדרים בקובץ ההגדרות שכבר השתמשנו בו. נפתח אותו:
sudo nano /etc/nginx/nginx.conf

ונכניס תחת Basic Settings את השורות:

keepalive_timeout 16;
client_body_timeout 12;
client_header_timeout 12;
send_timeout 12;

כדאי להריץ חיפוש לערך timeout עם ctrl+w ולראות שאין כפילויות. כברירת מחדל, רק keepalive_timeout קיים בקובץ.

כשנסיים, ctrl+s לשמירה, ctrl+x ליציאה, וריסטרט:
sudo systemctl restart nginx

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

אופטימיזציה #5 – עדכון גרסת שרת

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

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

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

את השדרוג של חבילות התוכנה על הלינוקס שלכם ניתן לבצע דרך שורות הפקודה:
sudo apt-get update
sudo apt-get upgrade

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

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

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

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

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

אופטימיזציה #6 – שירות CDN

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

CDN, למי שלא מכיר את המושג, הוא ראשי תיבות של Content Delivery Network, או רשת שילוח תוכן. רשת כזו מורכבת משרתים רבים, ברחבי העולם, שתפקידם לתווך ביניכם לבין המבקרים שלכם.

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

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

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

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

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

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

אופטימיזציית צד שרת – פנים רבות לה

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

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

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

אופטימיזציה תמיד אפשר לעשות, בעוד שחברת אחסון הרבה יותר קשה להחליף.