Hm not sure if you can see my previous thread messages, I did some little
analysis:

ICS: ~23s, 377 x 8KB, 55-60ms between packets: http://pastebin.com/Uq5mphUH
ICS @ 64KB: ~22s, 48 x 64KB, 450-470ms between packets:
http://pastebin.com/wTat71Qe
SYN: ~6s, 49 x 64KB, 110-120ms between packets: http://pastebin.com/g5svt11P
Indy: ~9s, 95 x 32KB, 70-80ms between packets: http://pastebin.com/Dt2PydTR
WinInet: ~6s, 190 x ~16KB, 5-55ms between packets,
http://pastebin.com/jZLvua5u

then tried to log timings through various stages of the post, albeit not
being that helpful, I think the main issue lies on OverbyteIcsHttpProt
around

    while FState <> httpReady do begin
>       {$IFDEF MSWINDOWS}
>         if MsgWaitForMultipleObjects(0, Pointer(nil)^, FALSE, 1000,
>                                      QS_ALLINPUT) = WAIT_OBJECT_0 then
>       {$ENDIF}
>             MessagePump;
>

I'll check on wireshark.


On Mon, Apr 18, 2016 at 4:44 PM, RTT <p...@sapo.pt> wrote:

> On 18/04/2016 15:15, brian - wrote:
>
>> I know ICS is made for free by volunteers, I'm not expecting/demanding a
>> fix, but I think this is an issue that we could look into to try to find a
>> solution/find the core problem together.
>>
>
> To start, you could compare the characteristics of the packets being sent
> (e.g. using Wireshark), and the times involved, so we can get a general
> idea of what is being done differently in these HTTP components. Maybe this
> general analyzes offers the clues for what code needs to be
> optimized/profiled.
>
> --
> To unsubscribe or change your settings for TWSocket mailing list
> please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
> Visit our website at http://www.overbyte.be
>
-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to