HTTP Anti-Virus Proxy

Is the performance difference between using a loopback file and using a dedicated ext3 partition to store the temp files, significant?

Os

I don't think so. If you have enough memory, everything is cached by the OS anyway. Measure and tell us.

OK, I have not been able to detect any real world difference so far, but maybe I'm just not able to generate enough requests.

Any ideas as to how I can generate a lot of requets from a single client?
Any suggestions for a suitable benchmarking/measurement tool?

Os

http://www.acme.com/software/http_load/
http://httpd.apache.org/docs/2.2/programs/ab.html

etc..

I've had great results w/the following fstab:



Squid and ClamAV both use tmpfs. HAVP uses ext3 on the root part. with writeback enabled.

DrKewp,

How big are your tmpfs storage areas for Squid and Clamav?

Regards

Os

The box has 8 gigs RAM, no swap.

All tmpfs partitions are the default, which is one-half RAM. So 4 gigs each. The only one that will ever fill up (I hope!) is the squid cache.

Squid is configured to use 2 gigs ram and 4 gigs 'disk' (tmpfs) cache.

Wouldn't your squid cache benefit from being persistent over reboots? I'm guessing that after a reboot, using tmpfs would mean that it takes a significant amount of time to re-populate and optimise.

Would I be correct in assuming that the reason you are not using tmpfs for the havp temp directory is because it doesn't support mandatory locking?

I wonder what other directories would benefit from using tmpfs?
GNOME, Clamav & MySQL use /tmp by default.
I will certainly try using tmpfs for P3Scan temp dirs /var/spool/p3scan/children & /var/spool/p3scan/notify.
Any other ideas for temp dirs to try tmpfs with? Apache2?, lighttpd?, dhcp?, bind?, samba? ......

Regards

Os

Not really.

It pains me to say this as someone whom used to do web caching as a full-time job, but in the web 2.0 world caches are almost useless. We see less than a 10% bandwidth saving from our current implementation. Too much streaming and dynamic content these days.

Caches still help for a myriad of reasons, but its usually during the flash crowd kind of scenarios. So having a persistent storage doesn't buy you much. Plus I don't plan on bouncing the box more than once a week, tops.

Tmpfs + mandatory locking is technically supported, it just doesn't work consistently with havp for some reason. I looked into it and its some sort of exotic race condition I really don't feel like debugging. A ramdisk works fine if you want that, but it has to be statically sized at boot. You can also use a loopback file and keep it in tmpfs, which works as well. But I worry about the overhead.

I have squid configured to whitelist all the heavy the content, so only a small % is getting scanned. Given the aggressive buffering the linux kernel does plus my filesystem tweaks I don't expect the disk is being touched much, if at all. So far the disk seems mostly idle with my current configuration, so I'm happy.

I build all my boxes the same way, tons of ram, no swap and tmpfs for /tmp and /var/tmp (+/var/spool/squid on the web caches). I have scheduled reboots to keep 'em clean, amongst other things.

Any scratch work is much faster via tmpfs, if you have the free memory to pull it off. Portage builds are much faster, for example.

Linux that is. On Solaris tmpfs works flawlessly.

If you have info, then please share it.

Based on my testing, attempting to lock a file on a tmpfs partion on linux will sometimes return a 'Resource not available' error. It's not consistent and seems to happen randomly, regardless of load. The files will ultimately be created, but the havp log file fills up with errors in the process. I was going to experiment with putting in a delay during the file creation, but since that negates the performance benefit of tmpfs, I decided to just punt it.

My research indicated the problem may actually be with the locking process itself, see:
http://www.mjmwired.net/kernel/Document ... ocking.txt

The documentation indicates that the Linux implementation of mandatory locking leaves much to be desired...

Yeah I guess I will just update documentation to clearly state that Linux+tmpfs is broken. Hopefully someone has time or motivation to debug it someday.

I wouldn't say Linux+tmpfs is broken. It's really the linux implementation of mandatory locks is broken, which manifests itself overtly when used on a tmpfs partition.

I use tmpfs for everything on linux and have had no other problems with it. Works like a charm.

Ok sorry for not being clear. Linux+tmpfs+HAVP.

After some research I've decided that tmpfs for the squid store wasn't necessary for my needs. I've settled instead on the following memory usage configuration:

# Memory usage values
cache_mem 4096 MB
maximum_object_size 128 KB
memory_pools on
memory_replacement_policy heap GDSF

# no disk store
cache_dir null /null

I only cache small objects to memory and disable the disk store entirely. So far this has been working well.