{"id":20962,"date":"2026-08-24T15:04:34","date_gmt":"2026-08-24T13:04:34","guid":{"rendered":"https:\/\/webhosting.de\/redis-lfu-vs-lru-eviction-policies-vergleich-cache-optimierung\/"},"modified":"2026-08-24T15:04:34","modified_gmt":"2026-08-24T13:04:34","slug":"vergelijking-van-de-eviction-beleidsregels-lfu-en-lru-in-redis-cache-optimalisatie","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/redis-lfu-vs-lru-eviction-policies-vergleich-cache-optimierung\/","title":{"rendered":"Redis LFU versus LRU: welk verwijderingsbeleid is het juiste?"},"content":{"rendered":"<p>Redis LFU en LRU bepalen welke sleutels bij schaarse bronnen uit de cache worden verwijderd \u2013 en daarmee over <strong>Raakpercentage<\/strong>, responstijd en geheugengebruik. Ik laat je zien wanneer het frequentiegebaseerde beleid LFU of het actualiteitsgebaseerde beleid LRU beter geschikt is, hoe je deze configureert en welke effecten allkeys-lfu versus allkeys-lru in de dagelijkse praktijk hebben; het sleutelwoord <strong>Redis LFU<\/strong> staat daarbij centraal.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>Recency<\/strong> vs. <strong>Frequentie<\/strong>: LRU geeft de voorkeur aan de meest recente toegangen, LFU geeft de voorkeur aan frequente toegangen.<\/li>\n  <li><strong>Benadering<\/strong> in Redis: Beide beleidsregels werken met steekproeven via `maxmemory-samples`.<\/li>\n  <li><strong>Werklasten<\/strong> Kies: Sessies\/Dashboards \u2192 LRU, Bestsellers\/Ranglijsten \u2192 LFU.<\/li>\n  <li><strong>Afstemmen<\/strong> Zorg ervoor dat de volgende instellingen correct zijn ingesteld: lfu-decay-time, maxmemory, maxmemory-samples.<\/li>\n  <li><strong>Controle<\/strong> Noodzakelijk: de hit-rate, het aantal evictions per seconde en de latentie continu controleren.<\/li>\n<\/ul>\n\n<h2>Hoe uitzetting in Redis verloopt<\/h2>\n\n<p>Redis bewaart gegevens in het RAM-geheugen; als het proces <strong>maxmemory<\/strong>, moet het sleutels verwijderen. Precies hier komen beleidsregels zoals allkeys-lru en allkeys-lfu om de hoek kijken, die bepalen welke items plaats moeten maken. Ik richt me op deze twee varianten, omdat ze rekening houden met de volledige dataset, niet alleen met sleutels met een TTL. Redis selecteert de te verwijderen sleutel via een steekproef, die je kunt instellen met <strong>maxmemory-samples<\/strong> regelt; meer steekproeven verhogen de nauwkeurigheid, maar kosten CPU-capaciteit. Deze aanpak levert in grote keyspaces goede resultaten op, zonder dat het beheer te duur wordt.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis-eviction-policies-9472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interne informatie: hoe Redis LRU en Redis LFU implementeert<\/h2>\n\n<p>Beide beleidsregels werken in Redis <strong>bij benadering<\/strong>, om constant snel te blijven. LRU slaat per object een tijdstempel op voor de laatste toegang. Bij eviction neemt Redis een steekproef en verwijdert de \u201eoudste\u201c kandidaat uit de selectie. Dit is in de praktijk uiterst effici\u00ebnt en voldoende nauwkeurig, mits je de steekproefgrootte afstemt op de keyspace.<\/p>\n\n<p><strong>Redis LFU<\/strong> voegt aan dit idee een <strong>compacte frequentie-metriek<\/strong>, die in de loop van de tijd <strong>veroudert<\/strong> (Decay). Elke toegang verhoogt de gebruiksteller niet lineair, maar op een gedempte manier, zodat afzonderlijke piekfasen de teller niet permanent overbelasten. Tegelijkertijd zorgt een tijdsverval ervoor dat vroegere populariteit op een gegeven moment aan gewicht verliest. Via parameters zoals <em>lfu-verval-tijd<\/em> (hoe snel veroudert de geschiedenis) en een interne logfactor (hoe sterk groeien de tellers per bezoek) breng je in evenwicht <em>reactiviteit<\/em> tegen <em>Stabiliteit<\/em> de prioritering. Vuistregel: lagere decay-waarden \u2192 snellere aanpassing, hogere waarden \u2192 tragere, maar stabielere prioriteiten.<\/p>\n\n<h2>LRU in Redis: principe, voordelen, valkuilen<\/h2>\n\n<p>LRU verwijdert de oudste <strong>ongebruikte<\/strong> Sleutels en geeft daarmee prioriteit aan actualiteit. Deze logica past bij patronen met een tijdelijke relevantie, zoals sessies, live-dashboards of kortstondige API-antwoorden. Redis maakt gebruik van een benaderde LRU: records zijn voorzien van een tijdstempel, steekproeven selecteren de oudste kandidaat \u2013 snel en transparant. LRU reageert snel op wijzigingen, omdat recent gebruikte sleutels bovenaan blijven staan en oudere worden verwijderd. Grote eenmalige scans kunnen echter problematisch zijn, omdat deze de cache vullen met kortstondige waarden en belangrijke sleutels die tijdelijk inactief zijn <strong>verdringen<\/strong>.<\/p>\n\n<p>Praktische tip: Als je LRU gebruikt en regelmatig \u201ekoude\u201c massale opvragingen (bijv. backoffice-rapporten) uitvoert, capsel deze workloads dan in <em>afzonderlijke<\/em> Caches of plan grotere <strong>maxmemory<\/strong>-reserves. Zo voorkom je cache-pollution, waarbij waardevolle gegevens die binnenkort weer nodig zijn, worden verdrongen.<\/p>\n\n<h2>LFU in Redis: principe, voordelen, valkuilen<\/h2>\n\n<p>LFU verwijdert sleutels met een lage <strong>Gebruiksfrequentie<\/strong> en beschermt zo \u201ehot keys\u201c op de lange termijn. De interne teller groeit logaritmisch en veroudert in de loop van de tijd (decay), zodat oude populariteit niet eeuwig meetelt. Dit leidt tot een evenwichtige weging: Veelgebruikte gegevens blijven langer bewaard, terwijl enkele uitschieters de prioriteit nauwelijks be\u00efnvloeden. LFU levert in catalogi, ranglijsten of feature-caches vaak een hogere hit-rate op, omdat het beproefde sleutels in het geheugen bewaart. Het reageert echter trager op nieuwe trends, waardoor het afstemmen van <strong>lfu-verval-tijd<\/strong> belangrijk blijft.<\/p>\n\n<p>Voor <strong>On\/Off-trends<\/strong> (bijv. marketingcampagnes) geldt het volgende: stel de decay zo in dat een nieuwe trend merkbaar invloed heeft, zonder dat kortstondige ruis de cache voortdurend herschikt. In veel projecten heeft het volgende zijn waarde bewezen: begin voorzichtig en versnel vervolgens stapsgewijs, totdat de hit-rate onder belasting stabiel blijft.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis_lfu_vs_lru_3948.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Vergelijking: recency versus frequentie in het dagelijks leven<\/h2>\n\n<p>In wezen maakt LRU onderscheid tussen \u201ewanneer voor het laatst gebruikt\u201c en LFU \u201ehoe vaak gebruikt\u201c \u2013 ik kies op basis van de werkelijke <strong>Werklasten<\/strong>. Voor vluchtige, gebruikersgerichte gegevens werkt LRU meestal beter, omdat recente toegangen vaak een voorbode zijn van toekomstige toegangen. Voor populaire productgegevens of configuraties werkt LFU beter, omdat blijvende populariteit de doorslag geeft. In gemengde scenario\u2019s scheid ik caches op basis van gegevenstypen en pas ik verschillende beleidsregels toe. De volgende tabel vat de verschillen kort samen en geeft je een snel <strong>Beslissingsondersteuning<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Aspect<\/th>\n      <th>LRU (allkeys-lru)<\/th>\n      <th>LFU (allkeys-lfu)<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Prioriteit<\/td>\n      <td><strong>Actualiteit<\/strong> het aantal bezoeken<\/td>\n      <td><strong>Frequentie<\/strong> het aantal bezoeken<\/td>\n    <\/tr>\n    <tr>\n      <td>Reactie op verandering in patroon<\/td>\n      <td>Snel, want het laatste gebruik telt<\/td>\n      <td>Gematigd, aangezien de geschiedenis een rol speelt<\/td>\n    <\/tr>\n    <tr>\n      <td>Aanbevolen workloads<\/td>\n      <td>Sessies, dashboards, live-API's<\/td>\n      <td>Bestsellers, ranglijsten, speciale caches<\/td>\n    <\/tr>\n    <tr>\n      <td>Gevoeligheid voor \u201evervuiling\u201c<\/td>\n      <td>Vrij hoog bij grote scans<\/td>\n      <td>Vrij laag dankzij de frequentieteller<\/td>\n    <\/tr>\n    <tr>\n      <td>Tuning-schroeven<\/td>\n      <td><strong>maxmemory-samples<\/strong><\/td>\n      <td><strong>lfu-verval-tijd<\/strong>, maxmemory-samples<\/td>\n    <\/tr>\n    <tr>\n      <td>Verklaarbaarheid<\/td>\n      <td>Zeer intu\u00eftief<\/td>\n      <td>Goed, met het oog op Decay<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Gevolgen voor de prestaties in de praktijk<\/h2>\n\n<p>Bij kleine datasets blijft het verschil vaak <strong>laag<\/strong>; naarmate de omvang toeneemt, wordt het kaf van het koren gescheiden. LRU overtuigt door de lage CPU-kosten van de benadering en een duidelijke reden: een key wordt verwijderd omdat deze het laatst ongebruikt is gebleven. LFU scoort bij consistente toegangen, omdat \u2018hot keys\u2019 veilig in het RAM blijven en de hit-rate meetbaar stijgt. De prijs die je ervoor betaalt, is het vereiste inzicht in tellers en decay, zodat je niet te traag of te agressief reageert. Ik controleer de effecten met profilering en statistieken, in plaats van alleen op gevoel te <strong>beslissen<\/strong>.<\/p>\n\n<p>Plan daarnaast ook de <strong>Koude start<\/strong> een: Na een herstart of implementatie is de cache leeg of \u201eonbekend\u201c met betrekking tot de frequenties. LRU stabiliseert zich snel op basis van kortetermijnlocaliteit. LFU heeft van nature een bepaalde opwarmtijd nodig om echte hotkeys te identificeren. Strategie\u00ebn zoals <em>Voorverwarmen<\/em> (het proactief laden van belangrijke sleutels) of een gefaseerde toename van het verkeer helpen de aanvankelijke latentie en missers te beperken.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis-eviction-policies-vergleich-4928.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configuratie en afstemming: de belangrijkste opties<\/h2>\n\n<p>Ik kies het beleid via <strong>maxmemory-beleid<\/strong>, meestal allkeys-lru of allkeys-lfu, minder vaak volatile-varianten met de nadruk op TTL. Met <strong>maxmemory<\/strong> Ik stel de harde grens vast waarboven de eviction begint, en bepaal de omvang ervan op basis van de dataset plus een veiligheidsmarge. De steekproefomvang stel ik in via <strong>maxmemory-samples<\/strong>; hogere waarden verbeteren de selectie, maar vergen wel CPU-kracht. Voor LFU geldt <strong>lfu-verval-tijd<\/strong> cruciaal, omdat hiermee wordt bepaald hoe snel oude zoekopdrachten aan belang inboeten en nieuwe aan belang winnen. Een uitgebreide handleiding voor het bepalen van de opslagcapaciteit vind je hier: <a href=\"https:\/\/webhosting.de\/nl\/redis-geheugenbeheer-geheugen-optimaal-configureren-prestaties-cache\/\">Het geheugen optimaal configureren<\/a>.<\/p>\n\n<h3>Concrete aanbevelingen voor de praktijk<\/h3>\n<p>Om snel aan de slag te kunnen, werk ik met duidelijke standaardinstellingen en voer ik iteraties uit onder belasting:<\/p>\n<ul>\n  <li>allkeys-lru + maxmemory-samples 7\u201310 voor vluchtige, gebruikersgerichte gegevens<\/li>\n  <li><strong>Redis LFU<\/strong> (allkeys-lfu) + lfu-decay-time conservatief (bijv. een gematigde waarde) voor stabiele hotkey-workloads<\/li>\n<\/ul>\n<p>Configuratie tijdens de uitvoering instellen:<\/p>\n<pre><code>CONFIG SET maxmemory 8gb\nCONFIG SET maxmemory-policy allkeys-lru\nCONFIG SET maxmemory-samples 10\n# Overschakelen naar LFU:\nCONFIG SET maxmemory-policy allkeys-lfu\nCONFIG SET lfu-decay-time 5\n<\/code><\/pre>\n<p>In redis.conf stel je dezelfde opties permanent in. Ik test wijzigingen eerst in de staging-omgeving met een representatieve belasting, voordat ik ze in de productieomgeving doorvoer.<\/p>\n\n<h3>De steekproefomvang kiezen<\/h3>\n<p><strong>maxmemory-samples<\/strong> is een betrouwbare instellingsparameter: hogere waarden verbeteren de trefkwaliteit van de eviction-kandidaten, maar kosten wel CPU-tijd. Als vuistregel begin ik met 7\u201310 bij grote keyspaces en verlaag ik deze waarde alleen als de CPU-tijd schaars wordt. Bij kleine keyspaces zijn 5 steekproeven vaak voldoende.<\/p>\n\n<h2>Monitoring en statistieken: meten in plaats van gissen<\/h2>\n\n<p>Ik houd voortdurend in de gaten <strong>Raakpercentage<\/strong>, evictions, latenties en geheugengebruik, om de onderlinge wisselwerking te beoordelen. Als het aantal evictions sterk toeneemt, controleer ik de RAM-reserves, TTL-strategie\u00ebn en het gekozen beleid. Een dalende hit-rate wijst er vaak op dat veranderingen in patronen het huidige beleid verzwakken of dat gegevensrecords niet voldoende gescheiden in de cache worden opgeslagen. Latentiepieken duiden soms op te kleine <strong>Voorbeelden<\/strong> of op een te agressieve eviction. Regelmatige belastingstests helpen me om de juiste balans te vinden tussen CPU-belasting, geheugenlimiet en trefpercentage.<\/p>\n\n<p>Handige commando's voor snelle controles:<\/p>\n<pre><code>INFO stats     # keyspace_hits, keyspace_misses, evicted_keys, expired_keys\nINFO memory    # used_memory, fragmentation, allocator_overhead\nLATENCY DOCTOR # Opmerkingen over pieken, bijv. forking of I\/O<\/code><\/pre>\n<p>De <strong>Raakpercentage<\/strong> Ik bereken dit als hits \/ (hits + misses). Een dalend percentage bij een stijgend aantal evicties is een waarschuwingssignaal. <em>uitgezette_sleutels<\/em> in verhouding tot het verkeer en <em>gebruikt_geheugen<\/em> geeft aan of het beleid vaak moet worden geactiveerd. Met <em>Sleutel \u2018MEMORY USAGE\u2019<\/em> identificeer je te grote objecten die je cache onevenredig veel ruimte innemen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tech_office_redis_policy_9123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hosting- en schaalbaarheidsaspecten: bewust een platform kiezen<\/h2>\n\n<p>Redis komt het best tot zijn recht op een <strong>krachtige<\/strong> Een platform met veel RAM, een lage latentie en een betrouwbare netwerkverbinding. Bij groeiende projecten vermijd ik continu gebruik op volle capaciteit, omdat \u2018eviction\u2019 dan te vaak wordt geactiveerd en de hit-rate eronder lijdt. Een goede <a href=\"https:\/\/webhosting.de\/nl\/redis-eviction-hosting-cache-strategie\/\">Hostingstrategie<\/a> zorgt ervoor dat beleidsregels indien nodig worden toegepast en niet continu worden geactiveerd. Bij vergelijkingen geef ik de voorkeur aan premium-aanbieders zoals webhoster.de, waarvan de infrastructuur hoge belastingen soepel aankan en een voorspelbare capaciteit mogelijk maakt. Zo zorgt het platform direct voor minder evictions en betere <strong>Reactietijden<\/strong> en stabielere prestaties.<\/p>\n\n<h3>Aspecten met betrekking tot clusters en replica's<\/h3>\n<p>In sharding-opstellingen (bijv. Redis Cluster) zijn eviction-beslissingen van toepassing <strong>per knoop<\/strong>. Dat betekent: headroom, beleid en afstemming moeten per knooppunt kloppen, niet alleen \u201egemiddeld\u201c. Hotkeys die ongelijkmatig over de slots zijn verdeeld, kunnen ervoor zorgen dat afzonderlijke knooppunten eerder tegen hun limiet aanlopen. Plan daarom buffers per shard in en houd evictions op knooppuntniveau in de gaten. Replicaten nemen de gegevensstatus over, inclusief verwijderde sleutels; houd er bij belastingstests rekening mee dat extra replicatie de latentie kan verhogen, zonder dat het beleid zelf de oorzaak is.<\/p>\n\n<h2>TTL-strategie\u00ebn en gemengde beleidsmaatregelen<\/h2>\n\n<p>Met TTL bescherm ik duurzame <strong>Configuraties<\/strong> en geef prioriteit aan tijdgevoelige, kortstondige gegevens. Als ik \u2018volatile-lru\u2019 of \u2018volatile-lfu\u2019 gebruik, vervangt Redis alleen sleutels waarvan de geldigheidsduur is verstreken \u2013 handig wanneer cache en permanente waarden naast elkaar bestaan. Ik verdeel caches vaak op basis van gegevenstypen: sessies op LRU, productcatalogi op LFU, om de respectievelijke sterke punten optimaal te benutten. Een slimme TTL-keuze voorkomt dat verouderde vermeldingen onnodig RAM-geheugen bezetten en verwijderingen veroorzaken. Zo houd ik het geheugen schoon, zonder nuttige <strong>Sneltoetsen<\/strong> te verliezen.<\/p>\n\n<p>Belangrijk: een beleid is van toepassing <strong>per instantie<\/strong>. Je kunt op betrouwbare wijze verschillende beleidsregels per gegevenstype toepassen door afzonderlijke Redis-instanties of duidelijk afgebakende caches te gebruiken. Namespaces op zich veranderen het beleid niet; ze helpen echter wel bij het gericht ongeldig maken en bij het meten.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/entwickler_schreibtisch_6354.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktijktest: beginnen met LRU, vervolgens gericht overschakelen naar LFU<\/h2>\n\n<p>Ik begin vaak met <strong>LRU<\/strong>, omdat het intu\u00eftief is en snel resultaten oplevert. Vervolgens identificeer ik caches met permanente hotkeys en schakel ik selectief over naar LFU. Deze aanpak minimaliseert het risico, omdat je alleen wijzigingen aanbrengt op plaatsen waar datapatronen de frequentielogica echt belonen. Met canaries en A\/B-tests meet ik de hit-rate en latentie voor en na de omschakeling. Zo optimaliseer ik stap voor stap, in plaats van de gehele <strong>Platform<\/strong> in \u00e9\u00e9n klap om te schakelen.<\/p>\n\n<h3>Een beproefd migratietraject<\/h3>\n<ul>\n  <li>Een uitgangspunt vaststellen: het huidige trefpercentage, het aantal uitzettingen, het 95e en 99e percentiel van de latentie vastleggen.<\/li>\n  <li>Pilot-cache selecteren: stabiel, vooral voor lezen bedoeld, met duidelijke sneltoetsen.<\/li>\n  <li>LFU inschakelen, <strong>lfu-verval-tijd<\/strong> conservatief instellen, <strong>maxmemory-samples<\/strong> verhogen.<\/li>\n  <li>Houd rekening met een opwarmfase en blijf deze in de gaten houden totdat de waarden stabiel zijn geworden.<\/li>\n  <li>Vergelijk de statistieken en pas daarna in kleine stapjes aanpassingen door.<\/li>\n<\/ul>\n\n<h2>Veelvoorkomende valkuilen in apps (bijv. WordPress)<\/h2>\n\n<p>In contentsystemen leiden onjuiste TTL\u2019s en ongeschikte <strong>Sleutels<\/strong> dit leidt al snel tot een stortvloed aan verwijderingen. Controleer of dynamische pagina\u2019s onbedoeld in de cache worden opgeslagen of dat te grote waarden het geheugen overbelasten. Zorg voor een correct \u2018invalidate\u2019-gedrag na publicaties, zodat verouderde inhoud verdwijnt en er ruimte vrijkomt. Deze handleiding helpt je bij het herkennen van typische foutpatronen in de CMS-omgeving: <a href=\"https:\/\/webhosting.de\/nl\/configuratiefout-in-de-redis-objectcache-prestatieoptimalisatie-van-wordpress\/\">Fout in de objectcache<\/a>. Als je op de juiste manier uitsluit, realistische TTL\u2019s instelt en het juiste beleid kiest, stijgen de hit-rate en <strong>Snelheid<\/strong> meetbaar.<\/p>\n\n<p>Andere anti-patronen uit de praktijk:<\/p>\n<ul>\n  <li><strong>Grote afzonderlijke objecten<\/strong> (bijv. enorme JSON-blobs) verdringen veel kleine, nuttige sleutels. Oplossing: gegevens opsplitsen en alleen de daadwerkelijk gebruikte segmenten in de cache opslaan.<\/li>\n  <li><strong>Donderende kachel<\/strong>: Veel gelijktijdige missers voor dezelfde sleutel. Oplossing: Request-Coalescing\/Locks, korte jitter bij TTL's, zodat vernieuwingen gespreid plaatsvinden.<\/li>\n  <li><strong>Scanvervuiling<\/strong>: Batch-leesbewerkingen zonder hergebruik. Oplossing: aparte instantie\/naamruimte, LRU daar met meer geheugen of de workloads bewust niet in de cache opslaan.<\/li>\n  <li><strong>Onduidelijke ongeldverklaring<\/strong>: Oude versies vullen de cache. Oplossing: Duidelijke sleutelschema\u2019s (bijv. versievoorvoegsels) en deterministische invalidatiepaden.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis-eviction-policy-7264.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Samenvatting: Hoe ik de keuze maak<\/h2>\n\n<p>Ik stel <strong>LRU<\/strong> wanneer actualiteit de beste heuristiek biedt voor toekomstige bezoeken \u2013 bijvoorbeeld bij sessies, dashboards en live-API\u2019s. Ik maak er gebruik van <strong>LFU<\/strong>, als er duidelijke, permanente hotkeys zijn die ik ook tijdens piekbelastingen wil beschermen. Monitoring laat me zien of evictions de overhand krijgen of dat de hit-rate daalt; dan pas ik samples, TTL\u2019s en decay aan. Met een zorgvuldige platformkeuze, een slimme opslaglimiet en afzonderlijke caches per gegevenstype haal ik constant meer uit het systeem. Zo blijft de cache snel, voorspelbaar en afgestemd op het toegangs patroon \u2013 zonder giswerk.<\/p>","protected":false},"excerpt":{"rendered":"<p>Om je cache optimaal te configureren, is het belangrijk dat je begrijpt hoe Redis-eviction met Redis LFU en Redis LRU werkt \u2013 dit artikel geeft je een directe vergelijking en helpt je bij het kiezen van het juiste beleid.<\/p>","protected":false},"author":1,"featured_media":20955,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20962","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"148","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Redis LFU","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20955","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20962","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=20962"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20962\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/20955"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=20962"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=20962"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=20962"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}