{"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":"redis-lfu-vs-lru-eviction-policies-a-comparison-for-cache-optimization","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/redis-lfu-vs-lru-eviction-policies-vergleich-cache-optimierung\/","title":{"rendered":"Redis LFU vs. LRU: Which Eviction Policy Is the Right One?"},"content":{"rendered":"<p>Redis LFU and LRU determine which keys are evicted from the cache when resources are scarce\u2014and thus determine <strong>Hit rate<\/strong>, response time, and memory usage. I'll show you when the frequency-based LFU policy or the recency-based LRU policy is more appropriate, how to configure them, and what effects \"allkeys-lfu\" versus \"allkeys-lru\" have in everyday use; the focus keyword <strong>Redis LFU<\/strong> is at the heart of this.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>Recency<\/strong> vs. <strong>Frequency<\/strong>: LRU favors the most recent accesses; LFU favors frequent accesses.<\/li>\n  <li><strong>Approximation<\/strong> In Redis: Both policies use samples based on `maxmemory-samples`.<\/li>\n  <li><strong>Workloads<\/strong> Choose: Sessions\/Dashboards \u2192 LRU, Bestsellers\/Rankings \u2192 LFU.<\/li>\n  <li><strong>Tuning<\/strong> Make sure to set lfu-decay-time, maxmemory, and maxmemory-samples correctly.<\/li>\n  <li><strong>Monitoring<\/strong> Required: Continuously monitor the hit rate, evictions per second, and latency.<\/li>\n<\/ul>\n\n<h2>How Eviction Works in Redis<\/h2>\n\n<p>Redis stores data in RAM; if the process <strong>maxmemory<\/strong>, it must evict keys. This is exactly where policies like allkeys-lru and allkeys-lfu come into play; they determine which entries are evicted. I\u2019m focusing on these two variants because they take the entire dataset into account, not just keys with a TTL. Redis selects the key to be deleted via a sample, which you can configure with <strong>maxmemory-samples<\/strong> controls; more samples increase accuracy but consume CPU resources. This approach yields good results in large keyspaces without making management too costly.<\/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>Behind the Scenes: How Redis Implements LRU and LFU<\/h2>\n\n<p>Both policies run in Redis <strong>approximately<\/strong>, to maintain a consistently high speed. LRU stores a timestamp for the last access for each object. During eviction, Redis takes a sample and discards the \u201eoldest\u201c candidate from the selection. In practice, this is extremely efficient and sufficiently accurate if you choose a sample size appropriate for the keyspace.<\/p>\n\n<p><strong>Redis LFU<\/strong> expands on this idea by adding a <strong>Compact Frequency Meter<\/strong>, which over time <strong>ages<\/strong> (Decay). Each access increases the usage counter not linearly, but in a damped manner, so that individual burst phases do not permanently saturate the counter. At the same time, a time decay ensures that past popularity eventually loses its weight. Through parameters such as <em>lfu-decay-time<\/em> (how quickly the history ages) and an internal log factor (how much the counters grow with each access)\u2014you balance these <em>responsiveness<\/em> against <em>Stability<\/em> Prioritization. Rule of thumb: Smaller decay values \u2192 faster adjustment; larger values \u2192 slower but more stable priorities.<\/p>\n\n<h2>LRU in Redis: Principles, Strengths, Pitfalls<\/h2>\n\n<p>LRU removes the oldest one <strong>unused<\/strong> It uses a key-based approach, thereby prioritizing recency. This logic aligns well with patterns involving temporal locality, such as sessions, live dashboards, or short-term API responses. Redis uses an approximated LRU: Entries carry a timestamp, and sampling selects the oldest candidate\u2014quickly and transparently. LRU reacts quickly to changes because recently used keys remain at the top while older ones are evicted. Large one-time scans can become problematic, as they fill the cache with short-lived values and push out important keys that are temporarily inactive <strong>suppress<\/strong>.<\/p>\n\n<p>Practical tip: If you use LRU and regularly run \u201ecold\u201c bulk queries (e.g., back-office reports), encapsulate these workloads in <em>separate<\/em> Caches, or plan for more generous ones <strong>maxmemory<\/strong>-Reserves. This helps you avoid cache pollution, in which valuable data that will be needed again soon is displaced.<\/p>\n\n<h2>LFU in Redis: Principles, Strengths, Pitfalls<\/h2>\n\n<p>LFU removes keys with low <strong>Frequency of Use<\/strong> and thus preserves long-term \u201ehot keys.\u201c The internal counter grows logarithmically and decays over time so that past popularity doesn\u2019t count indefinitely. This results in a balancing weighting: Frequently used data is retained longer, while individual outliers have little effect on priority. LFU often delivers a higher hit rate in catalogs, rankings, or feature caches because it keeps proven keys in memory. However, it reacts more slowly to new trends, which is why tuning <strong>lfu-decay-time<\/strong> remains important.<\/p>\n\n<p>For <strong>On\/Off Trends<\/strong> (e.g., marketing campaigns): Set the decay rate so that a new trend has a noticeable impact without short-term noise constantly resorting the cache. In many projects, the following approach has proven effective: start conservatively, then gradually accelerate until the hit rate remains stable under load.<\/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>Comparison: Recency vs. Frequency in Everyday Life<\/h2>\n\n<p>Essentially, LRU distinguishes between \u201elast used\u201c and LFU distinguishes between \u201ehow often used\u201c\u2014I make my selection based on the actual <strong>Workloads<\/strong>. For volatile, user-centric data, LRU usually feels more natural, since recent accesses often foreshadow future accesses. For popular product data or configurations, LFU works better because sustained popularity is what matters. In mixed scenarios, I separate caches by data type and apply different policies. The following table briefly summarizes the differences and gives you a quick <strong>Decision support<\/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>Priority<\/td>\n      <td><strong>Actuality<\/strong> the number of hits<\/td>\n      <td><strong>Frequency<\/strong> the number of hits<\/td>\n    <\/tr>\n    <tr>\n      <td>Response to a Pattern Change<\/td>\n      <td>Hurry\u2014the last time you used it counts<\/td>\n      <td>Moderate, since history plays a role<\/td>\n    <\/tr>\n    <tr>\n      <td>Recommended workloads<\/td>\n      <td>Sessions, Dashboards, Live APIs<\/td>\n      <td>Bestsellers, Rankings, Feature Caches<\/td>\n    <\/tr>\n    <tr>\n      <td>Sensitivity to \u201ePollution\u201c<\/td>\n      <td>Tends to be high for large scans<\/td>\n      <td>Rather low due to the frequency counter<\/td>\n    <\/tr>\n    <tr>\n      <td>Tuning Screws<\/td>\n      <td><strong>maxmemory-samples<\/strong><\/td>\n      <td><strong>lfu-decay-time<\/strong>, maxmemory-samples<\/td>\n    <\/tr>\n    <tr>\n      <td>Explainability<\/td>\n      <td>Very intuitive<\/td>\n      <td>Well, with regard to Decay<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Performance Impacts in Practice<\/h2>\n\n<p>With small data sets, the difference is often <strong>low<\/strong>; as the dataset grows, the wheat is separated from the chaff. LRU stands out due to its low CPU overhead for approximation and a clear rationale: a key is evicted because it was last left unused. LFU excels with consistent access patterns, as hot keys remain securely in RAM and the hit rate measurably increases. The trade-off lies in the necessary understanding of counters and decay, so that you react neither too sluggishly nor too aggressively. I verify the effects using profiling and metrics, rather than relying solely on intuition. <strong>decide<\/strong>.<\/p>\n\n<p>Also, plan for the <strong>cold start<\/strong> First: After a reboot or deployment, the cache is empty or \u201eunaware\u201c of access frequencies. LRU quickly stabilizes based on short-term locality. LFU naturally requires some warm-up time to identify true hot keys. Strategies such as <em>Prewarming<\/em> (proactively loading important keys) or staggered traffic ramping can help mitigate initial latency and misses.<\/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>Configuration and Tuning: The Most Important Options<\/h2>\n\n<p>I select the policy via <strong>maxmemory policy<\/strong>, typically allkeys-lru or allkeys-lfu, and less commonly volatile variants with a TTL focus. With <strong>maxmemory<\/strong> I set the hard threshold at which eviction begins and scale it based on the dataset size plus a safety margin. I control the sample size via <strong>maxmemory-samples<\/strong>; higher values improve the selection but require more CPU power. For LFU, <strong>lfu-decay-time<\/strong> This is crucial because it determines how quickly old accesses fade and new ones gain weight. You can find detailed instructions on memory sizing here: <a href=\"https:\/\/webhosting.de\/en\/redis-memory-management-optimally-configuring-memory-for-performance-and-caching\/\">Optimize Storage Configuration<\/a>.<\/p>\n\n<h3>Practical Tips for Everyday Use<\/h3>\n<p>To get started quickly, I work with clear defaults and iterate under load:<\/p>\n<ul>\n  <li>allkeys-lru + maxmemory-samples 7\u201310 for volatile, user-facing data<\/li>\n  <li><strong>Redis LFU<\/strong> (allkeys-lfu) + lfu-decay-time set to a conservative value (e.g., a moderate value) for stable hotkey workloads<\/li>\n<\/ul>\n<p>Set the configuration at runtime:<\/p>\n<pre><code>CONFIG SET maxmemory 8gb\nCONFIG SET maxmemory-policy allkeys-lru\nCONFIG SET maxmemory-samples 10\n# Switch to LFU:\nCONFIG SET maxmemory-policy allkeys-lfu\nCONFIG SET lfu-decay-time 5\n<\/code><\/pre>\n<p>In redis.conf, you define these same options permanently. I test changes first in staging with a representative load before deploying them to production.<\/p>\n\n<h3>Select the sample size<\/h3>\n<p><strong>maxmemory-samples<\/strong> This is a reliable tuning parameter: Higher values improve the accuracy of eviction candidates but consume CPU resources. As a rule of thumb, I start with 7\u201310 for large keyspaces and only reduce this value if CPU time becomes scarce. For small keyspaces, 5 samples are often sufficient.<\/p>\n\n<h2>Monitoring and Metrics: Measure Instead of Guess<\/h2>\n\n<p>I am constantly observing <strong>Hit rate<\/strong>, evictions, latencies, and memory usage to assess their interaction. If evictions rise sharply, I check RAM reserves, TTL strategies, and the selected policy. A declining hit rate often indicates that changing patterns are weakening the current policy or that data sets are not being cached separately enough. Latency spikes sometimes indicate that <strong>Samples<\/strong> or toward overly aggressive eviction. Regular load tests help me find the right balance between CPU usage, memory limits, and hit rate.<\/p>\n\n<p>Handy commands for quick checks:<\/p>\n<pre><code>INFO stats     # keyspace_hits, keyspace_misses, evicted_keys, expired_keys\nINFO memory    # used_memory, fragmentation, allocator_overhead\nLATENCY DOCTOR # Notes on spikes, e.g., forking or I\/O<\/code><\/pre>\n<p>The <strong>Hit rate<\/strong> I calculate it as hits \/ (hits + misses). A declining ratio amid rising evictions is a warning sign. <em>evicted_keys<\/em> in relation to traffic and <em>used_memory<\/em> indicates whether the policy needs to be triggered frequently. With <em>MEMORY USAGE key<\/em> You can identify oversized objects that disproportionately dominate your cache.<\/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 and Scaling Considerations: Choose Your Platform Carefully<\/h2>\n\n<p>Redis really shines in a <strong>high-performance<\/strong> A platform with plenty of RAM, low latency, and a reliable network connection. As projects grow, I avoid continuous operation at full capacity because eviction then triggers too frequently and the hit rate suffers. A good <a href=\"https:\/\/webhosting.de\/en\/redis-eviction-hosting-cache-strategy\/\">Hosting strategy<\/a> ensures that policies kick in when necessary and don't run constantly. When comparing options, I rely on premium providers like webhoster.de, whose infrastructure handles high loads smoothly and enables predictable capacity. As a result, the platform directly benefits from fewer evictions and better <strong>Response times<\/strong> and more consistent performance.<\/p>\n\n<h3>Cluster and Replica Considerations<\/h3>\n<p>In sharding setups (e.g., Redis Cluster), eviction decisions take effect <strong>per node<\/strong>. This means that headroom, policy, and tuning must be appropriate for each node, not just \u201eon average.\u201c Hot keys that are unevenly distributed across slots can push individual nodes to their limits sooner. Therefore, plan buffers per shard and monitor evictions at the node level. Replicas inherit the data state, including deleted keys; during load testing, keep in mind that additional replication can increase latency without the policy itself being at fault.<\/p>\n\n<h2>TTL Strategies and Mixed Policies<\/h2>\n\n<p>With TTL, I protect durable <strong>Configurations<\/strong> and prioritize time-sensitive, short-lived data. If I use volatile-lru or volatile-lfu, Redis only evicts keys that have expired\u2014which is helpful when cache and persistent values coexist. I often separate caches by data type: sessions on LRU, product catalogs on LFU, to take advantage of their respective strengths. A smart TTL choice prevents outdated entries from unnecessarily tying up RAM and triggering evictions. This way, I keep memory clean without losing useful <strong>Hot Keys<\/strong> to lose.<\/p>\n\n<p>Important: A policy applies <strong>per instance<\/strong>. You can reliably implement different policies for each data type by running separate Redis instances or clearly delineated caches. Namespaces alone do not change the policy; however, they help with targeted invalidation and measurement.<\/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>Practical Test: Start with LRU, then switch to LFU<\/h2>\n\n<p>I often start with <strong>LRU<\/strong>, because it\u2019s intuitive and delivers quick results. Afterward, I identify caches with consistent hot keys and selectively switch to LFU. This approach minimizes risk because you only make changes where data patterns truly benefit from the frequency-based logic. Using canaries and A\/B tests, I measure hit rates and latency before and after the switch. This way, I optimize step by step, rather than changing the entire <strong>Platform<\/strong> to switch over all at once.<\/p>\n\n<h3>A proven migration path<\/h3>\n<ul>\n  <li>Establish a baseline: Record the current hit rate, evictions, and the 95th and 99th percentiles of latency.<\/li>\n  <li>Select a pilot cache: a stable, read-heavy area with clear hotkeys.<\/li>\n  <li>Enable LFU, <strong>lfu-decay-time<\/strong> set conservatively, <strong>maxmemory-samples<\/strong> increase.<\/li>\n  <li>Plan for a warm-up phase and monitor the process until the counters have stabilized.<\/li>\n  <li>Compare metrics, and only then make small adjustments.<\/li>\n<\/ul>\n\n<h2>Common Pitfalls in Apps (e.g., WordPress)<\/h2>\n\n<p>In content management systems, incorrect TTLs and unsuitable <strong>Keys<\/strong> This can quickly lead to a flood of evictions. Check whether dynamic pages are being cached unintentionally or whether values that are too large are causing the memory to overflow. Ensure proper invalidation behavior after publications so that outdated content is removed and space is freed up. This guide will help you identify typical error scenarios in a CMS environment: <a href=\"https:\/\/webhosting.de\/en\/redis-object-cache-configuration-error-wordpress-performance-tuning\/\">Object Cache Error<\/a>. If you invalidate properly, set realistic TTLs, and choose the right policy, the hit rate and <strong>Speed<\/strong> measurable.<\/p>\n\n<p>Additional anti-patterns from real-world experience:<\/p>\n<ul>\n  <li><strong>Large Individual Properties<\/strong> (e.g., huge JSON blobs) crowd out many small, useful keys. Solution: Split the data into smaller chunks and cache only the segments that are actually used.<\/li>\n  <li><strong>Thundering stove<\/strong>: Many simultaneous misses for the same key. Solution: Request coalescing\/locks, short jitter in TTLs so that renewals occur in a distributed manner.<\/li>\n  <li><strong>Scan Pollution<\/strong>: Batch reads without reuse. Solution: Separate instance\/namespace, use LRU there with more generous memory, or deliberately avoid caching those workloads.<\/li>\n  <li><strong>Unclear Invalidation<\/strong>: Old versions fill up the cache. Solution: Clear key schemes (e.g., version prefixes) and deterministic invalidation paths.<\/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>Summary: How I make the choice<\/h2>\n\n<p>I set <strong>LRU<\/strong> when recency provides the best heuristic for future access\u2014such as with sessions, dashboards, and live APIs. I\u2019ll use <strong>LFU<\/strong>, ...when there are clear, persistent hot keys that I want to protect even during peak loads. Monitoring shows me whether evictions are getting out of hand or the hit rate is dropping; then I adjust samples, TTLs, and decay. With a well-chosen platform, a smart memory limit, and separate caches for each data type, I consistently get more out of the system. This keeps the cache fast, predictable, and aligned with the access pattern\u2014without any guesswork.<\/p>","protected":false},"excerpt":{"rendered":"<p>To configure your cache optimally, you should understand how Redis eviction works with Redis LFU and Redis LRU\u2014this article provides a direct comparison and helps you choose the right policy.<\/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":"143","_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\/en\/wp-json\/wp\/v2\/posts\/20962","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=20962"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20962\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/20955"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=20962"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=20962"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=20962"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}