Redis или Memcached: једноставан cache може да преокрене победника

За кеш који само чува и враћа вредности по кључу, Memcached може бити бржи избор. У објављеном поређењу груписаних уписа забележено је 493.152 операције у секунди за Memcached set_multi и 125.211 за Redis са pipelining-ом. То је резултат конкретних клијената и једноставних SET операција; аутор не наводи P99 за тај резултат, па он сам не одређује избор за продукциони кеш.

Redis има јачи разлог за избор када апликација треба да мења делове структуре података, одржава скупове или рангирања, реплицира податке или их записује на диск. Преглед Redis Open Source наводи hash, скупове и сортиране скупове са атомским операцијама, као и уграђену репликацију и различите нивое трајности. Зато се поређење протока једноставних кључева одваја од питања које послове апликација препушта кешу.

Зашто начин слања захтева мења резултат

Када клијент пошаље команду и чека одговор пре следеће, свака операција плаћа трошак обиласка мреже. Pipelining допушта да више команди буде послато пре чекања одговора, па се тај трошак распоређује на више операција. Груписање зато може знатно да промени измерени проток без промене самог сервера. Резултат таквог теста говори о споју клијента, протокола, мреже и кеша.

У поменутом поређењу почетни тест појединачних уписа показао је много већу разлику него тест са груписањем. Ни други резултат није потпуно симетричан: Memcached set_multi и Redis pipeline нису исто клијентско понашање, мада оба смањују трошак слања великог броја захтева. За поређење сервера корисно је прво задати исту дубину захтева у лету. Одвојено се може измерити најбоља конфигурација коју стварна апликација уме да користи; тај налаз описује целу конфигурацију, а не изоловану брзину сервера.

Сам SET тест још не представља кеш у коме преовлађују читања. Промашај кеша може покренути приступ бази, а веће вредности оптерећују мрежу и меморију другачије од малих. Тим који гледа само највећи број операција у секунди може изабрати конфигурацију чија латенција при том оптерећењу већ прелази дозвољену границу.

Исти ресурси, исти саобраћај, иста граница P99

Поставка представљена на Linux Plumbers Conference доделила је сваком процесу Redis-а или Memcached-а наменски процесор и 2 GB меморије, унапред попунила кеш за 95% погодака и користила однос једног уписа на десет читања; просечна вредност имала је 64 бајта, а захтев је био да P99 остане испод једне милисекунде. Аутори су узимали најлошији P99 међу инстанцама, па добар просек није могао да сакрије спору инстанцу. Тај рад испитује утицај меморијских страница на ARM64 систему, а његове графиконе не треба читати као општу пресуду о два кеша.

За одлуку о сопственом систему, „исти ресурси” значе исти буџет процесора и меморије по конфигурацији, а не само машине сличног назива. Потребно је изједначити и број кључева, распоред њихове популарности, величине вредности, однос читања и уписа и удео погодака. Ако један пролаз користи топао, мали скуп података, а други изазива истискивање ставки, разлика у протоку не може се приписати само избору кеша.

Постоји и важна граница нормализације. Memcached може да обрађује захтеве кроз више нити, али додела једног процесора по инстанци ограничава корист од тог својства. Ако продукциона конфигурација има више језгара по инстанци, засебан тест треба да измери и тај распоред, уз укупан буџет ресурса који тим заиста може да плати. На крају се упоређује проток остварен испод задате P99 границе, а не највећи проток из пролаза који је границу прекорачио.

Када функције мењају архитектуру

Преглед Memcached-а описује ставку као кључ, рок истека и сирову вредност: сервер не разуме унутрашњу структуру уписаног објекта, а његови сервери међусобно не реплицирају податке. Клијент бира сервер за кључ, док апликација обезбеђује вредност коју ће поново уписати после промашаја. То је добар модел за резултат упита или припремљен одговор који се може обновити из другог система.

Ако више захтева треба да мења различита поља истог објекта, Redis hash омогућава рад над пољем без преузимања и поновног уписа целе вредности. Скупови и сортирани скупови помажу када апликација тражи проверу припадности или поредак по резултату. У Memcached-у се такви подаци могу серијализовати у вредност, али онда апликација преузима посао измене и контроле истовремених уписа. То је стварни архитектонски трошак који GET и SET тест не обухвата.

Репликација и трајност решавају различите проблеме. Redis може да одржава копије података и да подешава запис на диск, али треба одредити колико је губитка недавних уписа прихватљиво и како ће се поступати при отказу. Memcached-ов модел полази од тога да се кеширана вредност може поново добити; ако је неопходно да стање преживи рестарт или постоји копија у самом слоју података, то више није само питање брзине једноставног кеша.

Шаблон за сопствени memtier тест

Упутство за memtier_benchmark описује избор Redis и Memcached протокола, однос SET и GET операција, величину вредности, број клијената, дубину pipelining-а и приказ перцентила. Исти генератор оптерећења омогућава упоредивији тест од два различита клијентска скрипта. Параметре ипак треба везати за саобраћај апликације, јер подразумевана подешавања алата нису опис њеног рада.

1. Припремите исти опсег кључева и вредности у оба кеша, па измерите стварни удео погодака. Задајте распоред популарности кључева и величине вредности према саобраћају који очекујете; исту количину резервисане меморије проверите и после попуњавања, када се види стварна потрошња.
2. Покрените генератор на одвојеној машини и у оба пролаза задржите исти буџет процесора, број клијената, трајање, однос SET:GET и простор кључева. Као условни почетни пролаз могу послужити --ratio=1:10, --data-size=64 и --pipeline=1; затим замените те вредности својим обрасцем саобраћаја и забележите и проток и P99.
3. Поновите пролазе при различитом броју клијената и дубини pipelining-а коју апликациони клијент заиста подржава. За сваку конфигурацију тражите највећи стабилан проток који остаје испод ваше P99 границе. Ако се резултат мења са бројем захтева у лету, у одлуци сачувајте и тај параметар, не само име кеша.

За пролазан кеш једноставних вредности предност Memcached-а у уском тесту заслужује проверу на сопственом оптерећењу. Ако апликација тражи структуре података, репликацију или подешен запис на диск, Redis доноси функције чију вредност мерење самих GET и SET операција не може да покаже.

Прочитајте и:

• Claude Code или Codex: врста задатка бира победника
• Kajabi или Thinkific: јефтинији курс може да тражи више алата
• Паушалац или лична зарада: приход сам не одлучује победника