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

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

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

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

אז מה עושים

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

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