C#/Java Souce Code For ASP.NET Bandwidth/Speed Test Page Needed

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

You've all seen them. Hoards of sites (predominantly ISP's) offering to test
your bandwidth to the four corners of the globe, all trying to show that they
are faster and you should switch to using them.

Well, I now have a need to implement something similiar within my ASP.NET
applications so that I can troubleshoot slow performance problems between our
clients and our servers. An ActiveX control or Java Applet that the client
can download to their browser and that communicates with the server-side code
to test throughput between their desktop and our data center.

I've found PHP code, Linux-based tools, commercial product suites, but no
source code for C#.NET.

Can anyone point me in the right direction? TIA.
 
Are you finding it difficult to convert PHP to C#, Linux to Windows?
btw, which products have you evaluated?
Click to expand...

No. I'm not finding it difficult to convert PHP to C#, because I'm not doing
it. And I have no experience with Linux so I'm not going there either.

And I can't believe that measuring a clients throughput to your web server,
something that is common across the web, is so difficult that I have to pay
for somebody elses product.

I am surprised at the lack of MS support for such a thing. I would think
with the proliferation of ASP.NET web applications, that questions concerning
the performance of a particular app would arise more often.

It doesn't matter that your web-farm is under-utilised, that you're using
20% of a 10Mb dedicated line, that your SQL Server 2005 backend cluster sits
idle most of the time. If the customer calls you and says that your
application is slow, you have to do something about it.

Hence the need for a speedtest page within the app.
 
....
It doesn't matter that your web-farm is under-utilised, that you're using
20% of a 10Mb dedicated line, that your SQL Server 2005 backend cluster
sits
idle most of the time. If the customer calls you and says that your
application is slow, you have to do something about it.

Hence the need for a speedtest page within the app.
Click to expand...

Generally, a speedtest page wouldn't show whether or not your application is
slow. At most, it would show maximum available bandwidth at the moment the
test is run.

If bandwidth is your most important performance issue, then you're in great
shape! Most of us have more problems with slow code or slow database access,
or something like that.

John
 
Slow code and slow DB access are not issues since we knew we could have
5,000+ users accessing the system simultaneously, hence the dedicated line
but still we have a couple of customers who call us and complain that when
they are using the system the response times are slow (this is, clicking on a
button that performs a function is taking 10-30 seconds instead of the normal
1-3).

I'm pretty sure, after stress testing the system with WAS and ACT, running
relevant perfmon counters for a month, and logs from our data center that
show we're only using about 20% of the link on average (peaking to 70% at
month start/end), that the slowdown isn't at our end, but there's just no
pleasing some people. It's like we're guilty until proven innocent.

Now, it could be that our ISP is the bottleneck, and I would like to know
that so we can change if need be. Or it could be that the customers network
is lagging. Or the users PC is busy doing something and IE is not getting the
processor time it needs.

Unfortunately, accurately measuring TTFB and TTLB can only be done from the
client, hence the reason I want a page within the app that the user can go to
when they are experiencing some form of "slowdown", that will test bandwidth,
throughput, response times, etc. and send the report to us and the user.
 
As an example, where can I find the source code for a page like this?

http://tech.msn.com/speedtest.aspx

Obviously I don't care for the area code portion since our servers are
outside the US, and I don't think I can include the connection type since
most users wouldn't know what their company Internet connection really was.

If push comes to shove I'll just write my own from scratch, but try not to
make the usual mistakes such as overlooking TCP/IP packet control, timer
accuracy and precision of results.
 
Back
Top