> > (a) the performance measurements/benchmarks used by the
article were
> > synthetic and don't reflect real database applications
>
> I think that a Slashdot-type web application would probably benefit
a
> lot.
Hows that? Slashdot serves (primarily) static pages which are
periodically generated. Anything that isn't static isn't hit very
often, or is dynamic enough that it doesn't matter (second or 3rd
comment deep in chat thread). It'll help generation of their front
page for those users logged in, but even then the content itself is
cached in memory on the webservers. Their second bottleneck is using
apache with modperl. They'd get alot faster results with a custom
written webserver which serves slashdot pages only -- even if it was
written as a daemon in perl.
Why have the network overhead to hit a cached resource when you can
have it right in the webserver itself?
Use a table with a single row which holds a timestamp to determine
when cache should be expired (triggers update the time on writes).
That query is done everytime. Thats it though, nothing else repeats
more than 5 times unless the data changes (5 as there are 5
webservers). But, speed up that query by 2x and we can serve 2x more
pages :)
create table cache_expire (lastwrite timestamp);
insert into cache_expire default values;
select lastwrite from cache_expire;
Think you can get a big boost to that?
Those phpBB's, etc would get a much biggest boost by using a 5MB
shared memory segment to store the articles, etc on the webserver
itself as it avoids network and connection conjestion of the database
entirely.
