Sounds like a problem with your code if it can't handle 2 edits a second.

>>54576708
Would it be? I figured I'd get some sort of response if it was a code related problem, but nothing, the server just stops responding.

>>54576757
Stops responding in what way? In that the server program stops running, or the server itself drops requests? i.e if you ping the IP it doesnt pick it up

>>54576858
Server drops the request entirely. The script itself is fine, I ran the same load test internally and got responses/successes every time.

>>54576858
Here's a python script I used for one of the tests:

import urllib2
import json
from httplib import BadStatusLine


def dorequest(number):
    fails = 0;
    success = 0;
    failcode = 0;
    for i in range(number):
        data = '{"fake_json_goes_here"}'

        req = urllib2.Request('http://oursite.com.au/API/')
        req.add_header('Content-Type', 'application/json')
        try:        
            response = urllib2.urlopen(req)
            #html = response.read()
            #parsed = json.loads(html);
            #print parsed['success'];
            httpcode = response.getcode();
            print httpcode
            if(httpcode == 200):
                success += 1;
            else:
                failcode += 1;
        except BadStatusLine:
                fails += 1;

    print success
    print fails
    print failcode

dorequest(200);

The resulting output:

200
200 (etc etc etc)
42
158
0

>>54576873

maybe somebody is doing load shaping in the internet between client and server?

intelligently drop a few packets here and there and everything goes to shit.

Are you opening and closing ports per request?

Are you sure the request is even making it to the server? Is a timeout cleaning everything up too soon?

can you log with time-stamps the received requests and responses to see if latency explodes for no reason.

I don't do web development; mostly super low level stuff and deep embedded.

>>54576643
look at your webserver logs. see if the dropped requests reached the webserver
Are you behind cloudflare or some sort of cache?

>>54576960
This. Could be a firewall setting to drop packets from an IP if it sends more packets per x time than y limit.

>>54576945
We record all requests to the API, the request never reaches the server when I start getting the timeouts.

>>54576960

Nope, no cloudflare.

So is the host at fault, do you think? Like I said, I've checked our resource allocations and everything is within the supposed limits.

>>54576982
Oh shiiiit, I will check that.

>>54576991
>We record all requests to the API, the request never reaches the server when I start getting the timeouts.

but at what level are the requests disappearing? Can you stick wireshark on the client or server(preferred) and see the exact point that things stop working?

>>54577035
The first thing the script does it grab the contents of the POST, check if it's valid JSON, check if the JSON contains all the keys we need, and stores it along with an IP and a timestamp. The requests just straight up stop being received at the entry point.

>>54577077
Pls halp.

>>54576991
How do you get it working again? Do you restart something your side or their side? That would be the biggest indicator of where the problem lies.

>>54576925
rewrite it in C

>>54577197

I'm just saying you need to look at this at the layers below your high level view.

Like for example (I don't do python) it looks like your code is opening and closing a tcp port per transaction. That is a perfect place for a man in the middle to rate-limit you by dropping TCP packets thinking your are doing a DOS attack.

But hell, I have no idea of how the python http library is implemented. How is each connection cleaned up on the client? (not that that really matters if you have tested the client and server on the same nw and it works fine).

That's what a tool like wireshark is going to tell you; at exactly what point in the protocol/handshaking are things going south.

to me though that loop containing urlopen looks suspicious; IF it is actually opening and closing a tcp port per call. But, I don't deal with web protocols, and I know they don't really care very much about overhead in that world.

If you want performance you want to open and close a tcp port once per big transaction and send as much data at a time in one direction as possible. Do as little handshaking as possible. in the 'c' you would want to use as large buffers as you can, and write as many bytes as you can per call.

But this web stuff is layers upon layers of 'stuff' hidden behind libraries - and then python on top of that.

Good luck good sir.