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