Re: Something like "ping" for windows messages.

See below...
On 8 Dec 2006 13:01:39 -0800, "Peter Smithson" <Peter_Smithson@xxxxxxxxxxx> wrote:


Joseph M. Newcomer wrote:

So the responsiveness to any PARTICULAR message is
going to depend solely on what your app is doing, what its current priority is relative to
all other applications and all other kernel threads, what they are doing, and so on. So
in general measuring the responsiveness to any one message is problematic in predicting
responsiveness on the average; you'd have to run not a 10-second, 10-message test, but a
several-hour, tens-to-hundreds-of-messages-per-second test. Any data from a small sample
would not be representative of reality.

That's the joy of benchmarking! There will only be two processes on my
system (of any note). One will be the server, the other will be the
http client test - I suppose that could run on another PC.
****
Nobody cares how many "processes" exist, because processes have nothing to do with
scheduling. What matters is the number of *threads* that exist in your system.

Use something like sysinternal's Process Explorer (procexp.exe) or better still the new
replacement which is now a free download from Microsoft. My email machine is running 42
top-level windows. These represent 19 of the 46 processes running on my machine (the rest
are running under various system accounts). There are, according to procexp, 479 threads
running. And only the threads matter in terms of scheduling. And that doesn't even
count the number of threads in the kernel supporting things like device drivers, the file
system, and goodness-knows-what-else.

So don't even talk about "processes"; they are largely meaningless. Talk about the number
of threads. Note that you have virtually no control over the actual number of threads
that can be running. You don't even know where many of them (perhaps most of them) are!
****
The position of the GUI shouldn't come into it as there isn't really a
GUI. I know there's a lot to it but by keeping the circumstances the
same and only varying one part (the http server), I'll find out what
effect the http server is having on the responsiveness of the rest of
the server.
****
I saturated the network by running my test program (which generated lots of TCP/IP
packets) on six other machines. So the time spent processing a SendMessage call is not
indicative of performance; you may have hit other limitations, such as the number of
kernel network buffers available, or the amount of network bandwidth available.

It turns out that running four machines saturated the network; as I added more machines I
got no additional processing, even though I had massive excess capacity in my program. I
determined this by noting the amount of time it spent waiting for messages. (One of the
few occasions I've used PreTranslateMessage...I recorded the "start time" when I hit
OnIdle and the "end time" in PreTranslateMessage (providing I was blocked), and I had
excess capacity. I forget how much).

So when you talk about "benchmarking", always make sure that what you are apparently
measuring is giving you a meaningful result. Partly this is my background in physics;
measurement is a real art form. You always, when making a physical measurement, have to
make certain that your apparatus is designed to measure what you want to measure, has
measured what you intended to measure, and has done so in a statistically significant
fashion.

Example: The Michaelson-Morley experiment on the existence of the ether always gave a
small difference in the two readings, but too small to be considered significant. This
gave science fiction writers for decades an excuse to justify faster-than-light travel
because they would claim this discontinuity gave all the leverage they needed.

Someone replicated the experiment with their equipment and discovered they had created a
very sensitive thermometer. When rotated (he did the experiment in their lab) the
temperature differential caused the false reading. So they weren't measuring any
difference in the luminiferous ether; they were measuring the effects of temperature on
their apparatus!

I once was presented with information that proved our product was 30% faster than our
cojmpetitor's product. I didn't believe this number. It turns out the guy who did it ran
th experiment on a Vax/780 that was also the main network interface machine, without
unplugging the network cable, and used a (Unix) script with the 'ti' command. He
subtracted the start time from the end time and made this claim. He did it with one
experiment! The VP for marketing hated my guts after I proved beyond any shadow of a
doubt that we were no more than 10% faster than our competitor. He felt that I'd betrayed
the company. Unfortunately, as I pointed out to the president of the company, our
competitor could run the same experiment I did and demonstrate we were lying in our teeth
if we made the 30% claim. Facts are facts. He hadn't conducted a scienifically solid
experiment, and had exactly ONE data point.
****

What are you hoping to discover?

The server has to process messages in order to work. If the new http
component is coded such that it stops the message pump from working, I
want to know about it. I need a way to test the message pump. I think
this will give me a clue as to how responsive the sytem is going to be.
Note that I'm not that interested in how fast the http server is (at
this stage).
****
What you're saying is that you are doing substantial processing once a message is
received, and you need to know when you saturate your capability. This is a different
question than how fast the message pump is, or what a WM_TIMER message might do.

You don't want to test the message pump, you want to test the throughput of your HTTP
server. So measure that. But don't confuse it with how the message pump is working. That
won't really tell you anything about your app.

Use threads. Use a number of threads equal to the number of CPUs. This would be a good
start. If the threads can block use more threads. When you hit saturation, make sure
that the saturation is the saturation of your http server and not the saturation of your
network stack.
****

I know it's an approximation but if it's taking 10 seconds to respond
to a message then I know that's bad. I'm not looking for small
variations - though if I can get consistent results then that would be
nice.
***
That's really bad, but knowing how fast the message pump works isn't going to answer this
question.
****

Perhaps I need to post more messages to get more accuracy.

I've found out about WM_NULL message from
http://support.microsoft.com/kb/231844 and pinched some code from
http://www.codeproject.com/cpp/ModuleNameFromWindwHandle.asp so I'll
see how it goes.

Thanks for your replies. The lack of threading in 16 bit Windows
explains a lot about this app!

Peter.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Copy .xls betwen local disk and https:// location
    ... I don't think you can do a copy or filecopy to a http server. ... and a https:// network location that requires ID an password. ... Do Until .ReadyState = 4 ...
    (microsoft.public.excel.programming)
  • Re: iptables firewall/SNAT
    ... In message, Cronus wrote: ... I would also like to set up a http server and ... What is the best iptables firewall config. ... and so gain access to your network. ...
    (comp.os.linux.networking)
  • Re: HTTP POST
    ... This part is not explicit enough. ... the bytes on the network between your browser and the HTTP server? ... If it is the bytes on the network, ...
    (freebsd-questions)
  • Re: Borland is neglecting Delphi for Win32 badly
    ... > broadband network. ... Wouldn't that mean that you're CPU-limited on your P2 while your ISP ... Out HTTP server here, ...
    (borland.public.delphi.non-technical)
Loading