Thanks Alastair - an excellent thread with great suggestions. We ALL seem to face this one sooner or later!
David David Blocker [EMAIL PROTECTED] 781-784-1919 Fax: 781-784-1860 Cell: 339-206-0261 ----- Original Message ----- From: "Alastair Burr" <[EMAIL PROTECTED]> To: "RBG7-L Mailing List" <[email protected]> Sent: Sunday, April 17, 2005 3:24 AM Subject: [RBG7-L] - Re: Small Network > 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 > > > > --- RBG7-L > ================================================ > TO POST A MESSAGE TO ALL MEMBERS: > Send a plain text email to [email protected] > > (Don't use any of these words as your Subject: > INTRO, SUBSCRIBE, UNSUBSCRIBE, SEARCH, > REMOVE, SUSPEND, RESUME, DIGEST, RESEND, HELP) > ================================================ > TO SEE MESSAGE POSTING GUIDELINES: > Send a plain text email to [email protected] > In the message SUBJECT, put just one word: INTRO > ================================================ > TO UNSUBSCRIBE: > Send a plain text email to [email protected] > In the message SUBJECT, put just one word: UNSUBSCRIBE > ================================================ > TO SEARCH ARCHIVES: > Send a plain text email to [email protected] > In the message SUBJECT, put just one word: SEARCH-n > (where n is the number of days). In the message body, > place any > text to search for. > ================================================ > >
