I've tried a number of different ways to store the delivery table: shared memory, a dbm file on a ramdisk, and a MySQL heap table. The shared memory did not work, because PHP's shared memory manager is a bit too simplistic. It uses a flat linked list to manage the variables you've put into shared memory. Once you get over a couple thousand variables, it grinds to a halt. In addition, when you store a variable at a key that is already in use, the shared memory manager relocates everything that is stored after that key to make room for your new variable. Imagine if you've got 20 MB of data in shared memory, and you want to change the variable located at key #1!
The dbm file idea didn't get very far. It was too slow, and I didn't want to waste any more time trying to figure out why.
The heap table in MySQL rocks! I was able to insert 200,000 records into it (that roughly represents 100,000 unique visitors) in 81 seconds (0.0008 seconds per insertion, which in my mind is fantastic). The resulting table occupied 10.3 MB (that's the 1024**2 kind of MB, not 1000**2). This suggests that if you want to use no more than 32 MB for your delivery table, you could support approximately 300,000 unique visitors. If you clean out the delivery table every 15 minutes, you could conceivably handle 1.2 million unique visitors per hour.
Of course, as the number of sections that each visitor views grows, the number of unique visitors you can handle goes down. If each visitor sees on average 3 different sections, you'll only be able to handle 100,000 in 15 minutes.
To complicate matters further, users behind proxy servers will require roughly half the storage, because they share IP addresses. Users not accepting cookies will require more storage, because each time they view a page, we'll record a new ID.