Shared memory - to use or not to use?

I'm building a proof-of-concept ad serving engine using PHP with MySQL on a Linux platform. If I can obtain the performance levels I need (600,000 - 1,000,000 ad deliveries/hour), I'll move forward with the project, which I hope to make available under the GPL. (Yeah, just what the world needs, more ads on Web pages :-P) I need to manage a large table of users to record which ad was last seen by each user. I have three options for this: - MySQL - shared memory - dbm files on a ramdisk Which of these would be fastest? The shared memory option seems most logical to me, but then it seems that I'd have to take on a lot of responsibility for managing the locations of the values (some sort of hashing routines). _Unless_ I can just stick a big hash array into shared memory and access values in that hash array. My guess is that such a technique wouldn't work. I'm thinking that if I call shm_get_var() to retrieve a hashed array, it will actually copy all of the data in the array into the memory space of the process. This would be highly inefficient if you have 100,000 values in the hashed array. Is this correct? So if I can't do that, I'd have to create some sort of hash routine myself and then manage collisions as I insert into shared memory. Not pretty, but I have to do whatever it takes to squeeze out performance from the system. Am I right in thinking that there would be too much overhead to use MySQL for such rapid storage and retrieval? What about dbm on a ramdisk? Seems that the dbm libraries would handle all my hashing/collision issues for me (probably more efficiently than I could hope to do), but what kind of overhead is involved in letting the OS treat RAM like a filesystem? Seems that would cut into my performance... Any advice would be greatly appreciated. Jason Priebe WRAL OnLine http://www.wral-tv.com/