Re: Shared memory - to use or not to use?

From: Date: Wed, 28 Jun 2000 13:19:15 +0000
Subject: Re: Shared memory - to use or not to use?
References: 1  Groups: php.general 
Request: Send a blank email to php-general+get-3548@lists.php.net to get a copy of this message
Just a sanity check on this...are you serving out the actual images from this Linux box? Or just an ID to give back to the client making the ad request? I ask, because you find there are bandwidth issues here. Assuming you need 1,000,000 ads delivered per hour, if you were to do this with serving out on average 5K ad sizes, you would be consuing approximately 13Mbit of bandwidth on a sustained basis from the maching acting as the ad server. So, make sure that your bottleneck doesn't end up being the network architecture you are using... Cheers, Thomas "Priebe, Jason" wrote: > > 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/ > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net > For additional commands, e-mail: php-general-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net -- ------------------------------------------------------------ Thomas Reinke Tel: (905) 331-2260 Director of Technology Fax: (905) 331-2504 E-Soft Inc. http://www.e-softinc.com Publishers of SecuritySpace http://www.securityspace.com

« previous php.general (#3548) next »