{"id":20116,"date":"2026-07-29T08:34:12","date_gmt":"2026-07-29T06:34:12","guid":{"rendered":"https:\/\/webhosting.de\/redis-memory-management-speicher-optimal-konfigurieren-performance-cache\/"},"modified":"2026-07-29T08:34:12","modified_gmt":"2026-07-29T06:34:12","slug":"redis-memory-management-optimally-configuring-memory-for-performance-and-caching","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/redis-memory-management-speicher-optimal-konfigurieren-performance-cache\/","title":{"rendered":"Redis Memory Management \u2013 Optimizing Memory Configuration for Maximum Performance"},"content":{"rendered":"<p>I configure Redis memory so that it remains predictable: clear limits, appropriate eviction policies, well-defined TTLs, and continuous monitoring prevent latency spikes and data loss. This guide provides specific settings for <strong>maxmemory<\/strong>, eviction, defragmentation, and data structures, so that Redis operates reliably and quickly under load.<\/p>\n\n<h2>Key points<\/h2>\n<ul>\n  <li><strong>maxmemory<\/strong> Calculate realistically and use that as a safety margin<\/li>\n  <li><strong>Eviction policy<\/strong> Choose one that matches the cache pattern<\/li>\n  <li><strong>TTL design<\/strong> Combine Jitter with Stampedes<\/li>\n  <li><strong>Defragmentation<\/strong> Activate and review key metrics<\/li>\n  <li><strong>Monitoring<\/strong> with alerts starting at ~75 % utilization<\/li>\n<\/ul>\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\/07\/redis-speicher-management-6823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Understanding Redis Storage: Planning Instead of Gut Feelings<\/h2>\n<p>I always plan for a storage budget that accounts for data, <strong>Overhead<\/strong> and reserves. In addition to keys and values, replication, client buffers, AOF\/RDB persistence, and internal structures consume additional RAM. Anyone who only considers the volume of user data underestimates the actual memory usage and risks bottlenecks. I first calculate the active data set, add 20\u201340 % overhead depending on the features, and reserve additional space for the operating system and tools. This ensures that the instance remains responsive even during peak loads and achieves consistent latencies.<\/p>\n\n<h2>Setting maxmemory Correctly: Defining the Allocation Range<\/h2>\n<p>I set <strong>maxmemory<\/strong> Typically set to 50\u201375 % of the server\u2019s RAM to ensure that kernel caches, agents, and logging have enough headroom. On dedicated cache hosts, I often start with 70\u201375 %; on shared machines, I\u2019m more conservative. This setting is configured in redis.conf (e.g., \u201cmaxmemory 2gb\u201d) or at runtime via \u201cCONFIG SET maxmemory 2gb\u201d. Once the limit is reached, the eviction policy kicks in or write operations fail\u2014which I deliberately use as a protective mechanism. Ignoring this limit can lead to unpredictable out-of-memory situations.<\/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\/07\/redis_memory_mgmt_setup_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Select Eviction Policies Carefully<\/h2>\n<p>I'll pass on the <strong>Eviction<\/strong>-Adjust the cache policy to match the access pattern, as it determines the hit rate and stability. For traditional caches, \u201callkeys-lru\u201d usually works best, since rarely used keys are evicted first. In setups with consistent TTLs, \u201cvolatile-lru\u201d can make sense because only expiring keys are affected. I only use random policies like \u201callkeys-random\u201d when no usage data is available. Experience shows that a clear policy, consistent TTLs, and a realistic `maxmemory` setting result in predictable behavior under load.<\/p>\n\n<h3>LRU vs. LFU and Fine-Tuning Sampling<\/h3>\n<p>When dealing with highly skewed access patterns, I like to rely on <strong>LFU<\/strong>-Policies (\u201callkeys-lfu\u201d or \u201cvolatile-lfu\u201d), because they keep frequently accessed items in the cache more reliably. Via <em>lfu-log-factor<\/em> I control the sensitivity to access frequency using <em>lfu-decay-time<\/em> how quickly \u201cpopularity\u201d fades. This affects LRU\/LFU <em>maxmemory-samples<\/em> The quality of the selection: 5 is the default; 10\u201315 improves decision-making with moderate CPU overhead. I measure the impact because higher sample counts can slightly increase latency but make evictions more efficient.<\/p>\n\n<h2>TTL Strategies for Managing Storage Pressure<\/h2>\n<p>I assign a <strong>TTL<\/strong>, so that outdated entries are automatically removed. Different lifetimes for pages, objects, and sessions keep memory usable and increase the hit rate. A small random component in the TTL prevents \u201cstampedes\u201d when many keys expire simultaneously. If you use \u201cvolatile-*,\u201d make sure that relevant keys actually have a TTL. I regularly review expiration patterns and adjust the times based on actual access data.<\/p>\n\n<h3>Fine-Tuning Active-Expire Effort and Triggers<\/h3>\n<p>I often increase the values for many TTL keys <em>active-expire-effort<\/em>, so that background scans quickly remove expired entries without blocking the server. I combine this with slightly staggered TTLs (jitter 5\u201310 %) to prevent simultaneous expirations and thus avoid a sudden surge in rebuild requests. In workloads with large, infrequently read objects, I enable <em>lazyfree-lazy-expire<\/em>, to handle deallocation in the background and avoid latency spikes caused by memory deallocation.<\/p>\n\n<h2>Reducing Fragmentation: activedefrag and Monitoring<\/h2>\n<p>I'm activating the active <strong>Defragmentation<\/strong> for dynamic datasets, to fill memory gaps. A fragmentation ratio significantly above 1.0 indicates that more physical RAM is being used than necessary. Starting at around 1.4, I assess the situation more closely and decide whether to fine-tune defragmentation or redistribute data. Instances that have been running for a particularly long time with highly fluctuating key sizes benefit measurably. This allows me to avoid unnecessary memory usage and keep latencies stable.<\/p>\n\n<h3>Configuring Jemalloc and the Operating System Correctly<\/h3>\n<p>I make sure that THP (Transparent Huge Pages) is disabled and that the host isn't swapping, because both of these factors negatively impact latency. <em>vm.overcommit_memory=1<\/em> Prevents fork failures during RDB\/AOF rewrites; nevertheless, I'm allowing for additional headroom (10\u201330 %) to buffer copy-on-write spikes. On Linux, this helps <em>MEMORY PURGE<\/em> occasionally, to adjust RSS to the actual usage level. For defragmentation, I prefer <em>active_defrag_cycle_min\/max<\/em> and <em>activedefrag-ignore-bytes<\/em> so that the machine runs smoothly but not too fast.<\/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\/07\/redis-memory-optimization-6382.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Using Data Structures and Encodings Efficiently<\/h2>\n<p>I choose data types based on memory profile, not just for convenience, because every byte <strong>counts<\/strong>. Small hashes, lists, sets, and sorted sets often benefit from compact encodings like listpack. I split very large values into manageable blocks so that updates remain granular and evictions are more precise. For large fields that are rarely read, I use application-level compression before writing. Short key names reduce the overhead per entry and add up significantly when dealing with millions of keys.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Data Type<\/th>\n      <th>Use<\/th>\n      <th>Encoding Tip<\/th>\n      <th>Storage Note<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>String<\/td>\n      <td>Individual values, counters<\/td>\n      <td>Directly, or with compression in the app if necessary<\/td>\n      <td><strong>Big Keys<\/strong> Avoid splitting values<\/td>\n    <\/tr>\n    <tr>\n      <td>Hash<\/td>\n      <td>Objects with Fields<\/td>\n      <td>listpack when there are only a few fields<\/td>\n      <td>Group small objects; use fields sparingly<\/td>\n    <\/tr>\n    <tr>\n      <td>Cunning<\/td>\n      <td>Queues, Feeds<\/td>\n      <td>listpack for short lists<\/td>\n      <td>Limit Length, Use Trimming<\/td>\n    <\/tr>\n    <tr>\n      <td>Set\/ZSet<\/td>\n      <td>Quantities, Rankings<\/td>\n      <td>listpack\/skiplist by size<\/td>\n      <td>Segmenting Large Collections<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>I regularly run \u201credis-cli \u2013bigkeys\u201d to identify outliers and analyze the memory profile <strong>targeted<\/strong> to optimize performance. This allows the instance to keep more relevant data in RAM and process requests faster.<\/p>\n\n<h3>Fine-Tuning Encoding Thresholds<\/h3>\n<p>I check <em>hash-max-listpack-entries\/value<\/em>, <em>set-max-intset-entries<\/em> and <em>zset-max-listpack-entries\/value<\/em>, to use Listpack encodings for as long as possible without overloading the CPU. For lists, I control this with <em>list-max-listpack-size<\/em> and <em>list-compress-depth<\/em> Compression. I limit streams with <em>stream-node-max-bytes\/entries<\/em>. Taken together, these techniques often result in double-digit percentage savings in RAM usage.<\/p>\n\n<h2>Monitoring and Alerts: Early Detection<\/h2>\n<p>I track Used Memory Percentage, Evictions, Cache Hit Rate, and Fragmentation Ratio because <strong>Trends<\/strong> are more important than snapshots. If utilization consistently rises above about 75 %, I plan capacity expansions. A rising eviction rate coupled with a falling hit rate signals incorrect policies, TTLs that are too short, or a budget that\u2019s too small. I set up alerts and correlate peaks with deployments, traffic spikes, or batch jobs. This allows me to address the root causes rather than just mitigating the symptoms.<\/p>\n\n<h3>Storage Diagnostics: Metrics and Commands<\/h3>\n<p>I use \u201cINFO memory,\u201d \u201cMEMORY STATS,\u201d and \u201cMEMORY DOCTOR\u201d to identify patterns. With \u201cMEMORY USAGE key SAMPLES N,\u201d I determine the exact footprint of objects. In addition to \u201c\u2013bigkeys,\u201d I use \u201credis-cli \u2013memkeys\u201d and \u201c\u2013hotkeys,\u201d when available, to specifically optimize memory-intensive or particularly frequently queried keys. \u201cLATENCY DOCTOR\u201d helps determine whether evictions, defrags, or forks are causing latency spikes.<\/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\/07\/redis_speicherverwaltung_5683.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Planning for Scalability: Vertical vs. Cluster<\/h2>\n<p>I scale vertically when individual nodes need more RAM or CPU, and horizontally when sharding reduces latency and <strong>Capacity<\/strong> better distributed. Before upgrades, I adjust limits, snapshots, and replica settings to ensure a smooth transition without an eviction storm. When traffic fluctuates significantly, a cluster helps distribute the load on hot keys across multiple nodes. For hosting scenarios, I carefully check isolation, for example, using <a href=\"https:\/\/webhosting.de\/en\/redis-shared-vs-dedicated-performance-security-cacheboost\/\">Shared vs. dedicated<\/a>. A clear strategy prevents costly overprovisioning and reduces risks associated with load changes.<\/p>\n\n<h3>Rebalancing and Large Keys in the Cluster<\/h3>\n<p>I schedule rebalancing windows so that large keys are not migrated and evicted at the same time. Large keys put a strain on the MIGRATE process and can cause client buffers to grow excessively. I therefore segment large values on the application side to ensure that cluster shifts remain granular and low-risk.<\/p>\n\n<h2>Redis in a Hosting Environment: WordPress in Practice<\/h2>\n<p>I set clear TTLs for the page cache, object cache, and sessions in the WordPress stack so that the memory <strong>easy to grip<\/strong> remains. Typical configurations use \u201cmaxmemory-policy allkeys-lru\u201d and set the limit to 60\u201375 % of RAM. For the object cache, I monitor key names, as extremely long prefixes create noticeable overhead. I systematically address common errors related to prefixing, TTLs, or misses; see <a href=\"https:\/\/webhosting.de\/en\/redis-object-cache-configuration-error-wordpress-performance-tuning\/\">Avoiding Object Cache Errors<\/a>. Active defragmentation stabilizes long-running sites with uneven traffic spikes.<\/p>\n\n<h3>TTL Classes and Stamp Avoidance<\/h3>\n<p>I define TTL classes (e.g., HTML pages\u2014short, query results\u2014medium, user profiles\u2014longer) and assign each class 5\u201315 % of jitter. I monitor spikes in misses after deployments: If many caches are being refreshed simultaneously, I temporarily increase TTLs or use warm-up jobs to smooth out the load.<\/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\/07\/redis_memory_5381.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Persistence and Replication: Calculating the Storage Budget<\/h2>\n<p>I always factor in additional time for AOF\/RDB and replication <strong>Memory<\/strong>, because snapshots and replica buffers consume RAM. Large snapshots can cause short-term memory pressure when concurrent writes are in progress. If you use replicas, plan for peak loads during resync and check buffer sizes. I summarize details on strategies and trade-offs in the post on <a href=\"https:\/\/webhosting.de\/en\/redis-persistence-rdb-aof-hosting-server-guide\/\">RDB and AOF<\/a> together. This ensures that the instance remains responsive even during backup and failover events.<\/p>\n\n<h3>Fork Overheads, Backlog, and Asynchronous Release<\/h3>\n<p>I plan to allocate 10\u201330 % of additional RAM for RDB\/AOF rewrites due to copy-on-write. <em>aof-use-rdb-preamble<\/em> speeds up restarts, <em>auto-aof-rewrite-percentage\/size<\/em> Control predictable rewrites. For replication, I size <em>repl-backlog-size<\/em> so that brief network issues don't force a full resync. I set <em>replica-ignore-maxmemory<\/em> deliberately depending on the role, so that replicas don't evict when they're catching up. In the event of massive deletions, I activate <em>lazyfree lazy eviction<\/em> and <em>lazyfree-lazy-server-del<\/em>, to decouple memory sharing from the critical query time.<\/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\/07\/redis-speicheroptimum-1834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Client Buffers and Pub\/Sub: Setting Hard Limits<\/h2>\n<p>I set <em>client output buffer limit<\/em> for <em>normal<\/em>, <em>replica<\/em> and <em>pubsub<\/em> strictly, so that a single client doesn't cause the instance to hit an OOM. When there's a lot of Pub\/Sub traffic, I set the Pub\/Sub buffers conservatively. I also keep <em>client-query-buffer-limit<\/em> I keep an eye on this to ensure that individual, large commands don't unexpectedly tie up RAM. In multi-tenant environments, I separate workloads into their own instances if the buffer profile varies significantly.<\/p>\n\n<h2>Specific Configuration: A Robust Startup Profile<\/h2>\n<p>I often start with the following profile and adjust it based on real metrics:<\/p>\n<pre><code>maxmemory 70%\nmaxmemory-policy allkeys-lfu\nmaxmemory-samples 10\n\n# TTL\/Expire\nactive-expire-effort 7\nlazyfree-lazy-expire yes\n\n# Lazyfree for Large Deletions\nlazyfree-lazy-eviction yes\nlazyfree-lazy-server-del yes\n\n# Defragmentation\nactivedefrag yes\nactivedefrag-ignore-bytes 100mb\nactivedefrag-cycle-min 10\nactivedefrag-cycle-max 50\n\n# Data Structures\nhash-max-listpack-entries 512\nhash-max-listpack-value 256\nzset-max-listpack-entries 512\nzset-max-listpack-value 128\nset-max-intset-entries 512\nlist-max-listpack-size -2\nlist-compress-depth 1\n\n# Replication\/Buffer\nrepl-backlog-size 256mb\nclient-output-buffer-limit normal 0 0 0\nclient-output-buffer-limit replica 256mb 64mb 60\nclient-output-buffer-limit pubsub 64mb 16mb 60\n<\/code><\/pre>\n<p>I view this as a starting point, not as a rule set in stone. Every environment has its own data formats, traffic patterns, and latency budgets.<\/p>\n\n<h2>Load Testing: Verify Instead of Assume<\/h2>\n<p>I test configurations using realistic load tests (e.g., mixed GET\/SET\/EXPIRE profiles), monitoring evictions, hit rate, P99 latency, and fragmentation ratio. I also simulate events such as AOF rewrites, RDB snapshots, replica resyncs, and mass deletes to measure headroom and lazyfree effects. Only when the path remains stable through peak loads do I deploy changes to production.<\/p>\n\n<h2>Containers and Multi-Tenancy: Setting Clear Boundaries<\/h2>\n<p>I set <strong>maxmemory<\/strong> below the container limit so that the cgroup OOM killer doesn't kick in first. I isolate workloads with different buffer and TTL profiles into separate instances instead of mixing databases\u2014because Redis shares <em>maxmemory<\/em> not per database. In Kubernetes, I plan PodDisruptionBudgets and rolling updates so that simultaneous warm-ups do not cause eviction waves.<\/p>\n\n<h2>Practical Checklist and Implementation<\/h2>\n<p>I start with a clear <strong>Step-by-Step Plan<\/strong>: Step 1 determines the memory budget, including overhead and reserve; Step 2 sets maxmemory to 50\u201375 % and selects the appropriate policy; Step 3 defines TTLs with low jitter for all cache keys; Step 4 optimizes data structures, splits large keys, and shortens names; Step 5 enables `activedefrag` and monitors the fragmentation ratio; Step 6 sets up metrics and alerts; Step 7 realistically tests peak loads and plans for scaling in a timely manner. I measure every change rather than just assuming it. That\u2019s the only way I can identify real progress. This rhythm establishes a reliable operational model.<\/p>\n\n<h2>Concluding Remarks: Memory as an Active Performance Tuning Tool<\/h2>\n<p>I treat Redis storage as a controllable <strong>Lever<\/strong> for latency, throughput, and reliability. Setting limits properly, choosing policies thoughtfully, and consistently using TTLs ensures predictable behavior under pressure. Monitoring, fragmentation control, and structured data types extract additional capacity from the same RAM. Scaling then becomes a planned step rather than an emergency measure. This keeps Redis memory manageable, the cache hit rate high, and the application fast\u2014from small projects to high-traffic platforms.<\/p>","protected":false},"excerpt":{"rendered":"<p>A Practical Guide to Redis Memory Management: How to Optimize Memory Configuration, Including maxmemory, Eviction Policies, and Monitoring\u2014with a Focus on Redis Memory for Maximum Performance.<\/p>","protected":false},"author":1,"featured_media":20109,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20116","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":"126","_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 memory","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":"20109","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20116","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=20116"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20116\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/20109"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=20116"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=20116"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=20116"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}