[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AW: httpapi speed
Scott,
I tried the version with Nagle's algorithm disabled and it is indeed much faster: 10.000 requests now take only 20 seconds instead of the 2.100 seconds it took before. This is a huge improvement! (Delphi client is still a bit faster and takes 7 seconds for 10.000 requests)
Looking at the wireshark traces on the webserver side however I see that the packet flow is still somewhat suboptimal, compared with my Delphi client tests: instead of one paket from AS/400 to webserver for each request and one paket from the webserver back I see this:
Paket 1: 143 bytes from AS/400 to webserver ('GET /ping,htm (et al.)' plus one CR LF at the end)
Paket 2: 72 bytes from AS/400 to webserver (just one CR LF)
Paket 3: 70 bytes from webserver to AS/400 (ACK)
Paket 4: 338 bytes from webserver to AS/400 (result of GET)
The Delphi client sends only one paket and receives one paket.
I will now see that I make my modification to send the CRLF together with the first sendreq operation in do_Oper() and see if this makes things better or worse.
Peter
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Saturday, May 31, 2014 5:18 AM
To: HTTPAPI and FTPAPI Projects
Subject: Re: AW: httpapi speed
Hello Peter,
Okay, here is a version of HTTPAPI that has Nagle's algorithm disabled.
It does NOT have your changes in it (so that we can tell if Nagle's algorithm helps or not.)
SAVF: http://www.scottklement.com/httpapi/test1/httpapi.savf
ZIP: http://www.scottklement.com/httpapi/test1/httpapi.zip
So please test that and see if it's faster or not. Then, if you like,
you can make your modification and see if that helps/hurts performance.
Please let me know what you find.
On 5/30/2014 5:04 PM, Sawatzki, Peter wrote:
> Scott,
>
> yes, I'd be happy to test this in any way you like. I can also capture wireshark traces on the webserver for inspection.
>
> " I'm thinking that (like Brian said) this might be related to Nagle's algorithm. The way Nagle's algorithm works is that the system tries to fit as much as possible into each packet, so if there's only a small amount of data in a packet, it adds a short delay to wait for more data. This could be the delay you're seeing."
>
> I see the delay exactly in the moment where httapi reads the first character in commtcp_lineread from the response to each request.
>
> Peter
>
> -----Ursprüngliche Nachricht-----
> Von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Im Auftrag von Scott
> Klement
> Gesendet: Freitag, 30. Mai 2014 22:39
> An: HTTPAPI and FTPAPI Projects
> Betreff: Re: httpapi speed
>
> Thanks, Peter.
>
> My concern with this fix is that it seems like it would be dependent on the exact length of your request. The TCP protocol built-in to the operating system automatically splits the data into packets, so for a longer/shorter request, the data in the request would end up being split differently.
>
> also, it shouldn't matter whether the CRLF is sent in one call to
> SendReq() or two. The data should all be put together... That's the
> way the TCP protocol works.
>
> I'm thinking that (like Brian said) this might be related to Nagle's algorithm. The way Nagle's algorithm works is that the system tries to fit as much as possible into each packet, so if there's only a small amount of data in a packet, it adds a short delay to wait for more data. This could be the delay you're seeing.
>
> If I made a copy of HTTPAPI with Nagle's algorithm disabled, would you be willing to give it a try and see if it helps? We could try it both with your update and without, and you could tell me what sort of difference it makes.
>
> Sound good?
>
>
>
> On 5/30/2014 2:27 PM, Sawatzki, Peter wrote:
>> Scott,
>>
>> I modified HTTPAPIR4, procedure do_oper() to add the CRLF directly to the request when no additonal header is present. If an additional header is present, the requests are sent in three parts as before.
>>
>> After this modification HTTPAPI is as fast as the PC clients (100 times faster in my tests).
>>
>> I changed this:
>>
>> ...
>> *********************************************************
>> * Send request chain & get response
>> *********************************************************
>> c if %len(wwAddlHdr) = 0
>> c eval wwReqChain = wwReqChain + CRLF
>> c endif
>> c eval rc = SendReq( peComm
>> c : %addr(wwReqChain)+VARPREF
>> c : %len(wwReqChain)
>> c : peTimeout )
>> c if rc < 1
>> c return rc
>> c endif
>>
>> c if %len(wwAddlHdr) > 0
>> c eval rc = SendReq( peComm
>> c : %addr(wwAddlHdr)+VARPREF
>> c : %len(wwAddlHdr)
>> c : peTimeout )
>> c if rc < 1
>> c return rc
>> c endif
>>
>> c eval wwReqChain = CRLF
>> c eval rc = SendReq( peComm
>> c : %addr(wwReqChain)+VARPREF
>> c : %len(wwReqChain)
>> c : peTimeout )
>> c if rc < 1
>> c return rc
>> c endif
>> c endif
>>
>> *********************************************************
>> * If this request requires a request-body (POST/PUT data)
>> * then it should be sent, here.
>> *********************************************************
>> c if peOper='PUT' or peOper='POST'
>> ...
>>
>>
>> -----Original Message-----
>> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Sawatzki,
>> Peter
>> Sent: Friday, May 30, 2014 12:01 PM
>> To: 'HTTPAPI and FTPAPI Projects'
>> Subject: RE: httpapi speed
>>
>> Scott,
>>
>> I implemented the changes you suggested in my test program but unfortunatly the performance didn't impoved at all.
>>
>> To further eliminate any other issues I may have I used a toString procedure that does nothing (just returns the length) and I'm reuqsting a simple static htm file that has only "pong" as a contents (4 bytes). So I'm simply calling "http://192.168.101.5/ping.htm";.
>>
>> ...
>> ---------------------------------------------------------------------
>> -
>> - This is the FTPAPI mailing list. To unsubscribe, please go to:
>> http://www.scottklement.com/mailman/listinfo/ftpapi
>> ---------------------------------------------------------------------
>> -
>> -
>>
> ----------------------------------------------------------------------
> - This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> ----------------------------------------------------------------------
> -
> ----------------------------------------------------------------------
> - This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> ----------------------------------------------------------------------
> -
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------