A customer’s websites periodically became noticeably slower. The applications themselves had not changed, but server load increased when large volumes of automated requests reached the websites. The increased traffic affected response times and reduced overall service stability. The goal was to determine whether the slowdown was caused by insufficient server resources or by traffic that did not need to reach the origin server at all.<\/span><\/p>\n The performance problem was associated with increased traffic generated by bots. Even when automated requests are technically valid HTTP requests, processing large numbers of them consumes infrastructure resources. Each request may require the server to accept a connection, process the HTTP request, execute web-server rules, pass the request to an application, and generate or retrieve content. As the number of unnecessary requests grows, legitimate users must compete for the same CPU, memory, application workers, and network capacity. Simply upgrading the server would therefore not address the underlying cause. The unwanted traffic needed to be filtered before it consumed origin-server resources.<\/span><\/p>\n 1. Investigated the source of the load<\/b><\/p>\n The support team analyzed the performance issue and identified increased automated traffic as a significant contributor to the server load. The problem was therefore not treated simply as insufficient hardware performance.<\/span><\/p>\n 2. Moved the domains to CDN nameservers<\/b><\/p>\n The affected domains were transferred to CDN nameservers. This added an external layer between incoming traffic and the customer’s origin infrastructure. Instead of all requests reaching the web server directly, traffic first passed through CDN.<\/span><\/p>\n 3. Configured filtering of unwanted traffic<\/b><\/p>\n Traffic filtering was configured so that unwanted automated requests could be handled before reaching the customer’s server. This reduced the amount of unnecessary traffic that the origin infrastructure had to process.<\/span><\/p>\n 4. Verified website operation<\/b><\/p>\n After the filtering changes were applied, the websites were tested again. The reduction in unwanted requests lowered server load and improved normal website responsiveness.<\/span><\/p>\n When server performance degrades, increasing CPU or RAM can sometimes help. But adding hardware does not always solve the actual problem. If a large portion of the workload consists of traffic that the application should not be processing in the first place, increasing server capacity simply allows the infrastructure to process more unwanted requests. Filtering the traffic earlier in the request path reduces the amount of work performed by the origin server. This approach addressed the source of the load rather than only increasing the capacity available to absorb it.<\/span><\/p>\n The work included performance troubleshooting, traffic analysis, domain DNS migration, CDN nameserver configuration, unwanted traffic filtering, origin-server verification, and post-change performance testing.<\/span><\/p>\n The amount of unnecessary traffic reaching the customer’s server was reduced. As a result, server load decreased and website response times improved noticeably without relying only on additional hardware resources. The customer retained the existing application environment while adding an external traffic-filtering layer in front of the origin servers.<\/span><\/p>\n <\/p>\n Results at a glance<\/b>: bot traffic identified, CDN introduced in front of the origin, unwanted requests filtered, server load reduced, website performance improved.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" Initial situation A customer’s websites periodically became noticeably slower. The applications themselves had not changed, but server load increased when large volumes of automated requests reached the websites. The increased traffic affected response times and reduced overall service stability. The goal was to determine whether the slowdown was caused by insufficient server resources or by […]<\/p>\n","protected":false},"author":7,"featured_media":9218,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49],"tags":[],"class_list":["post-9217","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-case-study","has-post-title","has-post-date","has-post-category","has-post-tag","has-post-comment","has-post-author",""],"yoast_head":"\nTechnical Challenge<\/b><\/h2>\n
What the Unihost Team Did<\/b><\/h2>\n
Why Traffic Filtering Was Better Than Simply Adding Resources<\/b><\/h2>\n
Unihost Support Work<\/b><\/h2>\n
Result<\/b><\/h2>\n