Brian, come talk to me...
www-personal.umich.edu does somewhere around 700-800K requests per day
these days (current bottleneck is the ethernet), is running Solaris 2.5.1,
and NCSA's httpd, and all of its data is served out of AFS. It is a Sparc
Ultra 1/140. The biggest non-network problem I have right now is with the
AFS cache disk, which is 20-50% busy during peak loads.
But, since August, I haven't heard anyone complain that it was slow.
(It's on a much cleaner network now, which relieved a lot of the problem,
and it's no longer using nscd to cache DNS, which was another big
improvement.)
On Tue, 17 Sep 1996, Brian W. Spolarich wrote:
>
> I'm attaching a writeup of some tests I did a few months ago using AFS
> to serve data to heavily-loaded HTTP server. At that time I did not have
> an opportunity to follow up very much on some of the unanswered questions,
> and didn't feel like I had characterized the situation clearly enough.
>
> The problems that we saw happened when we started the test scenario
> against a "cold" cache with a moderate (60Mb) amount of data to retrieve.
> In this scenario, the tests would proceed for a few minutes, and then the
> AFS client/HTTP server would lose contact with the AFS server. The
> addition of an additional database server did not solve the problem.
>
> If anyone has any thoughts on this, I'd appreciate hearing them. Some
> differences between these somewhat informal tests that I ran back in May
> and what we're going to do now include a change in operating system
> (Solaris 2.5.1 instead of 2.4), and Ultras (on 10Mb/sec ethernet) instead
> of Sparc 20s. If we can get it, we'll try and run the enhanced release of
> 2.5.1 (for Web servers) and see what happens.
>
> I believe tcp_max_conn_req was set to 128 during this test, but as I
> said, I did this somewhat informally and didn't collect all of the data
> that I should have. :-]
>
> What I'm looking for is responses like "Yeah, we saw similar behaviour
> when we did something like this and fixed it by <blah>", or "You might try
> bumping up <bleh>".
>
> Transarc didn't really provide much help (although they tried to be
> helpful) as the support guy didn't feel like he had enough info to really
> understand the problem.
~~~~
[EMAIL PROTECTED] f u cn rd ths, u cn gt
UofM/ITD Expert Consultant/Web Admin Team a gd jb n cmptr prgmmng
535 W. William, Ann Arbor, MI 48103
