Path: utzoo!utstat!news-server.csri.toronto.edu!math.lsa.umich.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!samsung!umich!sharkey!msuinfo!convex.cl.msu.edu!crs From: crs@convex.cl.msu.edu (Charles Severance (System Manager)) Newsgroups: news.software.nntp Subject: Re: How much of a load is nntp? Message-ID: <1990Nov21.202900.19293@msuinfo.cl.msu.edu> Date: 21 Nov 90 20:29:00 GMT References: <1990Nov15.155532.3384@ssd.kodak.com> <1990Nov16.220048.22474@engin.umich.edu> <1990Nov17.054512.13632@maverick.ksu.ksu.edu> <1990Nov21.180218.2129@engin.umich.edu> Sender: news@msuinfo.cl.msu.edu Distribution: na Organization: Michigan State University Lines: 96 This is indeed a tough question. I keep waiting for the answer to come out from someone who really knows based on some real testing. We use a SPARC/1 to serve 600-800 remote news readers per day. This machine is dedicated to news and no-one reads news on this machine at all. My first thought was that NFS was the way to go to because NFS is better at transferring large amounts of data and it would save memory on my machine. About 6 months later we had a major news reading crisis due to NFS. These are the dangers which we ran into which caused our problem: - With NFS you are at the mercy of the system administrator on the remote end as to the timeouts, etc. - While NFS is efficient at transferring large amounts of data, the act of searching directories and opening files has some overhead. News reading does a lot of opens and directory searches. - When NFS begins losing packets, it does not gracefully back off and assume that beating on a poor network does not improve its ability to respond quickly. - When NFS fails to deliver a packet after some number of furious retries the message that the user sees from the news reader is often very cryptic. Programmers doing reads and writes may or may not check every error code. Often the user sees a message like "SERVER Timeout: bad lstat" as their reader crashes. This points the blame to the server rather than a poor network or ill-configured local machine. As a contrast, NNTP uses TCP. - Most TCP implementations have an excellent backoff when network congestion rears its ugly head. TCP was designed to work across 9.6 lines taking 10 hops to get across the country. - The overhead of file opens and directory searches under NNTP is only in the host and with caching may not require a disk hit at all. - When news readers are developed which use NNTP, the programers generally include adequate error checking and user friendly messsages when networks fail. Using NFS, we had a major crisis using NFS as our primary mechanism for news access across a long campus backbone. Here is the story. There was a network problem which lost packts once in a while. The remote system administrators had the NFS timeout way too low and the remote servers didn't wait long enough before re-trying. This caused things to get much worse because most of the requests were actually getting to the server but the responses were getting lost. This made the server very busy accomplishing nothing. Eventually we fixed the problem by solving all of the problems: 1) bad NFS timeouts, 2) network problems, and 3) added memory to the server to eliminate paging completely. We did these things all at about the smae time so I can't assign a percentage of blame to each cause but I do know that all of the problems had some part in the situation. I also know that NNTP would have handled the network problem MUCH more gracefully. (Becaause no-one ever complained about a sluggish telnet during the crisis period). Now when people ask me whether to use NFS or not, I have to hem and haw. Perhaps if pushed, I might make the folowing recommendations: - Certainly use NFS if the systems are on one very reliable network which is never congested. I truly think that more simultaneous users can be supported by NFS than NNTP. Keep the retry timeouts very generous (5 sec or so) to give some backoff if network congestion occurs and packets start getting dropped. This also prevents retry requests and the response from the previous request from crossing on the network. - I would not use NFS if there is an IP router between the server and the remote news reading machine. The answer might also be a hybrid. Use NNTP to span "long" multi-hop distances and NFS for short distances. I still do not know how many simultaneous NNTP sessions are practical even with -n on the load command. I still want to hear some other experiences from the rest of the folks out there. Charles Severance Michigan State University 301 Computer Center East Lansing, MI 48824 internet: crs@convex.cl.msu.edu phone: (517) 353-2984 fax: (517) 353-9847 -- Charles Severance internet: crs@convex.cl.msu.edu Michigan State University phone: (517) 353-2984 301 Computer Center fax: (517) 353-9847 East Lansing, MI 48824 bitnet: 20095CRS@MSU