date:20160418

Re: [twsocket] SSL post extremely slow

2016-04-18 Thread brian -

You never mentioned you were testing the synchronous methods of the
component, that is not a fair test of ICS performance, you should be
using proper events and the async component methods.


I'm observing the same issue with async calls though, did the same test
from above but this time with PostAsync, waited for RequestDone: 49 seconds.



On Mon, Apr 18, 2016 at 6:06 PM, brian -  wrote:

> Captured with Microsoft Network Monitor, non-SSL post to my server:
>
> Synapse: 3.8s http://pasted.co/1f69a8a8
> ICS: 46.5s
> https://mega.nz/#!b05jyRzT!hLB8_xKHeHJyRb7nAXcQDM2mv0_RW9uf4y-iN3e6gkc
> (too large for text paste sites)
>
> few lines from each:
>
> Frame, time, time offset, process, source, destination, protocol,
> description, conv id
>
> SYN
> 52017:41:32 2016-Apr-1810.0849405Project1.exe
> 192.168.0.2**dest host**TCPTCP:[Continuation to
> #474]Flags=...A, SrcPort=58338, DstPort=HTTP(80), PayloadLen=1436,
> Seq=61535050 - 61536486, Ack=220751404, Win=258 (scale factor 0x8) =
> 66048{TCP:75, IPv4:18}
> 52117:41:32 2016-Apr-1810.0849470Project1.exe
> 192.168.0.2**dest host**TCPTCP:[Continuation to
> #474]Flags=...A, SrcPort=58338, DstPort=HTTP(80), PayloadLen=1436,
> Seq=61536486 - 61537922, Ack=220751404, Win=258 (scale factor 0x8) =
> 66048{TCP:75, IPv4:18}
> 52217:41:32 2016-Apr-1810.1643870Project1.exe**dest
> host**192.168.0.2TCPTCP:Flags=...A, SrcPort=HTTP(80),
> DstPort=58338, PayloadLen=0, Seq=220751404, Ack=61391450, Win=1167 (scale
> factor 0x7) = 149376{TCP:75, IPv4:18}
> 52317:41:32 2016-Apr-1810.1644469Project1.exe
> 192.168.0.2**dest host**TCPTCP:[Continuation to
> #474]Flags=...A, SrcPort=58338, DstPort=HTTP(80), PayloadLen=1436,
> Seq=61537922 - 61539358, Ack=220751404, Win=258 (scale factor 0x8) =
> 66048{TCP:75, IPv4:18}
> 52417:41:32 2016-Apr-1810.1644572Project1.exe
> 192.168.0.2**dest host**TCPTCP:[Continuation to
> #474]Flags=...A, SrcPort=58338, DstPort=HTTP(80), PayloadLen=1436,
> Seq=61539358 - 61540794, Ack=220751404, Win=258 (scale factor 0x8) =
> 66048{TCP:75, IPv4:18}
> 52517:41:32 2016-Apr-1810.1647476Project1.exe**dest
> host**192.168.0.2TCPTCP:Flags=...A, SrcPort=HTTP(80),
> DstPort=58338, PayloadLen=0, Seq=220751404, Ack=61394322, Win=1167 (scale
> factor 0x7) = 149376{TCP:75, IPv4:18}
> 52617:41:32 2016-Apr-1810.1647476Project1.exe**dest
> host**192.168.0.2TCPTCP:Flags=...A, SrcPort=HTTP(80),
> DstPort=58338, PayloadLen=0, Seq=220751404, Ack=61397194, Win=1167 (scale
> factor 0x7) = 149376{TCP:75, IPv4:18}
> 52717:41:32 2016-Apr-1810.1647476Project1.exe**dest
> host**192.168.0.2TCPTCP:Flags=...A, SrcPort=HTTP(80),
> DstPort=58338, PayloadLen=0, Seq=220751404, Ack=61402938, Win=1167 (scale
> factor 0x7) = 149376{TCP:75, IPv4:18}
> 52817:41:32 2016-Apr-1810.1647731Project1.exe
> 192.168.0.2**dest host**TCPTCP:[Continuation to
> #474]Flags=...A, SrcPort=58338, DstPort=HTTP(80), PayloadLen=1436,
> Seq=61540794 - 61542230, Ack=220751404, Win=258 (scale factor 0x8) =
> 66048{TCP:75, IPv4:18}
> 52917:41:32 2016-Apr-1810.1647817Project1.exe
> 192.168.0.2**dest host**TCPTCP:[Continuation to
> #474]Flags=...A, SrcPort=58338, DstPort=HTTP(80), PayloadLen=1436,
> Seq=61542230 - 61543666, Ack=220751404, Win=258 (scale factor 0x8) =
> 66048{TCP:75, IPv4:18}
>
> ICS
> 225117:50:17 2016-Apr-18177.9631709Project1.exe
> 192.168.0.2 **dest host**HTTPHTTP:HTTP Payload, URL:
> /test/upload.php {HTTP:289, TCP:288, IPv4:18}
> 225217:50:17 2016-Apr-18177.9631750Project1.exe
> 192.168.0.2 **dest host**TCPTCP:[Continuation to
> #2251]Flags=...AP..., SrcPort=58460, DstPort=HTTP(80), PayloadLen=24,
> Seq=458800455 - 458800479, Ack=3147579723, Win=258 (scale factor 0x8) =
> 66048{TCP:288, IPv4:18}
> 225317:50:17 2016-Apr-18177.9631908Project1.exe
> 192.168.0.2 **dest host**HTTPHTTP:HTTP Payload, URL:
> /test/upload.php {HTTP:289, TCP:288, IPv4:18}
> 225417:50:17 2016-Apr-18177.9631942Project1.exe
> 192.168.0.2 **dest host**TCPTCP:[Continuation to
> #2253]Flags=...AP..., SrcPort=58460, DstPort=HTTP(80), PayloadLen=24,
> Seq=458801915 - 458801939, Ack=3147579723, Win=258 (scale factor 0x8) =
> 66048{TCP:288, IPv4:18}
> 225517:50:17 2016-Apr-18177.9632252Project1.exe
> 192.168.0.2 **dest host**HTTPHTTP:HTTP Payload, URL:
> /test/upload.php {HTTP:289, TCP:288, IPv4:18}
> 225617:50:17 2016-Apr-18177.9632296Project1.exe
> 192.168.0.2 **dest host**TCPTCP:[Continuation to
> #2255]Flags=...AP..., SrcPort=58460, DstPort=HTTP(80), PayloadLen=24,
> Seq=458803375 - 458803399, Ack=3147579723, Win=258

Re: [twsocket] SSL post extremely slow

2016-04-18 Thread Angus Robertson - Magenta Systems Ltd

> Captured with Microsoft Network Monitor, non-SSL post to my 
> server:
> Synapse: 3.8s http://pasted.co/1f69a8a8
> ICS: 46.5s

All these measurements have little value when you are not comparing
like with like.  

After my last message, I assume you have redesigned your ICS
application to use async events and not slow sync events.  And what
buffer sizes?  Did you change all the different buffers, including file
I/O?  Or some or none.

For a third time, I will investigate this properly when I have spare
time, probably next month.  

You don't need to keep telling us ICS is slower, we know already.

Angus
 

-- 
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

Re: [twsocket] SSL post extremely slow

2016-04-18 Thread brian -

Captured with Microsoft Network Monitor, non-SSL post to my server:

Synapse: 3.8s http://pasted.co/1f69a8a8
ICS: 46.5s
https://mega.nz/#!b05jyRzT!hLB8_xKHeHJyRb7nAXcQDM2mv0_RW9uf4y-iN3e6gkc (too
large for text paste sites)

few lines from each:

Frame, time, time offset, process, source, destination, protocol,
description, conv id

SYN
52017:41:32 2016-Apr-1810.0849405Project1.exe192.168.0.2
**dest host**TCPTCP:[Continuation to #474]Flags=...A,
SrcPort=58338, DstPort=HTTP(80), PayloadLen=1436, Seq=61535050 - 61536486,
Ack=220751404, Win=258 (scale factor 0x8) = 66048{TCP:75, IPv4:18}
52117:41:32 2016-Apr-1810.0849470Project1.exe192.168.0.2
**dest host**TCPTCP:[Continuation to #474]Flags=...A,
SrcPort=58338, DstPort=HTTP(80), PayloadLen=1436, Seq=61536486 - 61537922,
Ack=220751404, Win=258 (scale factor 0x8) = 66048{TCP:75, IPv4:18}
52217:41:32 2016-Apr-1810.1643870Project1.exe**dest
host**192.168.0.2TCPTCP:Flags=...A, SrcPort=HTTP(80),
DstPort=58338, PayloadLen=0, Seq=220751404, Ack=61391450, Win=1167 (scale
factor 0x7) = 149376{TCP:75, IPv4:18}
52317:41:32 2016-Apr-1810.1644469Project1.exe192.168.0.2
**dest host**TCPTCP:[Continuation to #474]Flags=...A,
SrcPort=58338, DstPort=HTTP(80), PayloadLen=1436, Seq=61537922 - 61539358,
Ack=220751404, Win=258 (scale factor 0x8) = 66048{TCP:75, IPv4:18}
52417:41:32 2016-Apr-1810.1644572Project1.exe192.168.0.2
**dest host**TCPTCP:[Continuation to #474]Flags=...A,
SrcPort=58338, DstPort=HTTP(80), PayloadLen=1436, Seq=61539358 - 61540794,
Ack=220751404, Win=258 (scale factor 0x8) = 66048{TCP:75, IPv4:18}
52517:41:32 2016-Apr-1810.1647476Project1.exe**dest
host**192.168.0.2TCPTCP:Flags=...A, SrcPort=HTTP(80),
DstPort=58338, PayloadLen=0, Seq=220751404, Ack=61394322, Win=1167 (scale
factor 0x7) = 149376{TCP:75, IPv4:18}
52617:41:32 2016-Apr-1810.1647476Project1.exe**dest
host**192.168.0.2TCPTCP:Flags=...A, SrcPort=HTTP(80),
DstPort=58338, PayloadLen=0, Seq=220751404, Ack=61397194, Win=1167 (scale
factor 0x7) = 149376{TCP:75, IPv4:18}
52717:41:32 2016-Apr-1810.1647476Project1.exe**dest
host**192.168.0.2TCPTCP:Flags=...A, SrcPort=HTTP(80),
DstPort=58338, PayloadLen=0, Seq=220751404, Ack=61402938, Win=1167 (scale
factor 0x7) = 149376{TCP:75, IPv4:18}
52817:41:32 2016-Apr-1810.1647731Project1.exe192.168.0.2
**dest host**TCPTCP:[Continuation to #474]Flags=...A,
SrcPort=58338, DstPort=HTTP(80), PayloadLen=1436, Seq=61540794 - 61542230,
Ack=220751404, Win=258 (scale factor 0x8) = 66048{TCP:75, IPv4:18}
52917:41:32 2016-Apr-1810.1647817Project1.exe192.168.0.2
**dest host**TCPTCP:[Continuation to #474]Flags=...A,
SrcPort=58338, DstPort=HTTP(80), PayloadLen=1436, Seq=61542230 - 61543666,
Ack=220751404, Win=258 (scale factor 0x8) = 66048{TCP:75, IPv4:18}

ICS
225117:50:17 2016-Apr-18177.9631709Project1.exe
192.168.0.2 **dest host**HTTPHTTP:HTTP Payload, URL:
/test/upload.php {HTTP:289, TCP:288, IPv4:18}
225217:50:17 2016-Apr-18177.9631750Project1.exe
192.168.0.2 **dest host**TCPTCP:[Continuation to
#2251]Flags=...AP..., SrcPort=58460, DstPort=HTTP(80), PayloadLen=24,
Seq=458800455 - 458800479, Ack=3147579723, Win=258 (scale factor 0x8) =
66048{TCP:288, IPv4:18}
225317:50:17 2016-Apr-18177.9631908Project1.exe
192.168.0.2 **dest host**HTTPHTTP:HTTP Payload, URL:
/test/upload.php {HTTP:289, TCP:288, IPv4:18}
225417:50:17 2016-Apr-18177.9631942Project1.exe
192.168.0.2 **dest host**TCPTCP:[Continuation to
#2253]Flags=...AP..., SrcPort=58460, DstPort=HTTP(80), PayloadLen=24,
Seq=458801915 - 458801939, Ack=3147579723, Win=258 (scale factor 0x8) =
66048{TCP:288, IPv4:18}
225517:50:17 2016-Apr-18177.9632252Project1.exe
192.168.0.2 **dest host**HTTPHTTP:HTTP Payload, URL:
/test/upload.php {HTTP:289, TCP:288, IPv4:18}
225617:50:17 2016-Apr-18177.9632296Project1.exe
192.168.0.2 **dest host**TCPTCP:[Continuation to
#2255]Flags=...AP..., SrcPort=58460, DstPort=HTTP(80), PayloadLen=24,
Seq=458803375 - 458803399, Ack=3147579723, Win=258 (scale factor 0x8) =
66048{TCP:288, IPv4:18}
225717:50:17 2016-Apr-18177.9632594Project1.exe
192.168.0.2 **dest host**HTTPHTTP:HTTP Payload, URL:
/test/upload.php {HTTP:289, TCP:288, IPv4:18}
225817:50:17 2016-Apr-18177.9632631Project1.exe
192.168.0.2 **dest host**TCPTCP:[Continuation to
#2257]Flags=...AP..., SrcPort=58460, DstPort=HTTP(80), PayloadLen=24,
Seq=458804835 - 458804859, Ack=3147579723, Win=258 (scale factor 0x8) =
66048{TCP:288, IPv4:18}
225917:50:17 2016-Apr-18178.0811555Project1.exe

Re: [twsocket] SSL post extremely slow

2016-04-18 Thread Angus Robertson - Magenta Systems Ltd

> 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;

You never mentioned you were testing the synchronous methods of the
component, that is not a fair test of ICS performance, you should be
using proper events and the async component methods.   

MsgWaitForMultipleObjects has always been known to reduce performance
in sync applications, I always override it if using sync versions, such
as my TMagFtp and TMagHttp components.  

But without MsgWaitForMultipleObjects, your application will appear to
use 100% CPU (or 50% if two cores, etc) and some users think that is
bad, yet other heavy applications will still run fine.   

Angus

-- 
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

Re: [twsocket] SSL post extremely slow

2016-04-18 Thread Angus Robertson - Magenta Systems Ltd

> Do you think there might be an easy solution to this coming soon? 
> the problem is pretty serious, 

I would disagree this a serious problem, it might be annoying that your
ICS implementation runs slower than some other applications, but it's
hardly a major show stopper.  

HTTP was never designed as a high speed upload protocol, the first T
stands for text, FTP is the upload protocol of choice.  Our HTTP
component was designed 20 years ago when high speeds were unheard of
and was not optimised for such use.  

As I said last week, the HTTP client component needs larger buffers and
maybe other minor changes to improve performance, but there are other
ICS priorities that are more important. 

All ICS development is done by volunteers, you need to be patient until
people have spare time to respond to your queries.  

Angus
 

-- 
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

Re: [twsocket] TCP Bridges (Dennis Siggaard)

2016-04-18 Thread Wilfried Mestdagh


Hi Dennis,

SocketSpy works that way. If a client opens 6 sessions then SocketSpy 
will open 6 sessions to the other server using 6 TWSocket created on the 
fly.


Met vriendelijke groeten,
Wilfried Mestdagh

Op 17-04-16 om 15:57 schreef IT+NET - Dennis Siggaard:

Hi Wilfried,


I have already looked at the SocketSpy example once, but this time I got it to 
work, Thanks :)

But I got one last problem, that I am not sure can be solved at all ?


The PC2 webserver is listening (OK)
The PC2 TWSocketLocal can connect to the PC2 Webserver (ok)
The PC2 TWSocketExt can connect to PC1 TWSocketServerExt (ok)
The PC2 TCP bridge is working both ways (ok) (I see the right traffic flowing 
both ways)

The PC1 TWSocketServerExt is listening (OK)
The PC1 TWSocketServerLocal is listening (OK)
The PC1 TCP bridge is working both ways (ok) (I see the right traffic flowing 
both ways)

When I telnet to PC1:80 then everything seems to be okey traffic is flowing 
perferctly in both TCP bridges, but... surprise.

When I use a webbrowser to connect to PC1:80, it creates multiply connections 
to PC1:80. (6 connections at the same time)

>From my point of view, it would be impossible to bridge these (extra) 
connections, because there will always only be ONE connection (PC2 TWSocketExt 
connect to PC1 TWSocketServerExt)

Is this an dead end, or can you see something that I can't ?
I really spend many hours to get to this point. :(

Dennis.


--
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

Re: [twsocket] SSL post extremely slow

Re: [twsocket] SSL post extremely slow

Re: [twsocket] SSL post extremely slow

Re: [twsocket] SSL post extremely slow

Re: [twsocket] SSL post extremely slow

Re: [twsocket] TCP Bridges (Dennis Siggaard)

6 matches

Site Navigation

Mail list logo

Footer information