לא נעים לראות אתר סגור

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

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

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

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

אז מה עושים

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

  1. הקטנת קריאות של PHP
  2. שימוש ב Htaccess
  3. טיפול במסד הנתונים
  4. קאשינג
  5. אוטומציה של תהליכים
  6. אופטימיזציה של תוכן

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

שלב ראשון – התמודדות עם משבר.

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

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

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

הערה: לצורך הדיון והדוגמאות אני אניח שאנחנו נמצאים בספריה בשם web הבלוג הישן יושב בתיקיה dis-blog והחדש יושב בתיקיה wordpress (בתיקיה blog יושב עמוד ה HTML שהכנו).

לאחר יצירת ההתקנה הנקיה נתחיל בהעתקה של הקבצים החשובים – wp-config.php, קבצי ערכת העיצוב וספרית העלאות המדיה.

cp -a web/dis-blog/wp-config.php web/wordpress/wp-config.php
cp -a web/dis-blog/wp-content/uploads web/wordpress/wp-content/uploads
cp -a web/dis-blog/wp-content/themes/yourthemename web/wordpress/wp-content/ themes/yourthemename

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

כעת ניצור תת מתחם חדש (כל אחד לפי הוראות הספק שלו) – אם הבלוג ישב קודם ב blog.com ניצור משהו בסיגנון test.blog.com ונפנה לספריה החדשה. בגלל שהעתקנו את wp-config החיבור למסד הנתונים צריך לעבוד ברגע שנתחבר אל הדומיין החדש, אך בגלל שלא שינינו את הכתובת של הבלוג במסד הנתונים, חלק מהתכנים (תמונות, קבצי CSS וכ') עלולים שלא להופיע. לצורך כך יש להתחבר אל מסד הנתונים (דרך phpmyadmin או כל כלי מועדף אחר) ולמצוא את האפשרות שנקראת siteurl

SELECT * FROM wp_options where option_name="siteurl"

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

סוף ההתחלה

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

לדרג את הפוסט
0

Comments

12 תגובות על “לא נעים לראות אתר סגור”

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

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

  2. בלי להתייחס לשאר התוכן החשוב ובדקדקנות מעצבנת, עד כמה שאני מבין cp -arp מקביל ל cp -a ולא צריך להוסיף את השאר שהרי לפי man cp הדגל a הוא קיצור לפקודה cp -dpR.

    1. צודק, תוקן

  3. תמונת פרופיל של vaiden
    vaiden

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

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

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

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

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

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

    1. במקרה הספציפי הזה – משהו כמו 600 כניסות לפוסט הספציפי באותו היום – אבל כשיש לך מעל לתריסר תוספים פעילים ופונקציות לא יעילות – זה משמעותי.

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

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

  7. וורדפרס עודכן שוב מאז, עד כמה שאני יודעת.

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *