Add tideways_redis_keys_enabled setting to Tideways documentation

docs/best-practices/performance/how-to-set-up-tideways.md

@@ -45,6 +45,16 @@ You can assign an environment label (for example when this node is a staging ser
 hypernode-systemctl settings tideways_env_name staging
 ```
 
+#### Optional: Collect Keys for Redis Instrumentation
+
+Enable Redis key collection to see which keys are accessed by Redis operations in your traces. This provides more detailed insights when debugging Redis-related performance issues.
+
+```bash
+hypernode-systemctl settings tideways_redis_keys_enabled True
+```
+
+**Please note:** This setting can have privacy implications if your application uses personal identifiable information (such as email addresses or IP addresses) inside Redis keys. For more information, see the [Tideways documentation on Redis instrumentation](https://support.tideways.com/documentation/setup/configuration/advanced-instrumentation.html#collect-keys-for-redis-instrumentation).
+
 ### Activation through Control Panel
 
 It’s also possible to configure Tideways in the Control Panel.

docs/hypernode-platform/varnish/improving-varnish-hit-rate-on-hypernode.md

@@ -1,7 +1,9 @@
 ---
 myst:
   html_meta:
-    description:  Learn how to improve your Varnish cache hit rate on Hypernode by identifying automatic cache purges, analyzing hit/miss patterns, and optimizing URL normalization to boost performance and efficiency.
+    description: Learn how to improve your Varnish cache hit rate on Hypernode by
+      identifying automatic cache purges, analyzing hit/miss patterns, and optimizing
+      URL normalization to boost performance and efficiency.
     title: Improving Varnish Cache Hit Rate on Hypernode
 ---
 
@@ -17,13 +19,15 @@ This guide takes you step-by-step from verifying that your cache is active to di
 ## Before You Begin
 
 Typical cache hit rates:
-- **Below 10%** → Cache is barely reused  
-- **30–70%** → Improvement possible (depends on shop type and traffic patterns) 
-- **Above 80%** → Generally healthy for most shops 
+
+- **Below 10%** → Cache is barely reused
+- **30–70%** → Improvement possible (depends on shop type and traffic patterns)
+- **Above 80%** → Generally healthy for most shops
 
 Keep in mind:
-- Staging environments typically have low hit rates  
-- B2B webshops often have lower hit rates due to personalization  
+
+- Staging environments typically have low hit rates
+- B2B webshops often have lower hit rates due to personalization
 - Recently flushed caches temporarily reduce hit rates until the cache warms up
 
 Cache hit rate should always be evaluated in context. Traffic volume, personalization, and recent deployments directly affect cache reuse.
@@ -32,11 +36,11 @@ Cache hit rate should always be evaluated in context. Traffic volume, personaliz
 
 A low hit rate does not always indicate a problem. It is normal when:
 
-- Traffic volume is low  
-- The cache was recently flushed  
-- Most visitors are logged in  
-- The shop uses heavy personalization  
-- You are working in a staging environment  
+- Traffic volume is low
+- The cache was recently flushed
+- Most visitors are logged in
+- The shop uses heavy personalization
+- You are working in a staging environment
 
 Investigate further only if traffic is stable, the cache is warmed up, and the hit rate remains consistently low.
 
@@ -46,7 +50,8 @@ Ensure Varnish is properly enabled on your vhost and configured in your
 application (e.g. Magento 2).
 
 For Magento 2, verify:
-- That Varnish is enabled on the vhost  
+
+- That Varnish is enabled on the vhost
 - Varnish is selected as the caching application
 - The correct VCL is generated and loaded
 - Full Page Cache (FPC) is enabled
@@ -60,10 +65,13 @@ Tip: The [elgentos/magento2-varnish-extended](https://github.com/elgentos/magent
 ## Step 2 — Check if Pages Are Being Cached
 
 Using `varnishncsa` from the CLI to see in real time which pages are cached and which are not:
-```console 
+
+```console
 varnishncsa -F '%U%q %{Varnish:hitmiss}x'
 ```
+
 Look for:
+
 - `hit` → Served from Varnish
 - `miss` → Served from backend
 
@@ -75,16 +83,16 @@ curl -I https://yourdomain.com
 
 Review the following headers:
 
-- **`Set-Cookie`**  
+- **`Set-Cookie`**\
   If a Set-Cookie header (such as PHPSESSID) is present, Varnish will typically not cache the response.
 
-- **`Cache-Control`**  
+- **`Cache-Control`**\
   Should **not** contain `private`, `no-store`, or `no-cache`.
 
-- **`Age`**  
+- **`Age`**\
   Indicates how long (in seconds) the object has been cached.
 
-- **`X-Magento-*`**  
+- **`X-Magento-*`**\
   Provides Magento cache/debug information (visible in developer mode).
 
 If most responses return `MISS` (for example in `X-Magento-Cache-Debug` or similar headers), caching is not being reused effectively.
@@ -101,6 +109,7 @@ varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss
 ```
 
 This shows:
+
 - `MAIN.cache_hit` → Cached responses served
 - `MAIN.cache_miss` → Requests sent to backend
 
@@ -113,6 +122,7 @@ varnishlog
 ```
 
 Look for:
+
 - `VCL_call HIT` → Served from Varnish
 - `VCL_call MISS` → Served from backend
 - `Age` → Indicates how long (in seconds) the object has been cached.
@@ -125,6 +135,7 @@ Alternatively, reuse the varnishncsa command from Step 2 for live hit/miss monit
 ### 1. Pages Bypassing Varnish
 
 Some pages are intentionally not cached:
+
 - Checkout
 - Customer account pages
 - Requests containing `Set-Cookie` headers
@@ -136,6 +147,7 @@ This is expected behavior.
 If cache clears happen frequently, cache reuse becomes nearly impossible.
 
 Common causes:
+
 - Stock or pricing integrations
 - Magento cron jobs performing full cache purges
 - Extensions invalidating excessive cache entries
@@ -149,12 +161,14 @@ flushes.
 Tracking parameters create separate cache entries for identical content.
 
 Examples:
+
 - `utm_source`
 - `utm_medium`
 - `gclid`
 - `fbclid`
 
 Example problem:
+
 - /product-x
 - /product-x?utm_source=google
 
@@ -172,6 +186,7 @@ The [elgentos/magento2-varnish-extended](https://github.com/elgentos/magento2-va
 Different URL formats fragment your cache.
 
 Examples:
+
 - `/category` vs `/category/`
 - `?Color=Red` vs `?color=red`
 - Unsorted query parameters
@@ -190,6 +205,7 @@ grep -R "cacheable=\"false\"" app/code vendor
 ```
 
 If found:
+
 - Verify the block truly needs to be dynamic
 - Remove cacheable="false" if unnecessary
 - Use AJAX or Customer Data Sections for dynamic content
@@ -204,7 +220,7 @@ Enable developer mode temporarily for debugging purposes:
 magerun2 deploy:mode:set developer
 ```
 
-Or: 
+Or:
 
 ```console
 php bin/magento deploy:mode:set developer
@@ -215,25 +231,31 @@ php bin/magento deploy:mode:set developer
 ### varnishlog
 
 Inspect detailed request handling:
+
 ```console
 varnishlog
 ```
+
 Look for recurring MISS patterns on pages that should be cacheable.
 
 ### varnishncsa
 
 Show hit/miss per URL:
+
 ```console
 varnishncsa -F '%U%q %{Varnish:hitmiss}x'
 ```
+
 Filter for hits:
+
 ```console
 varnishncsa -F '%U%q %{Varnish:hitmiss}x' | grep hit
 ```
 
 ### Hypernode Insights (If Available)
 
 Use Hypernode Insights to:
+
 - Monitor hit/miss ratios
 - Detect purge spikes
-- Correlate cache drops with deployments or cron jobs
+- Correlate cache drops with deployments or cron jobs