This week, we:

• got 15,790 messages from 280 different IP addresses.
• handled 23,657 sessions from 1,340 different IP addresses.
• received 248,408 connections from at least 73,118 different IPaddresses.
• hit a highwater of 17 connections being checked at once.

Volume is up again from last week ,although the number of different IPs is down slightly.

I have an embarrassing confession: my home Internet connection is stilla dialup 28.8Kbps PPP link. (Back when I first set it up, this was onlyslightly behind the times, as 33.3Kbps modems had just come out.)

For a long time this was fine, because all I really did with it wastext-based stuff, mostly sshing to my machines at the university; whileI did do some web surfing, pretty much all of the sites I visitedregularly were

Recently, nothings askedan interesting question in a comment here :

[...] why, under the hood, deep down, is something like memcachednecessary? Why isn't the SQL server's cache as effective?

I think that one of the reasons for this is that highly aggressivecaching in an SQL server is much harder than it looks.

In database servers, caches have to be transparent ;non-transparent caches would implicitly break ACID guarantees. Now contemplate theproblem of completely correct cache invalidation that

One of the divisions in caching is between what I will call transparentand non-transparent caches. Transparent caches are ones where the onlything you are supposed to notice is faster speed; non-transparent cachesrequire you to manage them explicitly, especially cache invalidation.Operating system disk caches are an example of transparent caches, atleast in theory.

(At some level every cache is non-transparent, because it has to bemanaged by someone's code. So this is just a question of how a cache