About 10 years ago, when a WAN was installed at the company that I used to work for, I used R:Base to prove that there was a problem on one leg by copying a large file between fileservers.
Simply by copying the file a number of times, backwards and forwards, between our office in London and the offices in Europe and putting the destination name along with the date and start and finish times into a table it was possible to build up evidence that one connection was slower. The command file run automatically for a couple of hours overnight - when there was no other traffic - for weeks until, eventually, it was discovered that the supplying company has set-up one of the routers incorrectly. After that, if ever there was a speed problem on the network, we ran the thing again to check it. Regards, Alastair. ----- Original Message ----- From: "Lawrence Lustig" <[EMAIL PROTECTED]> To: "RBG7-L Mailing List" <[email protected]> Sent: Saturday, April 16, 2005 4:34 PM Subject: [RBG7-L] - Re: Small Network > > If you correct the scratch file issue (I learned about the scratch file > > about 2 weeks ago here on the forum) and you still have issues, here a a > > few things I would try: > > You can also test the speed of your network by copying a large file from the > network to a local hard disk and then back to the network and timing it in each > direction. A reasonable network should be moving 3 to 8 megabytes of data per > second. > > At one client where they thought they were having database problems, I wrote a > little VB script to do this and stuck it on the network. Then, when someone > had an issue, they could run the VB script and get a message saying "Measured > throughput X on download and Y on upload. Should be at least 2.0 MB/s." I > found that values ranged from 8 MB/s to .01 MB/s (that is, about 10 kilobytes > per second). The fastest machine was 800 times faster than the slowest! Using > that, they were able to locate bad wiring and switches (but by that point it > was out of my hands). > > The point here is to make sure you have a reasonable network throughput without > involving the database at all. Once you have the network working properly, you > can deal with any additional issues at the database level. But without a > properly configured and funtioning network, you will never get good performance > from R:Base. Make sure there are no slow stations at all -- since one slow > station doing an UPDATE could lock a table for minutes, slowing everyone else > down. > -- > Larry >
