{"id":21379,"date":"2026-09-14T08:34:50","date_gmt":"2026-09-14T06:34:50","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-query-response-time-plugin-database-monitoring-analyse-focus\/"},"modified":"2026-09-14T08:34:50","modified_gmt":"2026-09-14T06:34:50","slug":"mariadb-query-response-time-plugin-database-monitoring-analysis-focus","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/mariadb-query-response-time-plugin-database-monitoring-analyse-focus\/","title":{"rendered":"Using the MariaDB Query Response Time Plugin for Efficient Performance Monitoring"},"content":{"rendered":"<p>I use the MariaDB Query Response Time plugin to <strong>query response<\/strong> To visualize metrics by interval and quickly identify bottlenecks. This way, I can see within seconds if queries are frequently ending up in a slow bucket, and based on that, I can <strong>Optimizations<\/strong> for my monitoring.<\/p>\n\n<h2>Key points<\/h2>\n\n<p>Before I get into the details, I\u2019ll briefly summarize the most important aspects so you can clearly understand the next steps. I\u2019ll focus on benefits, activation, evaluation, and integration with existing tools, because that\u2019s exactly where you\u2019ll find the greatest potential for improving performance. The following bullet points provide you with guidelines for the technical implementation and day-to-day work with the plugin. They serve as a helpful reminder for recurring tasks. With this concise overview, I keep my <strong>Priorities<\/strong> keep an eye on and ensure that I have reliable <strong>Results<\/strong>.<\/p>\n<ul>\n  <li><strong>Histogram<\/strong> Instead of the mean: The distribution of durations clearly shows outliers.<\/li>\n  <li>Simple <strong>Activation<\/strong>: dynamically via INSTALL or statically via configuration.<\/li>\n  <li>Fast <strong>Analyzes<\/strong>: SHOW\/FLUSH for monitoring windows and comparisons.<\/li>\n  <li>Seamless <strong>Integration<\/strong>: Data can be used in dashboards and alerts.<\/li>\n  <li>Clear <strong>Prioritization<\/strong>: The percentage of slow queries is immediately visible.<\/li>\n<\/ul>\n\n<h2>Basic Principle and Architecture<\/h2>\n\n<p>For each query, the plugin records the execution time and distributes it across buckets, which function like a <strong>Histogram<\/strong> work. I read this distribution and can immediately tell whether many statements are under 1 ms or whether the second buckets are swelling. Two components underpin this concept: an audit component that measures performance during execution, and an INFORMATION_SCHEMA component that makes the data accessible. This way, I don\u2019t just get averages, but a true <strong>Distribution<\/strong> across all time periods. It is precisely this overview that helps me distinguish sporadic outliers from systematic problems and plan targeted measures.<\/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\/09\/mariadb-performance-monitoring-8392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Activation: dynamic and static<\/h2>\n\n<p>I activate the <strong>Plugin<\/strong> During operation, I use `INSTALL SONAME\/INSTALL PLUGIN` and then set `query_response_time_stats` to `ON`. These steps immediately start data collection without restarting the server. Alternatively, I add `plugin_load_add` to the configuration so that MariaDB loads the module at startup. In cluster setups, I keep the setting consistent across all relevant nodes so that my <strong>Measured values<\/strong> remain comparable. This way, I ensure that I have consistent data that I can accurately compare across testing, staging, and production environments.<\/p>\n\n<h2>Understanding Data: Histogram of Runtimes<\/h2>\n\n<p>I retrieve the distribution using INFORMATION_SCHEMA.QUERY_RESPONSE_TIME or SHOW QUERY_RESPONSE_TIME and evaluate the <strong>Buckets<\/strong> . Each line describes an upper time limit, the number of queries, and the total runtime for that interval. This allows me to see how much load is coming in millisecond increments and where second-based peaks are likely to occur. I regularly check how the <strong>Distribution<\/strong> after changes to indexes, caches, or configurations. This approach prevents individual average values from masking actual latency issues.<\/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\/09\/mariadb_performance_meeting_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Using SHOW and FLUSH Effectively<\/h2>\n\n<p>I start new measurement windows with `FLUSH QUERY_RESPONSE_TIME` so I can make accurate before-and-after comparisons. Then I read the current distribution with `SHOW QUERY_RESPONSE_TIME` and check whether the number of fast buckets is increasing. Especially during release testing, this gives me a clear picture within minutes of whether changes to queries are taking effect. I combine FLUSH with recurring jobs that retrieve the data and store it centrally. This is how I keep my <strong>Trends<\/strong> Keep an eye out for and recognize creeping <strong>Deteriorations<\/strong> Early on.<\/p>\n\n<h2>Integration with Monitoring Tools<\/h2>\n\n<p>I incorporate the distributions into dashboards and combine them with CPU, I\/O, and lock metrics. For more in-depth analysis, I also rely on <a href=\"https:\/\/webhosting.de\/en\/mysql-performance-schema-monitoring-tool\/\">Performance Schema Monitoring<\/a>, to view Waits and Stages in detail. This combination shows me whether high latencies stem from storage, locks, or inefficient execution plans. I set alerts so that a certain percentage must fall into slow buckets before I receive a notification. This reduces <strong>Noise<\/strong> and focuses my <strong>reaction<\/strong> real problems.<\/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\/09\/mariadb-monitoring-efficiency-4278.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Everyday scenarios and practical steps<\/h2>\n\n<p>After a release, I first check the distribution to see if broad segments of the load have slowed down. If I find new peaks in the seconds range, I perform a targeted drill-down on the affected workloads. When tuning indexes, I flush the statistics, generate load, and check whether the proportion of fast buckets is increasing. For tricky query plans, I also take a look at the <a href=\"https:\/\/webhosting.de\/en\/mariadb-optimizer-trace-sql-performance-analysis-database\/\">Optimizer Trace<\/a>, to understand planning decisions. This is how I connect <strong>Visibility<\/strong> from distribution to root cause analysis <strong>Statement<\/strong>-level.<\/p>\n\n<h2>Best Practices for Measurable Results<\/h2>\n\n<p>I define fixed measurement windows\u2014for example, daily with a nightly FLUSH\u2014so that I can reliably compare trends. In addition, I keep ad hoc measurements on hand before and after changes so that I can evaluate their effects immediately. In heavily loaded systems, I check the <strong>Overhead<\/strong> In short, it\u2019s usually moderate in practice. I automate the analysis, export the buckets, and archive them by time slice. This routine creates <strong>Transparency<\/strong> and saves me time during audits or post-mortems.<\/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\/09\/mariadb_monitoring_nacht_5782.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quickly resolve sources of error<\/h2>\n\n<p>If SHOW or the table is missing, I first check to see if I have the <strong>Plugin<\/strong> loaded correctly. Then I check `query_response_time_stats`; if it's set to `OFF`, MariaDB doesn't collect any data. If permissions are missing, I adjust the privileges for installation or flushing. In case of version differences, I compare syntax variations of `INSTALL SONAME` and `INSTALL PLUGIN` to avoid conflicts. I also keep my <strong>Documentation<\/strong> up to date, so that recurring checks can be done quickly.<\/p>\n\n<h2>Comparing Metrics: Table<\/h2>\n\n<p>I use this plugin along with Slow Query Log and Performance Schema because each source provides a different perspective. The following table helps me make the most of their strengths and avoid false expectations. For detailed entries, I check my <a href=\"https:\/\/webhosting.de\/en\/mysql-slow-query-log-hosting-analyze-queryperf\/\">Slow Query Log Analysis<\/a>, while I use the distribution across buckets for prioritization. This helps me reduce blind spots in my planning and identify patterns earlier. This leads to <strong>clear<\/strong> Decisions and faster <strong>Iterations<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Feature<\/th>\n      <th>Query Response Time Plugin<\/th>\n      <th>Slow Query Log<\/th>\n      <th>Performance scheme<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Granularity<\/td>\n      <td>Breakdown by <strong>Buckets<\/strong> (Histogram)<\/td>\n      <td>A few slow ones <strong>Statements<\/strong><\/td>\n      <td>Fine-Grained Waits\/Stages\/Locks<\/td>\n    <\/tr>\n    <tr>\n      <td>Data source<\/td>\n      <td>INFORMATION_SCHEMA\/SHOW<\/td>\n      <td>Log file or table<\/td>\n      <td>Internal Performance Views<\/td>\n    <\/tr>\n    <tr>\n      <td>Suitability<\/td>\n      <td>Overview, Trends, Alerts<\/td>\n      <td>Causes at the statement level<\/td>\n      <td>In-Depth Root Cause Analysis<\/td>\n    <\/tr>\n    <tr>\n      <td>Overhead<\/td>\n      <td>Low, easy to control<\/td>\n      <td>Amount, depending on the thresholds<\/td>\n      <td>Varies depending on activation<\/td>\n    <\/tr>\n    <tr>\n      <td>Reset<\/td>\n      <td>FLUSH QUERY_RESPONSE_TIME<\/td>\n      <td>Log Rotation\/Truncate<\/td>\n      <td>Context-specific<\/td>\n    <\/tr>\n    <tr>\n      <td>Outliers<\/td>\n      <td>Percentage distribution displayed<\/td>\n      <td>Individual peaks are visible<\/td>\n      <td>Causes of delays are identifiable<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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\/09\/mariadb_plugin_desk_9123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Role in Holistic Monitoring<\/h2>\n\n<p>I use the bucket distribution as a key metric in my dashboards because it reflects the perceived <strong>Latency<\/strong> that accurately reflects user behavior. If the percentage of slow buckets increases, I raise the priority of my analysis. Correlation with system metrics tells me whether I need to address CPU, RAM, I\/O, or locking issues. I also check whether caching strategies are effective or whether an increase in data volume requires new indexes. From this overview, I derive specific <strong>Actions<\/strong> ...instead of getting bogged down in details.<\/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\/09\/mariadb-monitoring-5289.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Customize the bucket design<\/h2>\n\n<p>I adjust the bucket resolution to suit my workloads. If I'm missing details in the sub-millisecond range, I increase the resolution there. If queries tend to be measured in seconds, I expand the upper buckets. The key is striking a balance: More buckets provide finer <strong>Insights<\/strong>, but they slightly increase the measurement overhead and the amount of data to be exported. I check my active variables using SHOW VARIABLES LIKE \u201aquery_response_time%\u2018; and document the selection for each environment. I roll out changes in a coordinated manner so that time series remain comparable across nodes and environments. I always initiate configuration changes with a targeted `FLUSH` to observe the effect of the new resolution in a fresh measurement window.<\/p>\n\n<p>In practice, I keep the following key questions in mind: Does the bucket scale cover my SLOs (e.g., 95% under 100 ms)? Can I clearly identify outlier classes? Are the aggregations for dashboards stable (no frequent scale changes)? This is how I ensure that the histogram supports decision-making and isn\u2019t just a \u201cnice-to-have.\u201d.<\/p>\n\n<h2>Derive Percentiles from Buckets<\/h2>\n\n<p>I derive p90\/p95\/p99 from the histogram distribution without logging every statement. To do this, I accumulate the counts of the buckets in ascending order until I reach the desired percentage. I use the corresponding bucket threshold as a conservative percentile estimate. That\u2019s sufficient for me for SLO monitoring and <strong>Alerts<\/strong>. I'd like to add: If there's a high concentration of data at the edge of the bucket, I set tighter limits or add additional classes so that the percentiles don't \u201cjump.\u201d This method is robust, fast, and places almost no load on the server\u2014ideal for continuous monitoring.<\/p>\n\n<p>For ad hoc calculations, I use simple SQL variables to calculate cumulative sums over INFORMATION_SCHEMA.QUERY_RESPONSE_TIME. In production environments, I calculate percentiles in my metrics system after exporting the buckets so that I can run historical and comparative analyses.<\/p>\n\n<h2>Replication, Galera, and High Availability<\/h2>\n\n<p>In the replication cluster, histograms are <strong>node-specific<\/strong>. This is intentional, since workloads on primary and secondary nodes differ (write load vs. read load). Nevertheless, I keep the plugin configuration identical so that I can clearly attribute any differences. In Galera setups, the bucket distribution per node helps me identify hotspots in read clusters and fine-tune load balancing. After switchover, I reschedule monitoring windows and mark them on my dashboards so I can correctly interpret any shifts. Important: The counters are volatile; after restarts, I intentionally start with a new window, but I export the latest values before maintenance windows to minimize breaks in the time series.<\/p>\n\n<h2>Automatic Export and Data Storage<\/h2>\n\n<p>I regularly export the buckets for trends and audits. I prefer querying from INFORMATION_SCHEMA because it\u2019s machine-readable. The job writes the timestamp, node, environment, and all buckets to a metrics pipeline or to a separate table. I perform the reset intentionally: Either I flush the data after the export (rolling-window analysis), or I collect data cumulatively and calculate differences externally (counter model). Both approaches have their place\u2014the important thing is to choose a single approach per dashboard so that alerts remain consistent.<\/p>\n\n<p>For quick checks in test environments, I use simple CSV exports and analyze them with standard tools. In production, I prioritize a streamlined, repeatable export process with clear error handling so that I don't lose any measurement windows.<\/p>\n\n<h2>Security, Rights, and Governance<\/h2>\n\n<p>To INSTALL or UNINSTALL the plugin, I need the appropriate privileges (e.g., INSTALL PLUGIN or administrative rights). Elevated privileges are also required for FLUSH QUERY_RESPONSE_TIME. I keep data access as restrictive as reasonable, since even metrics can reveal information about workloads. In regulated environments, I log changes to the plugin\u2019s status and configuration. I define who is authorized to start measurement windows and indicate in dashboards when and by whom a FLUSH was performed. This ensures that analyses remain traceable and suitable for audits.<\/p>\n\n<h2>Borders and Demarcation<\/h2>\n\n<p>The plugin measures the <strong>Server-side<\/strong> Execution time\u2014network latency and client retries are excluded. Query text, user, schema, or source are not logged; for that, I also use the Slow Query Log and Performance Schema. There is no persistence: counters are reset after a restart, so I export the data regularly. The plugin does not offer granular filtering (e.g., SELECT only); I handle this operationally using measurement windows during targeted load or by correlating buckets with logs. For very high QPS, I briefly check the overhead using A\/B measurements; in practice, it\u2019s low, but I never measure \u201cblindly.\u201d.<\/p>\n\n<h2>An In-Depth Look at Diagnosis: Common Pitfalls<\/h2>\n\n<p>If SHOW QUERY_RESPONSE_TIME is missing, I verify that the plugin name is correct and that the module is located in the plugin_dir. I check the loaded modules with `SHOW PLUGINS` and verify the paths. If the syntax differs between versions, I fall back on the alternative `INSTALL` form (with `SONAME`) and note the working variant in the internal documentation. If the values in `INFORMATION_SCHEMA` do not match those from `SHOW`, it is usually due to an intervening `FLUSH` or a measurement window conflict\u2014I repeat the measurement in a structured manner. If permission errors occur during `FLUSH`, I check specific privileges instead of granting `SUPER` across the board.<\/p>\n\n<h2>Dashboards and Alerts That Really Help<\/h2>\n\n<p>I visualize the buckets cumulatively and as percentages, not just in absolute terms. This way, changes in the load (more total requests) from <strong>Latency Shifts<\/strong> Decoupled. I phrase alerts in business language: \u201c&gt;5% of queries taking longer than 500 ms over 10 minutes\u201d instead of \u201cAverage &gt; 120 ms.\u201d I also use trend alerts (increasing proportion of slow queries) and stabilizers (hysteresis) to avoid false positives. In multi-node environments, I aggregate by role (Writer\/Reader) and also display the top contributors from the Log\/Performance schema so that escalation can be handled directly with a <strong>Action Plan<\/strong> starts.<\/p>\n\n<h2>Methodological Tests and Overhead Measurement<\/h2>\n\n<p>I systematically test the overhead: a brief load scenario without the plugin, then with the plugin loaded, and then with active stats. I measure throughput, CPU usage, and latency distribution. I repeat this process with different bucket resolutions. I document the results for my own platform instead of relying on general statements. This allows me to approve the plugin even in strictly regulated systems. For features that I only need occasionally (e.g., tighter sub-ms buckets), I limit their use to short, clearly defined measurement windows.<\/p>\n\n<h2>Practical Guide to Changes<\/h2>\n\n<p>Before making a structural change (index, parameter, deployment), I flush the system, set a time window, and collect system metrics in parallel. After the change, I repeat the process exactly. The key factor is the <strong>Symmetry<\/strong> Measurement criteria: identical load, same time period, same aggregation. I compare the percentage shares per bucket and evaluate them against my SLOs. Only when fast buckets increase significantly or slow ones decrease do I consider the measure a success. If the distribution remains unchanged, I turn to more in-depth tools (Optimizer Trace, Performance Schema) or adjust my hypothesis.<\/p>\n\n<h2>Summary: Get Clear Answers Faster<\/h2>\n\n<p>With the Query Response Time plugin, I can quickly get a clear picture of the distribution of query times. I activate the <strong>Module<\/strong> Targeted: Flush the measurement windows and compare performance trends before and after changes. Combining this with the Slow Query Log, Performance Schema, and, if necessary, optimizer analyses provides a comprehensive view of the causes. In my day-to-day work, I focus on buckets that are overflowing and use this information to derive specific <strong>Measures<\/strong> This way, I ensure a fast user experience and keep my database costs under control.<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how to use the MariaDB Query Response Time plugin for precise database monitoring, analyze query times, and identify performance issues early on.<\/p>","protected":false},"author":1,"featured_media":21372,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21379","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":"84","_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":"query response","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":"21372","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21379","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=21379"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21379\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/21372"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=21379"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=21379"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=21379"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}