Why does the webserver throttles ajax queries - DDoS?
Asked Answered
H

1

6

I have an issue on a HTML5 web app where I have repetitive data updates via an ajax query every two seconds. The first two or three go through at 175ms, but after this, they slow down to 500ms, from then on. The hosting company swears that it is not them. I did a simple test - see test scripts below. It is not my app as this test script has the same results. My question is: Is this the hosting service throttling thinking it is a DDoS attack, or is there something I can do to stop this throttling and slowing down the ajax queries?

The index file:

<!DOCTYPE html>
<html>
<head>
<script src="jquery.min.js"></script>
<script>
$(document).ready(function(){
    $("button").click(function(){
        var count = 0;
        var my_timer = setInterval(function(){  
            $.ajax({url: "test.php", success: function(result){
                $("#div1").html(result);
            }});
            count = count + 1;
            if(count == 10) clearInterval(my_timer);
        },2000);
    });
});
</script>
</head>
<body>
<div id="div1">Let jQuery AJAX Change This Text</div>
<br>
<button>Get External Content</button>
</body>
</html>

The php file:

<?php
    echo date('h:i:s');
?>
Heer answered 20/6, 2015 at 8:33 Comment(20)
Most web browsers impose a limit on the number of concurrent requests that they will run against the same site.... every two seconds is pretty frequent, especially if they take a while to process, and they could end up being queued by the browser - tools like firebug or chrome developer tools will show you thisDelusion
How do you measure the "go through" time? I've added some timing to the javascript (start at first line of interval function, measure in success handler) and tested the script on my server, but its averaging at 40ms. (Tested with current Chrome.)Flashing
Well they are not concurrent, they are serial. Also in the test script, the one line data command is not exactly heavy. This app works on another hosting service I have. This is why I was targeting the hosting company. But is there a work around?Heer
GhostGambler Yes, I was just using the Chrome console and watching the network traffic go through. And it is easy to see the queries start out at 175ms-ish (the speed of the ping). But then they slow down after the 3 to 5 interval to 500ms from then on. And it is very consistent.Heer
Here is what Chrome says about a stalled query: Stalled 0.680 ms DNS Lookup 1.957 ms Initial connection 334.281 ms SSL 170.421 ms Request/Response TIME Request sent 0.107 ms Waiting (TTFB) 177.716 ms Content Download 0.368 ms Explanation 515.571 msHeer
Here is what Chrome says about a the intial unstalled query: Connection Setup TIME Stalled ​ 0.656 ms Request/Response TIME Request sent ​ 0.130 ms Waiting (TTFB) ​ 179.640 ms Content Download ​ 0.445 ms Explanation 181.253 msHeer
Is this a shared hoster? 500ms in initial and ssl sounds just like a "slow" server. Although I'd say everything around 500ms is "normal" timing for shared hosters. This normally varies along with the current load of the hardware.Flashing
GhostGambler well it is a VPS, so there are others on the physical server no doubt. But the CPU and Memory are both < 2% usage. I have actual a webhost service that is even less powerful and it does the queries in 175ms - all of them. Also this does not explain why the first 3 to 5 go through normally at 175ms and then rest at 500ms. And again this phenomenon is very consistent and does not appear to be variable.Heer
Does the VPS has guaranteed CPU and memory? Is your webserver spawning a new process on every request? If your hoster tells you they have no DoS mitigating feature, I would believe them and search the VM for anything which might slow down.Flashing
GhostGambler - The VPS is completely empty of anything else running. So there is nothing to search for other than this script. The server is hardly even being used. The CPU and memory are wide open and not even close to being tapped out.Heer
You must prepend usernames with @ otherwise we do not get a notification about your reaction. CPU/mem inside of your VPS do not necessarily correspond to real hardware CPU/mem — that's why I asked if you have guaranteed CPU/mem. You could try to request a HTML instead of a PHP file to eliminate PHP as a possible bottleneck.Flashing
@GhostGambler I tried just an html ajax query - no php. Same results. The server is empty really, so I really don't think it is a resource issue. It does seem that if i replay the test script without a browser refresh it still comes back slow first iteration. If I refresh the browser and then do the test script it starts fast and then slows down after the 4-6 iteration. What is this telling me?Heer
Did you try another browser? Maybe asked someone with another internet connection as well? If the problem persists with an HTML file and is independent of browser and location, you should play around with the webserver configuration. You could deactivate keep alive, make sure there are enough running processes/threads so the server definitely does not spawn some on request. You could even try it locally with the text-based browser lynx.Flashing
@GhostGambler Did you try another browser? Yes. Someone with another internet connection as well? Same results. Webserver configuration. Not sure what to do here. You could deactivate keep alive. Not sure how to do this in javascript. I tried various Ajax options (cache, connection...), and no luck. It really is just this host service. It works fine on other hosting services I have.Heer
I guess this has nothing to do with the HTML or Javascript, but with the server configuration. You can either try it yourself or ask a new question with details about the server configuration. Either way you won't get around to invest a bigger bunch of time to isolate the problem.Flashing
@GhostGambler I still think it is the hosting company throttling due to a belief that it is a DDoS attack. Everywhere else it works fine. My plan right now is to switch providers. I though maybe there was an idea out there.Heer
It's not the AWS free tier is it? They throttle the server itself after ~2 seconds of high activity. Other thoughts are: what server architecture are you using? Apache is less useful for APIs due to the more restrictive number of connections it can manage compared to something like nginx. Is your test script verbatim, is there any chance it's hitting a database, or reading more than that one file from the file system? What mods is your server using? Are you connecting directly to the server or is there a CDN or caching layer or something in between?Emmie
@Emmie Txs for the response. The VPS is 4gb 2 core, with Apache FastCGI/Php5.4 offered by 1and1. Nothing but the script running. I have an app that runs with MySQL queries but same results. I do this to simplify the issue. So I believe unrelated. AWS, CDN, caching? Ouff, dunno I have a firewall, set to wide open (and tried disabling). All the same results. I was thinking a php.ini setting, options on the Ajax call or an .htaccess setting, tried these things, but nothing. I still just think it is in the hosting provider. But was hoping for a miracle out in stackoverflow land.Heer
AWS = Amazon Web Services. They provide servers and a whole ton of other useful things too, including a CDN. CDN = Content Delivery Network. This is something that helps you spread out your content so that it can be sent to people faster. Caching is when you store information from a slow source in somewhere faster. For example you can cache database requests in memory, or cache the result of a PHP script so you don't need to run it again if it's going to be the same result. None of this sounds like your issue though so I have no more ideas. Sorry. :(Emmie
Have you tried using mod_php instead of fast cgi, it's the only other thing I we can think of. I've never compared the two directly but I've always used fast cgi with nginx and mod php with apache. As an aside, if possible you should move to PHP 5.6 too as 5.4 is down to security updates only and will stop getting those very soon.Emmie
H
1

[SOLVED] After much research into this issue. I think I have finally figured it out, or at least found a workaround. Apparently CentOS and/or Plesk Php was blocking. They way I have resolved the issue was to re-image the server on openSUSE 13.1. With this OS the Ajax queries seem to work as they should. This is just a guess, but it looks like the PHP and or the CentOS software update mechanism also has bugs in it. The updates seem to not work well and create issues. So for now I won't fix what is not broken.

Thank you for the input the commentators made, as it did point me in the right direction.

Heer answered 28/6, 2015 at 8:52 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.