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

From: Date: Wed, 28 Jun 2000 06:28:47 +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-3604@lists.php.net to get a copy of this message
far out idea, but i recall MySQL being able to create in-memory tables. how its backed in terms of physical RAM or swapspace, i dont know. ""Priebe, Jason"" <priebe@wral-tv.com> wrote in message news:66FB2B6D1454D21196710008C728495002FE024C@cbc7-240.wral-tv.com... > 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 > > > > -- > 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 >

« previous php.general (#3604) next »