RE: [PHP] Shared memory - to use or not to use?

Some of the images will come from this Linux box, and some will be redirections to other organizations' ad servers. It's not inconceivable that we'd see 6 or 7 Mbps sustained. Our overall server farm has consumed as much as 31 Mbps, so we can handle it. This brings up another question -- when the ad delivery engine is delivering images itself, should it pull those images out of a MySQL table? Or should they come from files on the local disk? Or maybe even shared memory? So many decisions... Jason Priebe WRAL OnLine http://www.wral-tv.com/ > -----Original Message----- > From: Thomas Reinke [mailto:reinke@e-softinc.com] > Sent: Wednesday, June 28, 2000 9:19 a.m. > To: Priebe, Jason; php-general@lists.php.net > Subject: Re: [PHP] Shared memory - to use or not to use? > > > 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 >