אחת הבעיות הגדולות אשר אתרים גדולים צריכים להתמודד איתם היא תעבורה גבוהה. תעבורה גבוהה יכולה לגרום לנפילת האתר עקב כך שהתשתית עליו יושב האתר לא יודע להתמודד בצורה טובה עם הפיקים, או כאשר אין מימוש של Object Caching.
באחד המאמרים הקודמים, הסברתי על המגנון הכי קל למימוש, Page Caching, איתו ניתן להוריד בצורה משמעותית את העומס על משאבי השרת ועל המסד נתונים. אך כאשר אנו מדברים על אתר אשר לא יכול להשתמש בצורה מלאה ב-Page Caching, בין אם מדובר על תוצאות חיפוש או כאשר מדובר על אתר אשר מחזיר תוצאות שונות בהתאם למשתמש הגולש בו (בדוגמא לפורום, רשת חברתית וכד׳) אנו צריכים למצוא פיתרון אחר.
מה זה Object Caching?
אז כאמור אם האתר אמור להציג מידע אשר משתנה לפי המשתמש אשר מחובר אליו, או כאשר אנו לא יכולים להשתמש ב-Page Caching, איך אנו אמורים להתמודד עם עומסים? 🤔
אז כאמור לא משנה כמה אנחנו נבנה תשתית חכמה אשר מגדילה או מקטינה את כמות המשאבים לפי כמות התעבורה והבקשות, הכל בסוף מסתכם בעלויות שלפעמים יכולות להיות גבוהות מאוד. לחילופין אם אין לנו תשתית כזאתי, אנחנו נגיע למצב אשר שרת מסד הנתונים עלול לקרוס עקב עומס ואי היכולת להגיע ל-Scale טוב.
על מנת להתגבר על המצב אשר המסד נתונים שלנו יהיה צוואר בקבוק ועל מנת לאפשר לבצע Caching למידע אשר חוזר ממסד הנתונים, נרצה לממש מנגנון Object Caching כלשהו.
אז אם נרצה להגדיר מה זה Object Caching אפשר להסביר את זה בפשטות בתור מנגנון אשר מבצע Cache למידע אשר חוזר ממסד הנתונים. מנגנון כזה לרוב ימומש כ-Key Value Store, כלומר מאגר מידע פשוט אשר מורכב ממפתח (Key) וערך (Value). כאשר לרוב השאילתה אותה אנו מריצים מוגדרת כמפתח, והמידע אשר חוזר כתוצאה מביצוע השאילתה יהיו מוגדרים כערך.
אז איך זה עובד?
אז כאמור מנגנון זה הוא יחסית פשוט לא כזה שונה ממנגנון Page Caching. ניקח לדוגמה מצב בו אתם מחפשים פה באתר מילת חיפוש כלשהי, לצורך העניין ״וורדפרס״, כאשר אתם לוחצים על כפתור החיפוש האתר שולח שאילתה למסד הנתונים שיחזיר כל תוכן קיים אשר יש בו את מילת החיפוש.
באתר קטן אשר אין בו הרבה תוכן, או שאין בו הרבה פעולות של חיפוש זה לא כזה מהותי, אך כאשר מדברים על אתרים עם אלפי עמודי תוכן ועשרות אלפי חיפושים ביום זה מגיע למצב שפעולת החיפוש היא יקרה מאוד וגם לוקחת משאבים רבים וגם לוקחת זמן.
במקרה כזה אנו נרצה להכניס מנגנון באמצע, בין ביצוע השאילתה לבין החזרת התוצאות, אשר יבדוק האם בוצעה כבר שאילתה כזאתי ולא עבר זמן רב, במידה וכן נוכל להחזיר את התוצאות ישר וכך בעצם להימנע מפנייה למסד נתונים 💪.
בדומה למנגנוני Cache אחרים, גם כאן מדובר על מנגנון Cache אשר מבצע שמירה זמנית של תוצאות השאילתה לפרק זמן קצר, לרוב מנגנוני Object Caching יודעים לנהל בצורה עצמית את זמן ואופן שמירת המידע, כך שאנו לא צריכים להתערב בהגדרה זאתי.
אפשרויות למימוש Object Caching
כיום יש לרוב שתי גישות עיקריות למימוש של Object Caching, האחת ברמת הקוד, והשנייה ברמת הרכיב.
ניהול Object Caching ברמת הקוד
כאשר אנו מחפשים משהו בסיסי ופשוט, ניתן לממש זאת ע״י בניית מחלקה פשוטה לאיסוף, שמירה וניהול של מידע זה בזיכרון השרת. מחלקה זאת תמומש שלב אחד לפני הפנייה למסד נתונים. לחילופין יש מימושים אשר נותנים למחלקה לנהל את הפנייה למסד נתונים, כלומר במסגרת אותה מחלקה במידה והמידע לא קיים במאגר, הוא יפנה אוטומטית למסד הנתונים ויריץ את השאילתה וכמובן ישמור אותן בזיכרון השרת.
ניהול Object Caching ברמת הרכיב
לחילופין, במידה ואנו רוצים לבצע הפרדה מלאה בין השרת אשר מגיש את האתר ומעבד את הבקשות לבין שכבת ה-Cache, ניתן להרים שרת אשר חוצץ בין השרת עליו יושב האתר לבין השרת עליו יושב מסד הנתונים ועליו רץ פיתרון Object Caching כמו Redis או memcached.
כמובן שניתן להריץ על אותו השרת גם את האתר, גם את פתרון ה-Object Cache וגם את שרת מסד הנתונים, אך פעולה זאת לרוב לא מומלצת באתרים גדולים.
איזה שיטה עדיפה יותר?
כאמור לכל שיטה יש את היתרונות והחסרונות שלה, מצד אחד ניהול ברמת הקוד היא לרוב יותר מהירה כי היא מונעת את הצורך בשימוש ברכיב חיצוני, ולמרבית השפות יש ספרייה פנימית אשר מאפשרת לנהל Cache.
לעומת זאת לרכיב לרוב יש יתרון ברור יותר, בתור התחלה הוא יעיל יותר מאשר ניהול ברמת הקוד, בנוסף לרוב הוא כולל גם פיצ׳רים כמו ניהול עצמי מבחינת תוקף שמירת המידע, ניקיון וכד׳. בנוסף רכיבים אלו לרוב מאפשרים Persistent Cache, כלומר שבמידה והשרת נופל והזיכרון נמחק, בעת העלייה המידע יהיה זמין שוב כי הוא נשמר על הדיסק הקשיח גם.
מלבד זאת שימוש ברכיב חיצוני מאפשר לנו להתרכז בדברים החשובים שזה פיתוח האתר וניהול שוטף שלו 😎 ופחות ברמת שמירת ה-Cache.
Object Caching ווורדפרס
כאשר אנו מדברים על אתר וורדפרס, מרבית תוספי ה-Cache השונים כוללים בתוכם את האפשרות להתממשק לרכיב Redis או memcached.
לוורדפרס יש מחלה ידועה של שאילתות מורכבות, מכיוון שהמסד נתונים של וורדפרס מאפשר גמישות רבה ביצירת סוגי תכנים והרחבה של אובייקטים קיימים, זה בא על חשבון ביצועים, בשאילתות מסויימות אפשר להגיע למצב שיש כמעט 6-7 חיבורים של טבלאות (Inner Join).
לוורדפרס יש פתרון ברמת הקוד, ע״י שימוש במחלקת WP_Object_Cache ניתן לבצע ניהול של Object Cache ברמת הקוד ללא צורך ברכיב חיצוני כלשהו. מסיבה לא ברורה וורדפרס ממליצה לא לעבוד ישירות עם מחלקה זאת כאשר מפתחים תוספים, אלא ע״י שימוש בפונקציות wp_cache השונות.
למידע נוסף על איך להשתמש בפונקציות אלו, אני ממליץ לקרוא את הדוקומנטציה הרישמית של וורדפרס בנושא.
סיכום
שימוש ב-Object Cache במקביל ל-Page Cache יכול במקרים רבים לשפר פלאים את מהירות האתר, וכמובן לחסוך בעלויות רבות בבניית תשתית של Auto Scaling ברמת רכיבי השרת השונים.