BorlandTalk.com

Chad Z. Hower aka Kudzu · Guest

Im just starting on very preliminary tests. But std thread model (Indy 9)
versus the new supercore with fibers and IOCP.... mind you literally NO
optimization has been done on it yet... and im testing with 5-30 client
threads each full speed pounding the server. Will test bigger amounts later
with multiple machines.

Using 5 threads running for 30 seconds (Client)

Server with normal threads. Continuous connect, not reconnect so pooling
does not come into play here.
399 per second per thread.

SAME server. SAME code, but with different schdeuler (Fiber) and IOHandler
(IOCP). Running on ONE THREAD.
639 per second per thread.

And used 50% of the CPU the threaded one did during its run.
Pretty impressive - but more impressive is that we have not done
optimizations yet, and that the connect area is a bottleneck right now, and
always a bit in the overhead.

What are the requests? Its a demo I built - doestn matter right now. The
comparisons do. ;)

I should also mention that these are the FIRST actualy measurements we have
performed. Till now its ALL been implementation - just making it work.

Windows XP Pro. Client and server on same machine for this test.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Got Indy? Got the book?

http://www.atozedsoftware.com/indy/book/

ELKNews - Get your free copy at http://www.atozedsoftware.com

Trev · Guest

Wow! Looks impressive. Can't wait to see the optimised results.

Keep up the great work :)

Trev

"Chad Z. Hower aka Kudzu" <cpub (AT) hower (DOT) org> wrote

Cruxy · Guest

This are really good news... This something different, most of the time
everything becomes slower with a new release.... impressive in any case
- nearly doubling the management speed....

Charles Stack · Guest

What does those number mean exactly 399 per second per thread? Is that
connections per second?

What exactly are you measuring?

Are you using the loopback adapter (i.e. 127.0.0.1) or evaluating this for
traffic passing through a real NIC?

Why did you limit your stress tests for 30 seconds? Did performance drop or
did you just get bored? ;-)

I'll be far more impressed when I see how this behaves over a real network
than on the same machine. I still remember everyone complaining about
skewed results when DxSock's ran their numbers on the same machine. I,
personally, was far more impressed when I saw how it performed over a
network while watching server load remain at less than 6% and watching other
socket libraries barely able to breath (let alone keep up).

Perhaps a better test to show overall overall performance would be to
implement, say, a simple HTTP server using INDY 9 and INDY 10 and
benchmarking them against one of the well known stress testers over, say, a
100 MB or GB LAN. Measure number of HTTP transactions served/sec using the
two different models. Then, when you've optimized INDY 10 an think you've
squeezed every last performance tweek from it, compare it against other
commercial systems such as IIS or Winshock Web Server (WWS) for comparable
transactions (i.e. GET and PUT) and tweek some more.

Of course, this gets us back into that whole benchmarking
discussion/argument again. ;-)

Regards,

Charles

Chad Z. Hower aka Kudzu · Guest

"Charles Stack" <charles> wrote in news:3f8b48cd (AT) newsgroups (DOT) borland.com:

Charles Stack · Guest

Listen, Chad. I'm not trying to be argumentative. I'm just saying, like
you, that the numbers are all relative. What they are relative too is the
question.

To say you are getting X connections per second per thread on localhost
really has not meaning (unless you are running all your processes on the
same machine) other than to say that you've optimized some of your handling
and it appears twice as fast as INDY 9. TCP/IP communications via localhost
do not traverse the full network stack as it would with a real NIC and
network. What really matters is true performance over a real network using
real NICS and real protocols.

Yes, I realize you've said the numbers are preliminary. I also remember
how people went crazy when performance numbers were released comparing
DxSock to some of the other socket libraries (INDY included). I still
remember when there were statements made that INDY 9 would be tweaked for
performance and that it would perform better in subsequent benchmarks. What
we ended up with is another rewrite of INDY (8,9 and now 10). If those
rewrites ultimately mean better performance and minimal impact on existing
designs, then that's a good thing. If those rewrites improve the design
process for new applications, that's a good thing as well.

What the numbers do show, on a positive note, is that you are learning from
past mistakes and taking new approaches to improved the performance of INDY.
You are rethinking your design. A 100% performance increase in your
"preliminary" findings is, in my book, yet another a good thing.

What philosophy changes to socket programming did you make when making the
jump from INDY 9 to INDY 10? Why?

I asked about the 30 second test because if there are memory or resource
leaks in INDY 10, performance will be high intially and then suffer greatly
after a short run time. For people building new applications and deciding
on which library to use, this could have serious repercusions down the road
(despite INDY 10 being beta...people will still use it in production work).
If you're confident that there are no leaks, then I say "Bravo!" and keep
fine tuning. We are are looking forward to an improved INDY.

Charles

"Chad Z. Hower aka Kudzu" <cpub (AT) hower (DOT) org> wrote

Chad Z. Hower aka Kudzu · Guest

"Charles Stack" <charles.stack (AT) verizon (DOT) net> wrote in
news:3f8eb98a$1 (AT) newsgroups (DOT) borland.com:

Charles Stack · Guest

<argumentative>

No. You missed the WHOLE point and instead choose to try to belittle my
point rather than address my points factually.

The numbers you provided are meaningless except to say you can communicate
locally twice as fast. It is not indicative of performance that one will
receive on real world hardware or network as your packets don't traverse a
real TCP/IP stack.

Run the tests over a real network between two PCs (use a cross connect cable
if you want). It doesn't matter if you get 1 transaction per second on INDY
9 and 2 on INDY 10. The point then is that you have real numbers that
indicate the relative performance relative to your handling of sockets and
threads.

As a suggestion, you may also want to indicate how quickly your code and
address dynamic connections rather than continuous. That would show how
well your code handles connects and disconnects. Perhaps, write a really
simple web server using INDY 9 and 10 (keep the pages in memory to eliminate
disk i/o) and run WinStress. But, don't run client and server on the same
machine - that's pointless.

Personally, I don't give a rat's a@@ how the numbers turn out. My
suggestions are how to better measure your code in a manner that provides
meaningful results. I am not asking you to compare it against DxSock, ICS,
Synapse or whatever. You're not yet ready to do that and I accept that.
That is not the issue here. Providing true measures of performance,
however, is the issue at hand.

</argumentative>

"Chad Z. Hower aka Kudzu" <cpub (AT) hower (DOT) org> wrote

Hadi Hariri · Guest

Charles Stack · Guest

Why? Because the numbers he posted are bogus with the expectation that
people might think they mean something. Why post BS numbers when he could
just as easily posted numbers that have value? With two weeks to BORCON,
the least he could do is post numbers showing real progress and performance
stats for INDY 10 over INDY 9 rather than posting fluff with abolutely no
meaning.

Why not answer my questions regarding performance, stability and design
philosophy for INDY 10 and why INDY 10 is such a step forward? What do
fibers bring to the table in terms of performance by demonstrating with
hard, cold numbers? I think people (including myself) might actually be
interested in knowing the answers to these questions.

Have I answered yours?

Charles

"Hadi Hariri" <bounce_mail (AT) hadihariri (DOT) com> wrote

Don · Guest

Charles Stack wrote:

Don · Guest

Charles Stack wrote:

Bruce McGee · Guest

Chad,

Thanks for sharing this. I've always assumed (hoped) that Indy 10 would
have better performance relative to Indy 9, and it's good to see some
numbers to back this up.

Please let us know how it looks after some optimization.

Regards,
Bruce McGee
Glooscap Software

Charles Stack · Guest

"Don" <ozdelphi (AT) yahoo (DOT) com> wrote

Chad Z. Hower aka Kudzu · Guest

Bruce McGee <bmcgee (AT) ionline (DOT) net> wrote in news:3f8fcaa0$1
@newsgroups.borland.com: