הקדמה
"האתר שלי איטי – צריך להוסיף Redis."
זו אחת המשפטים שאנחנו שומעים הכי הרבה. לפעמים זה מגיע ממפתח, לפעמים מ-plugin שמציג אזהרה, לפעמים מפורום.
כמעט תמיד זה מגיע לפני שמישהו בדק מה בכלל גורם לאיטיות.
האמת היא שיש לא מעט אתרים שהתקנת Redis עליהם לא תעשה כמעט כלום.
ויש אתרים שבהם object cache שבור בשקט – ואף אחד לא שם לב, כי האתר "עובד."
במאמר הזה נסביר מה כל שכבת cache עושה, מתי היא עוזרת, ומתי כדאי פשוט לא לגעת.
שלוש שכבות שונות לגמרי
לפני שמחליטים מה להתקין, חשוב להבין שמדובר בשלוש שכבות שפועלות על חלקים שונים לחלוטין של ה-stack.
הן לא מחליפות אחת את השנייה – כל אחת פותרת בעיה אחרת.
OPcache – שכבת הבסיס שתמיד צריכה לרוץ
מה היא עושה
PHP הוא שפה מפורשת (interpreted). בכל בקשה לאתר, הקרנל של PHP צריך לקחת את קבצי ה-.php, לפרסר אותם,
לקמפל אותם ל-bytecode, ורק אז להריץ. בלי OPcache, זה קורה מחדש בכל בקשה, לכל קובץ.
OPcache שומר את ה-bytecode המקומפל בזיכרון. הבקשה הבאה פשוט מריצה את מה שכבר קומפל –
בלי parsing, בלי compilation. על אתר WordPress טיפוסי עם עשרות plugins, שכל אחד טוען עשרות קבצי PHP,
ההבדל יכול להיות בין 200ms ל-20ms בזמן עיבוד PHP טהור.
מתי היא עוזרת
תמיד. OPcache רלוונטית לכל אתר PHP, בכל גודל, בכל כמות תעבורה. זו לא אופטימיזציה – זו תשתית בסיסית.
נקודה חשובה: WordPress Site Health
WordPress Site Health מציג לפעמים אזהרה: "OPcache אינו מופעל." על שרתים רבים, ובמיוחד בסביבות CloudLinux עם CageFS,
האזהרה הזו היא false positive – OPcache רץ ופועל, אבל WordPress לא מצליח לזהות אותו בצורה נכונה בגלל אופן הבידוד של ה-PHP process.
אם אתם רואים את האזהרה הזו ומתכננים פעולה – קודם כל בדקו עם הצוות שלנו – יכול להיות שאתם רואים False Positive.
אל תסמכו על Site Health לבד.
Object Cache – Memcached ו-Redis
מה הן עושות
OPcache פותרת את בעיית קמפול ה-PHP. אבל WordPress עדיין מבצע שאילתות DB בכל בקשה –
קריאת הגדרות מ-wp_options, שליפת תוכן,
בדיקת sessions. Object cache שומר את התוצאות של השאילתות האלה בזיכרון, כך שהשאילתה הבאה לא תגיע ל-MySQL כלל.
Memcached ו-Redis עושות בעצם אותו הדבר מנקודת מבטה של WordPress –
הן שתיהן מספקות persistent object cache. ההבדלים ביניהן (Redis תומך ב-data structures מורכבות, persistence לדיסק, clustering)
רלוונטיים לפרויקטים גדולים, אבל לאתר WordPress טיפוסי הן אקוויוולנטיות לחלוטין.
מתי זה באמת עוזר
Object cache עוזר כשהצוואר בקבוק הוא מספר השאילתות למסד הנתונים. האינדיקטור הפשוט:
התקינו Query Monitor, טענו כמה עמודים, ובדקו כמה שאילתות DB מתבצעות בכל בקשה.
מתחת ל-50 שאילתות לעמוד – object cache יעזור מעט, אם בכלל.
50-100 שאילתות -תראו שיפור מורגש.
מעל 100 שאילתות – object cache הוא כמעט הכרחי.
חנויות WooCommerce עם קטלוגים גדולים, אתרי membership עם הרבה logica per-user,
אתרים עם plugins כבדים שמבצעים הרבה lookups – אלה המקרים שבהם ההבדל הוא דרמטי.
הסיפור שלא מספרים: object cache שבור בשקט
עבדנו על אתר WooCommerce שסבל מביצועים גרועים בצ'קאאוט. בדיקה עם Query Monitor גילתה תמונה מוזרה:
תוסף התשלומים שלח בקשת OAuth לכל טעינת עמוד, מחדש, כל פעם. טוקן OAuth שתקף 9 שעות נשלף מחדש בכל בקשה.
אותה בעיה חזרה על עצמה עם שתי קריאות API נוספות לשירותים חיצוניים – בסה"כ כ-1.5 שניות של HTTP calls חוסמות בכל טעינה.
על הנייר, object cache היה מותקן ומוגדר. בפועל, הוא לא שמר שום דבר בין בקשות. כל בקשה התחילה עם cache ריק לגמרי.
הגורם: WordPress plugin שביצע wp_cache_flush() בכל טעינת עמוד – מוחק את כל ה-cache בכל בקשה.
אחרי שזיהינו ונטרלנו אותו, ה-checkout ירד מ-2,800ms ל-1,200ms – שיפור של 57% ברגע אחד.
הלקח: object cache שבור בשקט הוא כמעט גרוע יותר מ-object cache שלא מותקן.
לפחות בלי cache אתם יודעים מה אתם מקבלים. Cache שמתאפס בכל בקשה גורם לאותה עומס על ה-DB,
אבל מוסיף overhead של ניהול cache מעל.
Page Cache – השכבה שאנשים שוכחים לספור
זו לא Redis ולא Memcached – אבל היא לרוב ההשפעה הגדולה ביותר על TTFB.
Page cache (כמו WP Rocket, W3 Total Cache, LiteSpeed Cache) שומר את ה-HTML המוכן של העמוד ומגיש אותו ישירות,
בלי להריץ PHP בכלל. TTFB של 28ms במקום 800ms – זה page cache, לא object cache.
נקודה חשובה: page cache לא עובד על עמודים דינמיים – checkout, cart, עמודי משתמש מחובר.
בדיוק בשביל זה object cache חשוב – הוא עוזר בדיוק על העמודים שבהם page cache לא יכול לעזור.
הגישה שלנו ב-SPD: לא מנחשים, מודדים
אנחנו לא מאמינים בפתרון גנרי.
כל לקוח שפונה אלינו עם תלונה על ביצועים עובר תחקיר שמתחיל מנתונים: TTFB בפועל,
מספר שאילתות DB לעמוד, מצב שכבות ה-cache הקיימות.
רק אחרי שיש תמונה ברורה אנחנו ממליצים על מה להתקין – ולפעמים הממצא הוא שה-cache שכבר קיים לא עובד כמו שצריך.
הגישה הזו לא רק נכונה מקצועית – היא גם מה שמבדיל אותנו משוק ה-hosting שבו "הוסיפו Redis" הוא תשובה אוטומטית.
אז מה מתקינים?
תמיד
OPcache – חייב לרוץ על כל שרת PHP. אם הוא כבוי, זו הבעיה הראשונה לפתור.
ברוב המקרים
Page cache (WP Rocket או שווה ערך) – ההשפעה הגדולה ביותר על ביצועים לאתרים תוכן ו-WooCommerce.
כשיש הצדקה
Object cache (Memcached או Redis) – כשיש מעל 50-100 שאילתות DB לעמוד, כשה-checkout איטי על אתר WooCommerce, או כשיש membership logic כבד.
לעולם לא "כי מישהו אמר"
Redis בלי מדידה קודמת. Redis הוא כלי מצוין – אבל על חלק מהסביבות (AlmaLinux 10, cPanel עם podman-based packages) הוא מגיע עם מורכבות תפעולית שמנגדת לו את היתרון. Memcached native יותר פשוט ויציב בסביבות shared hosting רגילות.
הגישה הנכונה: מדדו לפני שמתקינים
לפני כל החלטת cache, שלושה צעדים:
1. בדקו TTFB בסיסי -כמה זמן לוקח עמוד לטעון בלי cache? מה ה-breakdown בין PHP, DB, ו-network?
2. ספרו שאילתות DB – Query Monitor יתן לכם את המספר המדויק. זה הנתון שמחליט אם object cache שווה.
3. בדקו שה-cache שיש לכם עובד – לפני שמוסיפים שכבה, ודאו שהשכבות הקיימות פועלות בפועל. Cache שבור בשקט הוא נפוץ יותר ממה שחושבים.
אם אחרי שלושת הצעדים האלה עדיין לא ברור מה הבעיה – זה הזמן לפנות אלינו.
לעתים קרובות הבעיה היא לא cache כלל, אלא plugin איטי, query חסר index, או תצורת PHP-FPM שמייצרת תור.
צוות SPD Hostingsupport@spd.co.il
