Test Network Speed to Backend?

[PK]

Does anyone have a solution that I could use to have my front end determine
the speed to access the backend? (MS Access 2003)

I have a front end client which uses a access backend on a network file
share. The application runs beutifully on the LAN. When users access it
remotely over the (slow) WAN, we run into problems.

I want to disable certain functions if the link is too slow.

Thanks for any help!

 

[Albert D. Kallal]

I talk about network speed here:

http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html


For the most part, a typical wan is about 100 times slower then a office
lan. So, that means a 3 second operation becomes 300 seconds (5 minutes).

I outline some possible solutions in the above article....

why not just ask your network people what the speed of the wan is compared
to the lan (as my above article points out, we don't want an answer in bits,
bytes or whatever mumbo jumbo...just a raw number like it is 10 times
slower.

If it is 100 times slower, then fixing your code for a 30% increase is a
ABSOLUTE waste of time when you talking about such orders of magnitude in
terms of performance...

 

[PK]

Albert,

Thanks for your reply - I actually had read your article this morning before
your post. I am aware of the all of those solutions.

I am looking for code to test the speed. I am fine with the users accessing
the database for many functions over the WAN, I just want to restrict certain
functions if they are Remoting in. My application has over 350 users, but
only a half dozen access the database at any given point. SQL is in the
future - just not short term.

sooooo.... still looking for a code based test of speed.

 

[dymondjack]

Here's an idea pulled out of thin air...

What if you knew somewhere around what the limit response time would be for
the features you would like to disable. Maybe, the first thing you could to
would be to perform some mundane operation on the server location (create an
empty temp file perhaps), and record the system time just before the command
runs, and again just after the command runs. Then compare the two times. If
the difference is greater than *whatever*, disable the features.

Just a thought...


--
Jack Leach
www.tristatemachine.com

- "A designer knows he has reached perfection not when there is nothing left
to add, but when there is nothing left to take away." - Antoine De Saint
Exupery

 

[Gina Whipp]

See if something here will help you
http://www.members.shaw.ca/AlbertKallal/Wan/Wans.html

--
Gina Whipp

"I feel I have been denied critical, need to know, information!" - Tremors
II

http://www.regina-whipp.com/index_files/TipList.htm

 

[David W. Fenton]

What if you knew somewhere around what the limit response time
would be for the features you would like to disable. Maybe, the
first thing you could to would be to perform some mundane
operation on the server location (create an empty temp file
perhaps), and record the system time just before the command runs,
and again just after the command runs. Then compare the two
times. If the difference is greater than *whatever*, disable the
features.

Or take a file of known size, and time uploading and downloading it.
This is how sites like DSLReports.com test the speed of your
broadband connection.

 

[PK]

Thank you all for your replies!

dymondjack & David W. Fenton - I liked your ideas best, and eventually went
this route.
One of the first things the client does is download some information from
the backend (client version required, some drop down list populations, etc).
I timestamped before and after that process, determined the seconds using
[DurationInSeconds] = ((DateDiff("s", [Start], [End])))
and then determined what a reasonable response rate would be. Works like a
charm!