Re: doubt about 99% of the cases if the first byte of the file is cached.

I totally agree. I've been having problems related to the same issue: 
Downloading non-cached files.

If I try to start >50 downloads, only 50 will be served concurrently. The 
rest will block until there's a free 'slot'. And - yes - I've set 
max_connect to a far larger number than 50.

Ingo: Any ideas?

On Tue, 23 Apr 2002, Joe Cooper wrote:

> Unless there is a tux-devel list, I'd say it belongs here.  If there is 
> a tux-devel list, I'd say it belongs on it.
> 
> Alex Kramarov wrote:
> > I have been following this conversation for a long, long time, and though
> > this is tux related, it doesn't seem that it belongs in this list. does
> > anybody else feel the same ? maybe this should be private between the core
> > tux developers and Liang ?
> > 
> > -------Original Message-------
> > 
> > From: [email protected]
> > Date: Tuesday, April 23, 2002 19:04:20
> > To: [email protected]
> > Cc: [email protected]
> > Subject: RE: doubt about 99% of the cases if the first byte of the file is
> > cached.
> > 
> > Hi, Ingo
> > 
> > In our test case, we just build 10 files and each file is 5MB,10 files and
> > each file is 10MB, 10 files and each file is 50MB. The main memory of
> > TUX server is 256MB.
> > 
> > Why we build such big files for testing, the reason is we want linux to
> > flush out those files when the cache limit is reached. So we can update
> > caching status table in proxy.
> > 
> > We already test the feasibility of our project when we will use
> > flush_inode_pages()
> > in our program to flush a speicifc file. But now we want to get a real
> > flush
> > by Linux itself.
> > 
> > Now the question is can we know the maximum cache size of a backend
> > server running Linux 2.4.18 if the main memory is 256MB?
> > 
> > BTW, we record the time for the request of a speicifc file in our test case.
> > We found if the total size of all those http request files is bigger than
> > 100MB, then the
> > request time for a file again and again will be increased instead of
> > decreased.
> > So the performance of TUX is not improved because Linux take much time to
> > swap between cache and disk.
> > 
> > But if the total size of all those http request files is less than 100MB,
> > then the
> > request time for a file again and again will be decreased. So the
> > performance
> > of TUX is improved because Linux already cached all these files in cache.
> > 
> > Is this result reasonable?
> > 
> > Liang
> > 
> > 
> > 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On Behalf Of Ingo Molnar
> > Sent: Tuesday, April 23, 2002 7:43 AM
> > To: Liang Yang
> > Cc: [email protected]
> > Subject: RE: doubt about 99% of the cases if the first byte of the file is
> > cached.
> > 
> > 
> > 
> > On Tue, 23 Apr 2002, Liang Yang wrote:
> > 
> > 
> >>But even we didn't enable noatime, LED should flash only for 1/10 second
> >>or shorter time since Linux just need to update the access time flag of
> >>this file. it is not a big job and it shouldn't take Linux a long time
> >>to update this filed. But we noticed the Hard Disk LED flash for almost
> >>2 seconds each time. So maybe Linux is doing some large amount hard disk
> >>read/write operation instead of just updating file access time flag.
> > 
> > 
> > well, is RAM large enough for all files accessed to be cached in RAM?
> > 
> > 
> >>I guess for all the sizes of files, the access time flag should be the
> >>same. Is that correct?
> > 
> > 
> > yes, but each file has a different access flag, in different on-disk
> > positions. So if you are accessing 100 files, the atime update sequence
> > might create a longer LED flashing.
> > 
> > Ingo
> 
> 

-- 
Roy Sigurd Karlsbakk, Datavaktmester

Computers are like air conditioners.
They stop working when you open Windows.