{"id":20682,"date":"2026-08-15T18:19:23","date_gmt":"2026-08-15T16:19:23","guid":{"rendered":"https:\/\/webhosting.de\/bcc-tools-linux-performance-ebpf-observability-focus\/"},"modified":"2026-08-15T18:19:23","modified_gmt":"2026-08-15T16:19:23","slug":"bcc-tools-linux-performance-ebpf-observability-focus","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/bcc-tools-linux-performance-ebpf-observability-focus\/","title":{"rendered":"bcc tools in Action: A Practical Guide to Linux Performance Engineering with eBPF"},"content":{"rendered":"<p>I'll show you, step by step, how I <strong>bcc tools<\/strong> I use eBPF to quickly pinpoint and resolve bottlenecks on Linux servers. In doing so, I employ practical workflows, measure actual latencies in the kernel, and correlate events from the CPU, I\/O, and network to form a <strong>clear<\/strong> Root Cause Analysis.<\/p>\n\n<h2>Key points<\/h2>\n<ul>\n  <li><strong>eBPF<\/strong> provides deep tracing with low overhead.<\/li>\n  <li><strong>bcc tools<\/strong> cover CPU, I\/O, networking, and processes.<\/li>\n  <li><strong>Production-oriented<\/strong> Can be used without making any changes to the app.<\/li>\n  <li><strong>Checklist<\/strong> with ten tools to get you started.<\/li>\n  <li><strong>Security<\/strong> through verifiers and clear policies.<\/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\/08\/linux-performance-ebpf-4976.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Why eBPF for Linux Performance Engineering<\/h2>\n<p>I reach for <strong>eBPF<\/strong>, because I want to measure kernel events reliably, selectively, and with very little overhead. Traditional tools show totals, but they rarely explain why threads are waiting, packets are being resent, or I\/O is stalling; eBPF fills this gap with <strong>specific<\/strong> Events. The programs run in the kernel; the verifier checks them beforehand, and I can start them without rebooting. This allows me to correlate user-space calls with kernel paths and get a picture that enables immediate optimizations. If you'd like to delve deeper into this topic, you'll find an overview in my brief introduction to <a href=\"https:\/\/webhosting.de\/en\/ebpf-performance-analysis-linux-tracing-server-monitoring-observability\/\">eBPF Performance Analysis<\/a>, which outlines the interplay between tracing and observability.<\/p>\n\n<h2>What are BCC tools, and where can I find them?<\/h2>\n<p>The <strong>bcc<\/strong> tools are ready-to-use diagnostic programs based on eBPF and are typically located in \/usr\/share\/bcc\/tools. I run them directly from the shell, get clear standard output, and don't have to modify my applications. The collection covers processes, system calls, file systems, block I\/O, networking, schedulers, and profiling, making it suitable for <strong>productive<\/strong> Analyses. Since I enable tracing selectively, the impact remains minimal and measurement errors caused by monitoring are negligible. For more in-depth cases, I supplement the tools with my own eBPF or use additional sampling profiles.<\/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\/bcc_tools_linux_eBPF_7438.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Installation and requirements<\/h2>\n<p>I'm installing the <strong>bcc<\/strong> tools via the package manager (bcc-tools or bpfcc-tools) on common distributions. You\u2019ll need a kernel with eBPF support (4.x or later, preferably 4.9+), BPF functions enabled, and sufficient permissions to load the programs. On production servers, I test the eBPF capabilities of the kernel and distribution in advance in a test environment so that subsequent measurements <strong>reliable<\/strong> run. I prevent security profiles that completely block eBPF by using coordinated policies. The concise notes on provide a practical overview of setup and operation <a href=\"https:\/\/webhosting.de\/en\/ebpf-linux-analysis-tools-server-monitoring-insights\/\">eBPF analysis tools<\/a>.<\/p>\n\n<h2>Before Takeoff: System and Safety Checks<\/h2>\n<p>Before I run tests in production, I verify the host's basic capabilities. This helps me avoid false starts and ensures reproducible results.<\/p>\n<ul>\n  <li>Check kernel features: <code>uname -r<\/code> and available BPF functions (e.g., via feature checks). Important ones include kprobes\/tracepoints, BTF (for stable type information), and perf events.<\/li>\n  <li>Permissions and Policies: I ensure that only authorized users are allowed to load eBPF (CAP_BPF\/CAP_SYS_ADMIN or equivalent policy) and that LSM profiles do not block the loading process.<\/li>\n  <li>System parameters: <code>kernel.unprivileged_bpf_disabled<\/code> is usually active in production environments. That's why I deliberately work from secured sessions and with clear auditing.<\/li>\n  <li>Transparent Paths: I keep directories such as <code>\/sys\/kernel\/debug\/tracing<\/code> and <code>\/sys\/fs\/bpf<\/code> in mind, to clean up artifacts after taking measurements.<\/li>\n<\/ul>\n<p>These hygiene measures ensure that I can perform measurements in a targeted and reproducible manner\u2014without any side effects.<\/p>\n\n<h2>Practical Guide: The First Ten Tools<\/h2>\n<p>For a quick performance check, I follow a set sequence. This allows me to clearly narrow down whether the issue is caused by the CPU, I\/O, or the network, and decide whether to dig deeper into call stacks or timings. The table shows the core function of each tool and the question I\u2019m trying to answer with it. I keep the runtime short at first and repeat the measurements as soon as I have a suspicion <strong>confirm<\/strong> I want to. That way, I avoid blind spots and don't waste time in urgent <strong>Incidents<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Tool<\/th>\n      <th>Observed<\/th>\n      <th>Typical question<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>execsnoop<\/td>\n      <td>New Processes<\/td>\n      <td>Who creates short-term jobs that create a burden?<\/td>\n    <\/tr>\n    <tr>\n      <td>opensnoop<\/td>\n      <td>File Openings<\/td>\n      <td>Which paths are constantly being opened or logged?<\/td>\n    <\/tr>\n    <tr>\n      <td>ext4 is slower (xfs*, btrfs*, zfs*)<\/td>\n      <td>Slow FS Operations<\/td>\n      <td>Which requests show high latency per volume?<\/td>\n    <\/tr>\n    <tr>\n      <td>biolatency<\/td>\n      <td>Block I\/O Distribution<\/td>\n      <td>Are there sporadic or persistent latency spikes?<\/td>\n    <\/tr>\n    <tr>\n      <td>biosnoop<\/td>\n      <td>Individual I\/O Requests<\/td>\n      <td>Which process brings certain devices to a standstill?<\/td>\n    <\/tr>\n    <tr>\n      <td>cachestat<\/td>\n      <td>Page Cache Behavior<\/td>\n      <td>Is it worth getting more RAM, or does the app suffer from glitches?<\/td>\n    <\/tr>\n    <tr>\n      <td>tcpconnect<\/td>\n      <td>New TCP Connections<\/td>\n      <td>Who uses which service, and how often?<\/td>\n    <\/tr>\n    <tr>\n      <td>tcpaccept<\/td>\n      <td>Accepted Connections<\/td>\n      <td>Which server sockets are under heavy load?<\/td>\n    <\/tr>\n    <tr>\n      <td>tcpretrans<\/td>\n      <td>Retransmissions<\/td>\n      <td>Does packet loss indicate unstable paths?<\/td>\n    <\/tr>\n    <tr>\n      <td>runqlat<\/td>\n      <td>Scheduler Latencies<\/td>\n      <td>Are threads waiting too long for CPU time?<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>I also use <strong>profiles<\/strong> to identify hotspots in user or kernel space and aggregate call stacks. This helps me uncover expensive regular expressions, inefficient drivers, or spinlocks, which I then address in the code or configuration. I use short sampling intervals and compare multiple runs to filter out outliers <strong>visible<\/strong> This combination of a broad overview and in-depth analysis saves me a lot of time on analysis. I then test the optimization again under the same 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\/linux-performance-ebpf-tools-4528.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Extension: Make Off-CPU, Locks, and Wait Times Visible<\/h2>\n<p>Not all high latency is CPU-bound. Often, threads wait \u201eoff-CPU\u201c for I\/O, locks, or wake-ups. Additional bcc tools and profiles can help here:<\/p>\n<ul>\n  <li>Off-CPU Analysis: I measure how long threads spend off the CPU and which stacks lead to that state. This separates computation time from wait time and identifies blockers.<\/li>\n  <li>Lock Contention: I focus specifically on critical kernel and user-space locks. Long hold times or high contention indicate serialization points, which I break down (e.g., through sharding, finer granularity, or different data structures).<\/li>\n  <li>Wakeup paths: Latenencies between \u201ewoke up\u201c and \u201erunning again\u201c reveal scheduling and priority issues or excessively large worker pools.<\/li>\n<\/ul>\n<p>I correlate these signals with <strong>runqlat<\/strong> and <strong>biolatency<\/strong>, to distinguish between memory, I\/O, and scheduler-related causes.<\/p>\n\n<h2>Measurement Hygiene: Filters, Duration, Thresholds<\/h2>\n<p>To ensure that eBPF measurements remain reproducible, I follow three basic rules:<\/p>\n<ul>\n  <li>Short and to the point: I initially run tools for only a short time (e.g., 10\u201330 seconds) and focus on suspicious PIDs, containers, or sockets.<\/li>\n  <li>Setting Thresholds: With \u201e*slower\u201c tools, I filter out small latencies to reduce noise and see only problematic calls.<\/li>\n  <li>Limit the rate: I use selective filters (e.g., process name, TIDs, ports) to keep event rates low. This keeps overhead to a minimum and helps me avoid dropped events.<\/li>\n<\/ul>\n<p>Only when I see a pattern do I extend the duration or broaden the scope. This allows me to <strong>clean<\/strong> and reliable samples.<\/p>\n\n<h2>Real-World Scenario 1: Unexplained High CPU Load<\/h2>\n<p>If the CPU monitor consistently shows high values, I start by <strong>execsnoop<\/strong>, to identify short-lived processes. Next, I use `runqlat` to measure how long threads wait for CPU time and check whether the run queues are overfilled or the priorities are set incorrectly. If wait times become noticeable, I reduce the number of workers, adjust thread pools, or reschedule cron jobs so that the scheduler <strong>grab<\/strong> can. With profile, I collect stacks and identify the real hotspots in libraries and in my own code. Only after I bring all this information together do I make decisions regarding limits, garbage collection, affinities, or compiler flags.<\/p>\n\n<h2>Real-World Scenario 2: I\/O Latencies and Sluggish Applications<\/h2>\n<p>If users complain about freezes when CPU usage is low, I check by <strong>ext4slower<\/strong> Slow file system calls per process. Next, I use `biolatency` to examine the distribution of block I\/O times by device, to identify sporadic spikes or persistent bottlenecks. `biosnoop` shows me whether a single service is generating an unhealthy number of small writes, thereby triggering queuing that slows down other processes. With `cachestat`, I can see whether the page cache is hitting or missing. <strong>dominate<\/strong> and more RAM would help. In the end, I'll decide whether batch writes, larger buffers, or switching to faster storage will be worth it.<\/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_nachtarbeit_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Practical Scenario 3: Network Paths and Microservices<\/h2>\n<p>In distributed environments, I start with <strong>tcpconnect<\/strong>, to measure connection establishment between services. Then I use `tcpaccept` to check which server sockets have a particularly high number of incoming connections and whether limits on the listener side are being enforced. `tcpretrans` detects retransmissions and helps distinguish between transport issues and application errors before I adjust timeouts and retry settings. With these three metrics, I can determine whether the network, the app, or an upstream service is causing the <strong>Latency<\/strong> drives. After that, I adjust the backoff strategies, keepalive values, load balancer settings, and buffer sizes.<\/p>\n\n<h2>Operational Safety and Reliability of eBPF<\/h2>\n<p>I'm just uploading <strong>trustworthy<\/strong> I use tools and test my own eBPF programs on the staging environment first. The kernel verifier blocks faulty programs, but I also set limits for maps and buffers to ensure memory usage stays within safe bounds. I keep logging enabled to monitor behavior and side effects and to intervene quickly if necessary. Policies define who is allowed to load eBPF, ensuring that control remains with the platform team and security requirements are met. These rules ensure that tracing in production environments <strong>Reliable<\/strong> remains the same and doesn't produce any surprises.<\/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_tools_4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Container and Kubernetes environments<\/h2>\n<p>In containers, I separate systematic issues from pod-specific effects. To do this, I filter metrics by cgroup, namespace, or PID range. Many bcc tools allow filtering by process name or ID; alternatively, I collect metrics on the host and map events to workloads via cgroups. Important:<\/p>\n<ul>\n  <li>PID namespace: PIDs differ between the host and the container. I map the IDs or filter by process name or port.<\/li>\n  <li>Resource Quotas: CPU throttling caused by CFS quotas results in long wait times even when the system is not operating at full capacity. I can tell this by <strong>runqlat<\/strong> in combination with ratio metrics.<\/li>\n  <li>Network namespaces: When analyzing sockets, I make sure to use the correct namespace. I take measurements on the host interface and correlate them with pod IPs and ports.<\/li>\n<\/ul>\n<p>This ensures that the measurement results remain meaningful, even when many workloads are running in close proximity to one another.<\/p>\n\n<h2>Integration into Observability Stacks<\/h2>\n<p>I'm not replacing my monitoring; I'm supplementing it with <strong>eBPF<\/strong>. bcc tools provide me with depth, while metrics systems, logs, and APM show the breadth; together, they paint a coherent picture. When needed, I route traces from bcc into log pipelines, trigger snapshots during incidents, and document the findings with the team. For ad hoc profiling, I use sampling in addition to metric timelines to identify anomalies <strong>tangible<\/strong> will be. Those who prefer scripting as a supplement will find <a href=\"https:\/\/webhosting.de\/en\/bpftrace-detect-and-diagnose-hosting-server-issues-faster\/\">bpftrace in hosting<\/a> A streamlined way to answer ad hoc questions using mini-scripts.<\/p>\n\n<h2>Common Pitfalls\u2014and How I Get Around Them<\/h2>\n<ul>\n  <li>Noisy Neighbor: Individual jobs generate short-lived but intense load. <strong>execsnoop<\/strong> plus <strong>profiles<\/strong> These reliably identify these patterns; I use time boxes or isolate them using quotas.<\/li>\n  <li>NUMA and Affinities: High latencies despite available cores indicate cross-NUMA accesses. I'm checking CPU affinities, memory binding, and IRQ distribution.<\/li>\n  <li>IRQ\/SoftIRQ hotspots: Network load can saturate ksoftirqd kernels. I monitor retransmissions, distribute IRQs via RSS\/queues, and adjust RPS\/XPS.<\/li>\n  <li>Page cache effects: Cold starts appear to be slower. I take warm-up phases into account and compare <strong>cachestat<\/strong>-Values before and after loading.<\/li>\n  <li>Kernel Updates: Kprobes may change when there are version jumps. I prefer stable tracepoints, test them in advance, and keep a minimal set on hand.<\/li>\n<\/ul>\n\n<h2>Workflows that have proven effective<\/h2>\n<ul>\n  <li>Incident Snapshot: 60\u2013120 seconds of combined execution (execsnoop, runqlat, biolatency, tcpretrans, profile). After that, I focus on the subsystem that stands out.<\/li>\n  <li>Baseline Routine: Weekly brief measurements on key paths (e.g., storage and network profiles). This allows me to identify deviations early on.<\/li>\n  <li>Change Validation: Before and after configuration changes, I compare the same measurement points to quantify the effect.<\/li>\n<\/ul>\n\n<h2>Continuous Linux Performance Engineering<\/h2>\n<p>I view performance as an ongoing process, not as <strong>One-time action<\/strong>. In CI\/CD, I integrate short eBPF-based checks to detect regressions early and stop them before rollout. During maintenance windows, I measure typical paths under load, establish baselines, and document acceptable latency ranges. This allows me to quickly identify deviations and avoid guesswork during incidents, because I have comparative data <strong>available<\/strong>. This routine directly contributes to availability, cost control, and user experience.<\/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\/bcc-tools-leitfaden-4956.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mini Case Study: From Symptom to Cause in 12 Minutes<\/h2>\n<p>An API cluster is reporting rising 99p latencies while RPS remains unchanged. I'm starting an incident snapshot: <strong>tcpconnect<\/strong> shows no anomalies in the connection establishment, <strong>tcpretrans<\/strong> remains low\u2014but the network certainly isn't. <strong>runqlat<\/strong> reports short but frequent wait times; <strong>profiles<\/strong> displays hotspots in JSON format. At the same time, I'm monitoring with <strong>cachestat<\/strong> a drop in the cache hit rate during peak periods. The correlation suggests: many small payloads that are serialized synchronously and written immediately.<\/p>\n<p>I verify using <strong>ext4slower<\/strong>, which shows fsyncs lasting several milliseconds on the same volume for the API process; <strong>biolatency<\/strong> Confirms sporadic queue spikes on the affected device. Countermeasure: Batching writes, using a larger buffer, and performing asynchronous flushing at less critical points. After the rollout, the 99th-percentile latencies drop by 35 %, the cache hit rate recovers, and <strong>runqlat<\/strong> shows narrow distributions once again.<\/p>\n\n<h2>Summary for practice<\/h2>\n<p>With <strong>bcc<\/strong> Using tools and eBPF, I can quickly gain insight into CPU, I\/O, and network performance without modifying applications. The checklist consisting of execsnoop, opensnoop, ext4slower, biolatency, biosnoop, cachestat, tcpconnect, tcpaccept, tcpretrans, and runqlat provides a solid starting point. In addition, I use `profile` to identify hotspots and optimize code paths. With clean policies, logging, and limits, kernel usage remains <strong>safe<\/strong> and transparent. Those who consistently apply this method resolve performance issues more quickly, plan capacity more effectively, and reduce costs per request.<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how to professionally analyze and optimize Linux performance using bcc tools and eBPF. This guide provides practical performance engineering tips with a focus on bcc tools.<\/p>","protected":false},"author":1,"featured_media":20675,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[922],"tags":[],"class_list":["post-20682","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technologie"],"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":"123","_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":"bcc tools","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":"20675","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20682","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=20682"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20682\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/20675"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=20682"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=20682"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=20682"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}