{"id":20730,"date":"2026-08-17T11:52:23","date_gmt":"2026-08-17T09:52:23","guid":{"rendered":"https:\/\/webhosting.de\/apache-event-mpm-vs-worker-mpm-webserver-tuning-optimierung\/"},"modified":"2026-08-17T11:52:23","modified_gmt":"2026-08-17T09:52:23","slug":"apache-event-mpm-vs-worker-mpm-web-server-tuning-and-optimization","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/apache-event-mpm-vs-worker-mpm-webserver-tuning-optimierung\/","title":{"rendered":"Apache Event MPM vs. Worker MPM: A Modern Web Server Boost for High Workloads"},"content":{"rendered":"<p>In two sentences, I'll explain why the choice of the <strong>Apache MPM<\/strong> visibly affects throughput, latency, and stability under heavy load. I specifically compare Event MPM and Worker MPM in the context of long keep-alive connections, HTTP\/2, and high concurrency, and derive clear tuning recommendations from this analysis.<\/p>\n\n<h2>Key points<\/h2>\n\n<p>To help you grasp the most important points right away, I\u2019ll briefly summarize the key takeaways and highlight crucial keywords in bold. Based on these points, I\u2019ll outline specific steps and configurations below, explaining them in a practical way. I consistently evaluate both MPMs under realistic load profiles with numerous connections. This way, you can see right away which module stands out in your stack. The list provides a shortcut to making informed decisions in day-to-day operations.<\/p>\n<ul>\n  <li><strong>event<\/strong> Decouples Idle Keep-Alive from request threads and scales well with a large number of connections.<\/li>\n  <li><strong>Worker<\/strong> Performs well with short requests, but ties up threads with long keep-alive times.<\/li>\n  <li><strong>HTTP\/2<\/strong> Event benefits measurably from efficient multiplexing handling.<\/li>\n  <li><strong>Resources<\/strong>: This event keeps RAM and CPU usage lower per active request.<\/li>\n  <li><strong>Compatibility<\/strong>: Thread-safe modules are required; mod_php remains in prefork mode.<\/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\/serverraum-webserverturbo-4837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Why Worker and Event Are Leading the Way<\/h2>\n\n<p>In a modern business, I firmly believe in <strong>Threads<\/strong>, because they use less RAM per connection than processes. Prefork used to offer security with non-thread-safe modules, but it scales poorly with many connections. Today, Worker and Event dominate because they handle many concurrent users efficiently. This pays off especially with active keep-alive and HTTP\/2, where connections remain open for long periods. That\u2019s exactly where <strong>event<\/strong> its strengths, since it doesn't tie up idle connections on valuable request threads.<\/p>\n\n<h2>Apache Worker MPM: Architecture and Limitations<\/h2>\n\n<p>I define workers as a hybrid of processes and <strong>Threads<\/strong>, in which each child process has one listener thread and many server threads. A request is assigned to a thread, is processed, and then the thread is released. If the connection remains open, the same thread remains bound to that connection. This causes idle time when many clients wait for extended periods or send only small, sporadic requests. Anyone using workers should therefore carefully size thread pools and set limits; for this, you can refer to my brief <a href=\"https:\/\/webhosting.de\/en\/thread-pool-server-optimization-workerhosting-threadpool\/\">Thread pool optimization<\/a> use as a starting point.<\/p>\n\n<h2>Apache Event MPM: The Event Loop Explained<\/h2>\n\n<p>I describe an event as a \"worker-plus-event-loop,\" that is, <strong>listener<\/strong>-Threads that park idle connections. The listener accepts new connections, passes active requests to available worker threads, and then reclaims the connection. In this way, request threads only work when data is flowing. Hundreds or thousands of clients can therefore remain open without blocking the threads. It is precisely this <strong>Parking<\/strong> makes Event so efficient for typical HTTP\/1.1 and HTTP\/2 workloads.<\/p>\n\n<h2>Event vs. Worker: Differences Under Load<\/h2>\n\n<p>I always evaluate both MPMs under real-world <strong>Load<\/strong> with long keep-alive times. The worker quickly reaches its limit because idle connections tie up threads, which are then unavailable for new requests. Events keep the thread pools free and move idle connections into the event loop. This significantly increases the number of users that can be served simultaneously, while latencies remain stable. If you need a basis for decision-making, it\u2019s best to compare specific <a href=\"https:\/\/webhosting.de\/en\/threading-server-model-event-driven-hosting-comparison-serverperf\/\">event-driven server models<\/a> with thread pools in load tests.<\/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\/ApacheWebserverMeeting2573.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compatibility: Modules and Typical Setups<\/h2>\n\n<p>I first check the <strong>Modules<\/strong>, because both Worker and Event require thread safety. Traditional mod_php stacks aren\u2019t suitable, which is why Prefork still makes sense here. If, on the other hand, PHP is running via PHP-FPM or FastCGI, I definitely opt for Event. This also applies to reverse proxies to application servers, microservices, or Go\/Node backends. In such setups, Worker and, above all, <strong>event<\/strong> its strength without compromising on compatibility.<\/p>\n\n<h2>Configuration: The Most Important Directives<\/h2>\n\n<p>I'll give you a brief overview of the key guidelines so you can understand them clearly and <strong>customizes<\/strong>. MaxRequestWorkers limits the number of requests processed simultaneously; with Event, you can often set a higher value because idle connections do not block. ThreadsPerChild defines the number of threads per process; too few reduce throughput, while too many put a strain on the CPU. ServerLimit sets the limit for processes and thus the upper limit for parallel requests within the cluster. With KeepAliveTimeout, you control how long connections remain open; the higher the value, the greater the benefit <strong>event<\/strong>.<\/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\/webserver-turbo-mpm-comparison-8394.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparison Table: Worker vs. Event<\/h2>\n\n<p>I'll summarize the most important features in a concise <strong>Table<\/strong> together so you can see the differences right away. It\u2019s not a substitute for a load test, but it helps you focus on the key characteristics. Read the points from left to right and match them to your traffic profile. This will help you quickly find the right MPM for your architecture. The focus is clearly on scalability, resource requirements, and behavior with <strong>Keep-Alive<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Criterion<\/th>\n      <th>Worker MPM<\/th>\n      <th>Event MPM<\/th>\n      <th>impact<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Keep-Alive Handling<\/td>\n      <td>Thread Remains Bound to Connection<\/td>\n      <td>The event loop parks idle connections<\/td>\n      <td>Event keeps request threads free<\/td>\n    <\/tr>\n    <tr>\n      <td>Use of Resources<\/td>\n      <td>More bound threads during idle time<\/td>\n      <td>Fewer bound threads when idle<\/td>\n      <td>Less RAM\/CPU per active request<\/td>\n    <\/tr>\n    <tr>\n      <td>Latency under load<\/td>\n      <td>Leave earlier<\/td>\n      <td>Stays stable longer<\/td>\n      <td>Improved responsiveness<\/td>\n    <\/tr>\n    <tr>\n      <td>HTTP\/2 Support<\/td>\n      <td>Neat<\/td>\n      <td>Very efficient<\/td>\n      <td>Advantages of Multiplexing<\/td>\n    <\/tr>\n    <tr>\n      <td>Configuration<\/td>\n      <td>MaxRequestWorkers, ThreadsPerChild, ServerLimit<\/td>\n      <td>Immediately, plus event loop optimization<\/td>\n      <td>Event Allows for Higher Utilization<\/td>\n    <\/tr>\n    <tr>\n      <td>Compatibility<\/td>\n      <td>Thread-safe modules required<\/td>\n      <td>Likewise, preferably with PHP-FPM<\/td>\n      <td>Prefork remains a mod_php option<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Practical Application: Tuning Workflow and Measurement<\/h2>\n\n<p>I always start with a clean baseline <strong>Monitoring<\/strong> and log data. Then I gradually adjust MaxRequestWorkers and ThreadsPerChild and measure latency, error rate, and CPU load. I test KeepAliveTimeout in stages because the ideal time depends heavily on client behavior. At this point, it\u2019s worth comparing Event vs. Worker using tools like ab, wrk, or JMeter. Only once the metrics look good do I finalize the <strong>Profiles<\/strong> and document the key metrics.<\/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\/apache_mpm_techoffice_4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>When Prefork Remains a Viable Option<\/h2>\n\n<p>I use Prefork when the code absolutely must not be thread-safe <strong>Modules<\/strong> must run. In that case, isolation per process is more important than scaling. In return, I accept a significantly higher RAM requirement per connection. For legacy applications that can\u2019t be modified, this is often the most realistic approach. However, as soon as I use PHP-FPM or other external application servers, I prefer <strong>event<\/strong> clearly.<\/p>\n\n<h2>Web Hosting Context and Choosing a Provider<\/h2>\n\n<p>In a hosting environment, I pay attention to MPM profiles because there are often many virtual hosts on a single machine <strong>run<\/strong>. Event offers the most efficient use of resources here, especially with HTTP\/2 and TLS. If my stack requires PHP-FPM, I set Event as the default. A brief overview helps with context and a technical review <a href=\"https:\/\/webhosting.de\/en\/webserver-worker-models-prefork-worker-event-mpm-serverperf\/\">Comparison of Prefork, Worker, and Event<\/a> before the final exam. Those who complete these assignments will achieve noticeably better <strong>Response times<\/strong> per euro.<\/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_apachempm_9821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Best practices compact<\/h2>\n\n<p>I consistently use <strong>PHP-FPM<\/strong> or other external app servers so that Event can reach its full potential. After that, I tune MaxRequestWorkers and ThreadsPerChild to match the number of CPU cores and RAM, and check the system\u2019s hard limits. When there are many idle clients, I choose Event, deliberately set KeepAliveTimeout higher, and monitor latencies in the process. For workloads with very short requests and moderate keep-alive, Worker is sufficient as long as the modules remain thread-safe. Without continuous monitoring of thread utilization, errors, and <strong>Latencies<\/strong> I don't make any final decisions.<\/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\/serverraum-performance-4096.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Specific configuration examples for Event and Worker<\/h2>\n<p>I provide two minimalist profiles that I use as a starting point and then refine based on measured values. Crucially: <strong>MaxRequestWorkers = ServerLimit \u00d7 ThreadsPerChild<\/strong>. I work backward from the RAM budget and the requirements per thread (including modules, TLS, and buffers) and increase the amount incrementally.<\/p>\n<pre><code># Example: Event MPM (HTTP\/2, PHP-FPM)\nServerLimit 16\nThreadLimit 256\nThreadsPerChild 64\nMaxRequestWorkers     1024\nStartServers 4\nMaxConnectionsPerChild 10000\n\nKeepAlive On\nMaxKeepAliveRequests  100\nKeepAliveTimeout 15\n\n# Optional; adjust only after performance testing:\n# ListenBacklog 1024\n# ThreadStackSize     1048576   # 1 MB, only if modules allow it\n# AsyncRequestWorkerFactor 2    # Event loop fine-tuning; usually leave at default\n\n# HTTP\/2\nProtocols h2 http\/1.1\n# H2MaxSessionStreams  100\u2013200  # Fine-tune based on backend capacity\n<\/code><\/pre>\n<pre><code># Example: Worker MPM (short requests, moderate keep-alive)\nServerLimit 8\nThreadLimit 256\nThreadsPerChild 50\nMaxRequestWorkers     400\nStartServers 4\nMaxConnectionsPerChild 5000\n\nKeepAlive On\nMaxKeepAliveRequests  100\nKeepAliveTimeout 3\nProtocols http\/1.1\n<\/code><\/pre>\n<p>I hold <strong>MaxConnectionsPerChild<\/strong> (Alias: MaxRequestsPerChild) set to a value other than 0 to catch creeping memory leaks. <strong>KeepAliveTimeout<\/strong> I deliberately set it higher for the Event thread because idle connections are inexpensive; for the Worker thread, I keep it low so as not to block threads.<\/p>\n\n<h2>HTTP\/2 Fine-Tuning with Event<\/h2>\n<p>I take into account when <strong>HTTP\/2<\/strong>, that browsers open few connections and many <strong>streams<\/strong> multiplexing. This shifts the bottleneck away from the number of connections and toward fair thread allocation and backend capacity. With Event, threads remain free as long as a stream is waiting; this smooths out latency spikes. Practical control mechanisms:<\/p>\n<ul>\n  <li><strong>H2MaxSessionStreams<\/strong>: I typically stay in the 50\u2013200 range. Too high causes head-of-line effects in the backend; too low wastes parallelism.<\/li>\n  <li><strong>MaxRequestWorkers<\/strong>: With Event, I can scale up as long as the RAM and CPU can handle it. I'm monitoring the 95th and 99th percentiles of latency as parallelism increases.<\/li>\n  <li><strong>TLS<\/strong>: Using ALPN and modern cipher suites, I reduce handshake overhead; Event also benefits because idle periods between stream bursts are efficiently managed.<\/li>\n<\/ul>\n\n<h2>Operating System Limits and Socket Backlogs<\/h2>\n<p>Before every load test, I check the system limits; otherwise, it\u2019s not the MPM that limits performance, but the kernel. For a high number of connections, I scale the following in particular:<\/p>\n<ul>\n  <li><strong>File descriptors<\/strong>: ulimit -n and systemd <code>LimitNOFILE<\/code> For example, I increase it to 65,536 or higher; Apache needs an FD per socket, log, and pipe.<\/li>\n  <li><strong>backlog<\/strong>: <code>net.core.somaxconn<\/code> and <code>tcp_max_syn_backlog<\/code> I set it to an appropriate value (e.g., 1024\u20134096) so that the accept queue does not overflow.<\/li>\n  <li><strong>Port range<\/strong> (for reverse proxy): <code>ip_local_port_range<\/code> I would set it (e.g., 10,000\u201365,000) if there are many concurrent outbound connections to backends.<\/li>\n  <li><strong>FIN\/Timeouts<\/strong>: Be careful with <code>tcp_fin_timeout<\/code>: If it's too aggressive, it can cause the connection to drop; I only make changes based on measurements.<\/li>\n<\/ul>\n<p>I document every kernel tweak along with the rationale behind it and verify it by measuring the load again. Without evidence, the default setting is usually the right one.<\/p>\n\n<h2>Monitoring and Troubleshooting in Everyday Life<\/h2>\n<p>I activate <strong>ExtendedStatus<\/strong> and use `server-status` to check the <strong>Scoreboard<\/strong>-states. Under \u201eEvent,\" I see many idle\/keep-alive sockets, even though the worker threads aren't fully utilized. The error log shows \"server reached <strong>MaxRequestWorkers<\/strong> \u201csetting, consider raising the MaxRequestWorkers setting,\" the server is already operating at its limit; I increase the value cautiously and monitor RAM\/CPU usage as well as the error rate.<\/p>\n<ul>\n  <li><strong>Measurement Fields<\/strong>: In the access logs, I record response times (e.g., %D\/%T), status codes, and bytes; I correlate peaks with CPU\/IO.<\/li>\n  <li><strong>Symptoms in Workers<\/strong>: Many keep-alive connections are inactive; 100 threads are occupied by %; increasing latency; 503\/504 errors\u2014indicating tied-up threads.<\/li>\n  <li><strong>Symptoms at an Event<\/strong>: Listener threads are heavily loaded, but worker threads are free\u2014usually a network or backend limitation, not the MPM.<\/li>\n  <li><strong>Graceful Reload<\/strong>: I'm rolling out changes with <code>apachectl -k graceful<\/code> so that existing connections can drain properly.<\/li>\n<\/ul>\n\n<h2>Capacity Planning: From Cores and RAM to MaxRequestWorkers<\/h2>\n<p>I take a pragmatic approach: How much RAM per thread, plus buffers, do I want to allow? For TLS, filters, and common modules, I make a conservative estimate of a few MB per thread. Then I set <strong>MaxRequestWorkers<\/strong> so that peak load in the 95th and 99th percentiles is handled without a swap. At the CPU level, the following applies: Threads beyond the number of cores only help as long as they aren't constantly runtime-intensive. With events, I'm willing to try higher values because idle phases hardly cost anything.<\/p>\n<ul>\n  <li><strong>Rules of Thumb<\/strong>: Start with 32\u201364 threads per process, 4\u201316 processes; then measure and adjust.<\/li>\n  <li><strong>ThreadStackSize<\/strong>: If RAM is tight and the modules allow it, I'll reduce the stack size (carefully, using a stress test).<\/li>\n  <li><strong>MaxKeepAliveRequests<\/strong>: I usually leave it at the default; with chatty clients, a higher value can reduce overhead.<\/li>\n<\/ul>\n\n<h2>Reverse Proxy Scenarios and Backend Connections<\/h2>\n<p>I especially like to use events in app backends because they <strong>Front-End Sockets<\/strong> parks efficiently, while the actual work takes place in the backend. The key factor here is the pooling of the <strong>Backend Connections<\/strong> (mod_proxy):<\/p>\n<ul>\n  <li><strong>Keep-Alive to the Backend<\/strong>: Leave enabled to save on handshakes; pool sizes (<em>max<\/em> (per destination) based on backend capacity.<\/li>\n  <li><strong>Proxy Timeouts<\/strong>: Clearly define timeouts so that unresponsive backends do not tie up front-end threads.<\/li>\n  <li><strong>HTTP\/2 to the Backend<\/strong>: Whenever possible, I use H2 (e.g., h2c internally) to reduce the number of connections while handling more streams\u2014Event works well with it.<\/li>\n<\/ul>\n<p>I specifically monitor the latency breakdown between the front end and the back end; if only the back-end time increases, MPM tuning alone won't help\u2014in that case, I'll need to adjust pool sizes, timeouts, or back-end resources.<\/p>\n\n<h2>Rollout Strategy and Migration from Worker to Event<\/h2>\n<p>I'm migrating in clear steps: First, I check the <strong>List of Modules<\/strong> (apachectl -M) to check for thread safety. Anything that isn't thread-safe (typically mod_php) must be removed or isolated. After that, I enable events, set conservative initial values, and run load tests on the staging environment. During the rollout, I start with a subset of the traffic (Canary), compare metrics, and only then roll out widely.<\/p>\n<ul>\n  <li><strong>commands<\/strong>: As is typical for this distribution, switch MPM modules (e.g., a2dismod\/a2enmod) and perform a clean restart.<\/li>\n  <li><strong>Contingency Plan<\/strong>: I have a worker profile ready in case a module behaves unusually under \"Event.\".<\/li>\n  <li><strong>Documentation<\/strong>: I document every change to limits, HTTP\/2 parameters, and kernel values with before-and-after measurements.<\/li>\n<\/ul>\n\n<h2>Focus on Security and TLS Performance<\/h2>\n<p>When it comes to TLS, I've noticed that handshakes are CPU-intensive and can increase latency under heavy load. With <strong>Session resumption<\/strong> By using modern cipher selection, I reduce costs, while Event efficiently parks idle phases. In combination with HTTP\/2 and ALPN, I avoid additional round trips. Important: TLS buffers and OpenSSL parameters contribute to the RAM footprint per thread\u2014I take them into account in capacity planning.<\/p>\n\n<h2>Fault Tolerance and Graceful Degradation<\/h2>\n<p>I'm planning for overload: Is the CPU at full capacity, or is Apache reaching <strong>MaxRequestWorkers<\/strong>, I don't want a flood of retries. I set clear timeouts, informative error pages, and rate limits on upstream proxies. With Event, more remain under pressure <strong>Threads<\/strong> available for actual work, while idle connections are parked\u2014it is precisely this reserve that keeps the system operational longer, until the load drops again or automatic scaling kicks in.<\/p>\n\n<h2>Briefly summarized<\/h2>\n\n<p>In my current operations, I rely on <strong>event<\/strong>, as long as my stack uses thread-safe modules and PHP-FPM. This approach reduces the number of bound threads for idle connections, keeps response times stable, and increases the number of users served in parallel. Worker remains a solid option for short requests with moderate keep-alive times when Event isn\u2019t suitable for organizational reasons. I reserve Prefork for setups with non-thread-safe modules or legacy code. With clear load tests, careful tuning of the directives, and visible <strong>Monitoring<\/strong> I get Apache to run at turbo speed in a reproducible manner.<\/p>","protected":false},"excerpt":{"rendered":"<p>Apache Event MPM vs. Worker MPM: Find out which MPM offers the best performance for modern web server tuning and when you should use the Event module.<\/p>","protected":false},"author":1,"featured_media":20723,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20730","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-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":"113","_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":"Apache MPM","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":"20723","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20730","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=20730"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20730\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/20723"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=20730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=20730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=20730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}