Re: Shared memory - to use or not to use?
| From: | clayton collie | 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
>