Hi Maik, I also IM'ed you just a minute ago. Here at SFSU we are already using squid in front, but would like to hear from you (and others) about your experience with Varnish. According to some sites it seems that Varnish is being 10x-20x faster than Squid (at least that's the number they claim, see http://t-a-w.blogspot.com/2007/04/varnish-vs-squid-assembly-still-matters.html ), is this also your own experience as well? You mentioned that Squid can do a lot more useful things than Varnish, could you please elaborate a little bit more? Thanks!
Oops, our system administrator Mike reminded me that there is also another alternative other than Varnish and Squid. That is Perlbal (reverse proxy and http server):
http://en.wikipedia.org/wiki/Perlbal
http://www.danga.com/perlbal/
They are also the makers of http://www.danga.com/memcached/
Any one here had any experience with Perlbal? If so could you please share your experience with us? Thanks!
http://en.wikipedia.org/wiki/Perlbal
http://www.danga.com/perlbal/
They are also the makers of http://www.danga.com/memcached/
Any one here had any experience with Perlbal? If so could you please share your experience with us? Thanks!
I don't think that a "faster reverse proxy" would bring that much benefit, except for high load scenarios (where you will run squid on a seperate seperate server with I/O-Power to the max (e.g. RAID & XFS).
Speed heavily depends on what can be delivered NOT from cache. If the requested item is not in there, then you'll have to wait for the backend. Only these are the interesting requests.
And then we are talking about database tuning - lots of performance can be achieved by optimizing your database system. Then we talk about RAID10 and RAM, RAM, RAM, so that you can hold the whole database in RAM. The last thoughts (RAID10, XFS, RAM) are not mine, but from Kristian Koehntop - core developer MySQL.
He also says, that not the highest daterate of a HDD will perform (for database), but the shortest average seek time. The more heads the less seek time. Better a HDD-cake consisting of several small disks than one big one with only two heads.
PHP & Webserverload is ridiculous compared to database load (with moodle in my experience)
just my two cents...
Maik
Speed heavily depends on what can be delivered NOT from cache. If the requested item is not in there, then you'll have to wait for the backend. Only these are the interesting requests.
And then we are talking about database tuning - lots of performance can be achieved by optimizing your database system. Then we talk about RAID10 and RAM, RAM, RAM, so that you can hold the whole database in RAM. The last thoughts (RAID10, XFS, RAM) are not mine, but from Kristian Koehntop - core developer MySQL.
He also says, that not the highest daterate of a HDD will perform (for database), but the shortest average seek time. The more heads the less seek time. Better a HDD-cake consisting of several small disks than one big one with only two heads.
PHP & Webserverload is ridiculous compared to database load (with moodle in my experience)
just my two cents...
Maik