האפליקציה שלך מייצרת שאילתת מסד נתונים. מסד הנתונים מריץ אותה, מושך את המידע ומחזיר אותו. עד כאן הכול רגיל. אבל מה אם אותה שאילתה רצה 500 פעמים בדקה — ומחזירה את אותה תוצאה בכל פעם? אלה 500 נסיעות הלוך ושוב שהשרת שלך לא צריך לעשות.
זה בדיוק הבעיה שהגדרת cache בשרת פותרת. ושנים רבות, שני כלים שלטו בתחום הזה: Memcached ו-Redis. שניהם שומרים נתונים בשימוש תכוף בזיכרון כך שהאפליקציה יכולה לשלוף אותם במיקרושניות במקום מילישניות. אבל הם לא ניתנים להחלפה. בחירה בכלי הלא נכון לעומס העבודה שלך עלולה לגרום לך להחמיץ שיפורי ביצועים של ממש.
כך הם שונים בפועל — וכיצד להחליט איזה מהם שייך לשרת שלך.
מה משותף לשני הכלים
לפני שנצלול לשוני, כדאי להבין מה Memcached ו-Redis חולקים. שניהם הם מאגרי key-value בזיכרון. שניהם מהירים מאוד — זמני השליפה הם בדרך כלל פחות מ-1ms בעומס רגיל. ושניהם כלים בשלים ומוכחים עם קהילות גדולות ותיעוד מוצק.
הדמיון בערך נגמר שם.
איך Memcached עובד (ואיפה הוא מצטיין)
Memcached הוא הפשוט מבין השניים. הוא נבנה למשימה אחת: לשמור דברים במטמון במהירות. אתה שומר זוג key-value, אתה שולף אותו. זה בעצם כל ה-API.
הפשטות הזו היא גם החוזק הגדול ביותר שלו. Memcached הוא רב-הברגתי (multi-threaded), מה שאומר שהוא יכול לנצל במלואם ליבות CPU מרובות ללא הגדרה מיוחדת. בשרת עם 8 ליבות, Memcached יכול לפזר קריאות וכתיבות של cache על כולן. Redis, לעומת זאת, הוא חד-הברגתי (single-threaded) כברירת מחדל (אם כי Redis 6 הוסיף I/O מרובה הברגות לפעולות רשת).
Memcached גם משתמש בזיכרון ביעילות רבה יותר לאחסון מחרוזות פשוטות. אם הגדרת cache בשרת שלך מורכבת כולה מאחסון קטעי HTML מסודרים או אסימוני session, Memcached יכול לטפל ביותר רשומות לכל גיגהבייט של RAM לעומת Redis.
היכן Memcached נופל:
- אין שמירה לדיסק. אם השרת מופעל מחדש, ה-cache נמחק.
- אין מבני נתונים מובנים מעבר למחרוזות.
- אין שכפול (replication) או אשכולות ללא כלים חיצוניים.
- אין מסרים מסוג pub/sub.
- אין תסריטי Lua.
לצורכי קריאה טהורים עם תפוקה גבוהה על צומת יחיד — במיוחד כשהנתונים שלך הם מחרוזות פשוטות או בינאריות מסודרות — Memcached הוא בחירה מצוינת. הוא רזה, צפוי ומהיר.
איך Redis עובד (ולמה משתמשים בו הרבה מעבר ל-Cache)
Redis התחיל כמטמון והתפתח למשהו הרבה יותר רחב. כיום הוא משמש כמטמון, מתווך הודעות, מאגר session, מנוע לוח תוצאות, מגביל קצב, ועוד — הכול באחד.
ההבדל נעוץ במבני הנתונים. Redis תומך באופן מובנה ב:
- Strings — כמו Memcached
- Hashes — כמו מאגר key-value קטן בתוך מפתח
- Lists — אוספים מסודרים, שימושיים לתורים
- Sets ו-Sorted Sets — מצוינים ללוחות תוצאות וסינון כפילויות
- Bitmaps ו-HyperLogLogs — לניתוח נתונים וספירה משוערת
- Streams — למקורות אירועים ותורי הודעות
זה חשוב להגדרת cache בשרת שלך משום שאפליקציות אמיתיות לרוב שומרות במטמון יותר ממחרוזות גולמיות. דף מוצר עשוי לשמור hash של מזהי מוצרים קשורים. לוח בקרה של משתמש עשוי לשמור sorted set של פעילות אחרונה. Redis מטפל בכל זה באופן מובנה מבלי לסדר אובייקטים מורכבים למחרוזות ובחזרה.
Redis גם תומך בשמירה לדיסק. אפשר להגדיר אותו לכתוב לדיסק לפי לוח זמנים (RDB snapshots) או על ידי צירוף כל פעולת כתיבה ליומן (AOF). כלומר, ה-cache שלך שורד הפעלה מחדש — ובחלק מהתצורות, Redis יכול לשמש כמאגר נתונים ראשי, לא רק כשכבת cache.
לרוב הגדרות cache בשרת מודרניות, Redis הוא הבחירה הגמישה יותר. הפרש הביצועים בין השניים זניח לרוב העומסים — שניהם פועלים בטווח תת-מילישני. מה ש-Redis מוסיף הוא עומק.
אנחנו משתמשים ב-Redis כעמוד השדרה של שמירת אובייקטים ב-WordPress, שומרים תוצאות שאילתות מסד נתונים בזיכרון כך שטעינות חוזרות של דפים מדלגות על מסד הנתונים לגמרי. cache שהתחמם היטב משיג בדרך כלל שיעורי hit מעל 80%, מה שמתורגם ישירות ל-TTFB נמוך יותר ומסירת דפים מהירה יותר. אפשר לקרוא עוד על הסיבה לכך בלמה ה-Time to First Byte שלך עולה לך בהמרות.
הגדרת Cache בשרת: איזה כלי לבחור
בחר Memcached אם:
- צרכי ה-cache שלך פשוטים — נתוני מחרוזות, אסימוני session, קטעי HTML
- יש לך שרת רב-ליבות ואתה רוצה למקסם את השימוש ב-CPU לפעולות cache
- אתה מריץ עומס עם מקביליות גבוהה מאוד שבו ריבוי הברגות נותן יתרון מדיד
- אינך זקוק לשמירה לדיסק, שכפול או סוגי נתונים מתקדמים
- אתה רוצה את טביעת הרגל הקלה ביותר לחלוטין בזיכרון עבור cache טהור
בחר Redis אם:
- אתה צריך יותר מאחסון מחרוזות — hashes, lists, sets, sorted sets
- אתה רוצה שמירה לדיסק בין הפעלות מחדש
- אתה בונה תורים, מסרי pub/sub, או מגבילי קצב לצד ה-cache שלך
- אתה צריך שכפול מובנה או Redis Cluster לזמינות גבוהה
- אתה מריץ WordPress ורוצה שמירת אובייקטים (Redis משתלב ישירות דרך תוספים)
- אתה רוצה כלי אחד שיכול לטפל במספר תפקידי cache
לרוב אפליקציות האינטרנט — ובוודאי לרוב אתרי WordPress — Redis הוא הבחירה הנכונה. היכולות הנוספות לא מוסיפות עומס משמעותי, והשמירה לדיסק אומרת שה-cache שלך שורד הפעלה מחדש ללא תקופת התחממות מכאיבה.
טיפים מעשיים להגדרה
קביעת מגבלת זיכרון מקסימלית
בכל כלי שתבחר, תמיד הגדר תקרת זיכרון. ללא כזו, cache הולך וגדל עלול להתחרות עם האפליקציה שלך על RAM — וזה מסתיים רע.
עבור Redis, הוסף זאת ל-redis.conf שלך:
maxmemory 512mb maxmemory-policy allkeys-lruהמדיניות allkeys-lru אומרת ל-Redis להסיר את המפתחות שנעשה בהם שימוש הכי פחות לאחרונה כאשר הזיכרון מתמלא. לשכבת cache טהורה, זה בדרך כלל מה שאתה רוצה. אפשרויות אחרות כמו volatile-lru (הסר רק מפתחות עם TTL מוגדר) עדיפות אם אתה מערבב נתונים מאוחסנים ונתוני cache באותה מופע Redis.
עבור Memcached, הזיכרון מוגדר בהפעלה:
memcached -m 512קביעת TTL מתאים
לכל פריט מאוחסן צריך להיות זמן חיים. cache מיושן הוא לעיתים קרובות גרוע יותר מאי-cache — משתמשים רואים נתונים ישנים ואתה מבלה זמן בניפוי תקלות שנראות כבאג אקראי.
נקודת התחלה כללית:
- קטעי HTML של דפים: 60–300 שניות
- תוצאות שאילתות מסד נתונים: 300–3600 שניות בהתאם לתדירות השינוי של הנתונים
- נתוני session של משתמש: התאם לזמן הפסקת ה-session שלך
- ערכי תצורה סטטיים: שעות או יותר
עקוב אחר שיעור ה-Hit
הגדרת cache בשרת טובה רק כמו שיעור ה-hit שלה. אם ה-cache שלך מקבל hit ב-40% מהמקרים, כנראה שאתה מגדיר TTL קצר מדי, לא שומר את האובייקטים הנכונים, או מסיר פריטים באגרסיביות יתר.
עבור Redis, בדוק את שיעור ה-hit בזמן אמת:
redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses'חשב את שיעור ה-hit כך: hits / (hits + misses). שאף ל-80% ומעלה. אם אתה מתחת לזה, בדוק אילו מפתחות מתבקשים הכי הרבה וודא שהם אכן נשמרים במטמון.
אם אתה על שרת מנוהל, סוג זה של ניטור מוצג לעיתים קרובות בלוח הבקרה שלך באופן אוטומטי — כך שתוכל לראות מגמות שיעור hit לאורך זמן מבלי להריץ פקודות CLI ידנית.
מה עם שניהם בו זמנית?
זה לא נפוץ, אבל חלק ממערכות מריצות Memcached ו-Redis זה לצד זה — Memcached לאחסון session עם תפוקה גבוהה ו-Redis לנתוני אפליקציה. זה מוסיף מורכבות תפעולית ללא יתרון מעשי גדול לרוב האתרים. בחר אחד, הגדר אותו היטב, ועקוב אחריו. זה יעלה על כל הגדרת cache כפולה שאינה מכווננת כראוי.
לסקירה מעמיקה של הפעלת Redis ביעילות על השרת שלך, ראה איך להגדיר Redis Caching על השרת שלך מבלי לשבור כלום. ואם אתה רוצה להבין היכן cache מתאים בתמונת הביצועים הרחבה יותר, אופטימיזציית מהירות אתרים: מה באמת משנה מכסה את כל המחסנית.
השורה התחתונה
Memcached מהיר יותר בתרחישים רב-הברגתיים ספציפיים ופשוט יותר להבנה. Redis מסוגל יותר, שומר על נתונים לדיסק, וגמיש יותר — ולרוב הגדרות cache בשרת בעולם האמיתי, הוא ברירת המחדל הטובה יותר.
אם אתה לא בטוח, התחל עם Redis. הגדר מגבלת זיכרון, קבע TTL הגיוניים, ועקוב אחר שיעור ה-hit. תמיד אפשר לכוונן משם ברגע שתראה איך העומס הספציפי שלך מתנהג.
