Re: Some optimisations

On 16 Sep 2000, at 18:06, Henrik Nordstrom <hno@hem.passagen.se> wrote:

> Andres Kroonmaa wrote:
>
> > For each server socket squid mallocs 64KB buffer that consumes RAM,
>
> Actually it doesn't. It is to dumb to do this ;-)
>
> For all HTTP connections it uses a fixed buffer of 64 KB, and then
> copies the retreived data to the MemObject. The buffer size is actually
> free, at the cost of the data copy.

 ouch, my fault, didn't took enough time to read the code.
 Seems that it allocs ram to MemObject in blocks of SM_PAGE_SIZE based
 on actual amount read from server. Means that 64K would be used only
 for large reads, not persocket.

> > From these observations I decided to limit serverside buffer size to
> > 16KB, increase disk buffers from 8KB to 16KB, and also increase client
> > buffers from 4KB to 16KB and watch how it matters.
>
> That will increase the memory consumption quite a lot when I/O gets
> bound by the client speed. However for many requests I guess the I/O is
> actually server bound.. And it will give a better disk read pattern.

 yes, isn't very nice to reserve large buffers at clientside either.
 at the same time, server that has about 1000 concurrent clients would
 need 16MB of buffers instead of former 4MB. For a server of that load
 this doesn't seem too much.

> > Further strangeness in squid is that when it swapouts an object, it first
> > writes out metadata (storeentry+url) with whatever size is needed, and from
> > then on writes in diskblocks. This means that _all_ swapouts occur in badly
> > aligned manner:
>
> This is a unfortunate effect of the "new" cache file format where a
> header was added, However on most OS'es the penalty is mostly a added
> syscall, as the filesystem also buffers the write before paging it out
> to disk.

 Thats how it should be. But when I think of how OS should do it, I tend
 to assume that OS reserves limited buffering per FD, overrunning which
 would cause fault to handle it. Or is libc buffering that?
 Also, when serverside is relatively slow, dirty pages may get swaped
 out before filled completely. This means that appending would cause
 read+modify+write to the same disk block later.
 I wonder if we should make first write to client socket and disk
 sized to amount of free space in disk buffer. after that all traffic
 should be aligned well.

> If you want optimal paging behaviour then you should do block aligned
> writes using page aligned pages of memory. In that case some OS'es avoid
> data copying by duplicating the page in the disk cache and mark is as
> COW.

 isn't alignment to pages coming naturally from malloc lib? I thought
 malloc at least tries to return memory aligned to size of malloc.
 or perhaps we'd want to add xvalloc to util.c and use it for disk
 buffers? What about network buffers?

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Tue Sep 19 2000 - 02:08:28 MDT