Assessing Application Network Overhead

[mark]

Hi, I am in the process of developing a small application that sits in
the task bar and at a set interval polls an IIS web server for
information. The process involves the client sending anything between 3
and 30 characters of data and the server returning anything up to 50
characters of data.

I need to identify the overhead on the network so I can determine the
network utilisation of the application. The sort of questions I need to
be able to answer are:

1. Determine where bottlenecks exist (i.e - IIS processing versus
Network bandwidth)
2. The overall network overhead for a single client polling the server
once, including Ethernet overhead packets.
3. Determine the data payload of a single transaction
4. Determine the maximum number of synchronous transactions that the IIS
server can process before reaching breaking point

I would be grateful for any advice you can offer to help devise a
process for testing an applications network utilisation requirements
along with any network monitoring tool recommendations you may have.

Many thanks in advance,

Regards,
Mark.

 

[Peter Duniho]

[...]
I would be grateful for any advice you can offer to help devise a
process for testing an applications network utilisation requirements
along with any network monitoring tool recommendations you may have.

I'm not seeing anything in your question that is specific to C# or .NET.

You will probably get better information finding more appropriate forums
(something specific to TCP/IP or IIS, for example, as appropriate to the
specific parts of your question), as well as simply searching using
Google for data on the overhead of a UDP datagram (which is what I
presume you would use to poll IIS...using TCP will be significantly
higher, especially if you create a connection for each query).

That said, I don't have the numbers off the top of my head, but I seem
to recall the overhead for UDP is reasonably small (28 bytes sticks in
my mind for some reason ). As for application overhead, depending on
what processing needs to occur to respond to the datagram, I would be
most concerned simply that the regular polling would keep some
significant chunk of code resident in physical RAM when it otherwise
wouldn't need to be. Presumably the actual CPU and i/o overhead should
be small.

For anything more detailed, I'd suggest a more appropriate forum for the
question, as well as answering the more basic elements simply through
research (Google the external stuff like UDP overhead, and look more
closely yourself at the stuff related directly to your implementation).

Pete

 

[mark]

Thanks for the information Pete. I'll take a look at the tcpip forums too.

Mark.

[...]
I would be grateful for any advice you can offer to help devise a
process for testing an applications network utilisation requirements
along with any network monitoring tool recommendations you may have.

I'm not seeing anything in your question that is specific to C# or .NET.

You will probably get better information finding more appropriate forums
(something specific to TCP/IP or IIS, for example, as appropriate to the
specific parts of your question), as well as simply searching using
Google for data on the overhead of a UDP datagram (which is what I
presume you would use to poll IIS...using TCP will be significantly
higher, especially if you create a connection for each query).

That said, I don't have the numbers off the top of my head, but I seem
to recall the overhead for UDP is reasonably small (28 bytes sticks in
my mind for some reason ). As for application overhead, depending on
what processing needs to occur to respond to the datagram, I would be
most concerned simply that the regular polling would keep some
significant chunk of code resident in physical RAM when it otherwise
wouldn't need to be. Presumably the actual CPU and i/o overhead should
be small.

For anything more detailed, I'd suggest a more appropriate forum for the
question, as well as answering the more basic elements simply through
research (Google the external stuff like UDP overhead, and look more
closely yourself at the stuff related directly to your implementation).

Pete