Re: Server-Wide Persistent objects in PHP?
| From: | Yermo M. Lamers | Date: | Mon, 26 Nov 2001 17:18:23 +0000 |
| Subject: | Re: Server-Wide Persistent objects in PHP? | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-71677@lists.php.net to get a copy of this message | ||
Question for you, when you serialize to a file do the class definitions
get serialized along with it or do you have to pre-load your classes
before you can unserialize? (that seems to be the way it works but I may
be mistaken).
-- Yermo
On Mon, 26 Nov 2001, Andrey Hristov wrote:
> AFAIK PHP4 is better than PHP3 in that it makes some level of compilation.
> You may be serialize - de~ in files. If you use *nix you can choose to work with
> SysV semaphores and SysVShm (shared memory). Everything is in memory from one to another script
> invocation.
> So far I've seen only one script(system) which uses this capabilities of PHP. It's
> name is Oasis (oasis.sourceforge.net).
> In my tests its 3x-4x faster than analogous systems.
> For session data configure in your php.ini to use 'mm' instead of file for data
> storage.
>
> Best regards,
> Andrey Hristov
> IcyGEN Corporation
> http://www.icygen.com
> BALANCED SOLUTIONS
>
>
> ----- Original Message -----
> From: "Yermo M. Lamers" <yml@yml.com>
> To: "Benjamin Barringer" <bbarringer@infistar.com>
> Cc: <php-dev@lists.php.net>
> Sent: Monday, November 26, 2001 7:03 PM
> Subject: Re: [PHP-DEV] Server-Wide Persistent objects in PHP?
>
>
> >
> > Serializing to a file for a large number of objects isn't the correct
> > solution. For smaller projects it might be.
> >
> > The ideal (e.g. correct) solution is to have a server global scope which
> > never disappears. Something like a $SERVER_GLOBALS[] array or some such.
> >
> > For instance, it would be extremely cool to pre-load class files when the
> > server loads so you don't have to incur that overhead. It would be
> > extremely cool to instantiate objects at server start time and just have
> > them available ... basically making PHP have some mod_perl's capabilities.
> >
> > I had looked at serializing, but if I understand correctly before you can
> > unserialize them back you have to load all the class files again ... which
> > in my case means 1000's of lines of code each time ...
> >
> > in my situation I'm running a system that has to load, compile and run
> > 4-5 thousand lines of code .... and that's just to /construct/ the
> > objects. I'd like to do that once at server load time and then not again.
> >
> > -- Yermo
> >
> >
> > On Mon, 26 Nov 2001, Benjamin Barringer wrote:
> >
> > > Why don't you use serialize and unserialize and write the objects to a file.
> > > Makes a tremendous performance improvement (for my particular code base). I
> > > realize this isn't exactly what you need but; it may be a suitable
> > > alternative? You should also try out the Zend Cache. For a lot of my
> > > projects the cache is to $$$.
> > >
> > > Thanks
> > > Ben
> > >
> > >
> > > ----- Original Message -----
> > > From: "Yermo M. Lamers" <yml@yml.com>
> > > To: <php-dev@lists.php.net>
> > > Sent: Sunday, November 25, 2001 7:50 PM
> > > Subject: [PHP-DEV] Server-Wide Persistent objects in PHP?
> > >
> > >
> > > >
> > > > I'm building a reusable component object system in PHP where construction
> > > > of object trees, which needs to occur on every page, is very expensive.
> > > >
> > > > Running the subsequently built objects is very inexpensive.
> > > >
> > > > To make this system viable to use on high volume websites, I want to get
> > > > rid of the "construction of objects on every page" part which means I
> > > > want the ability to make object instances long lived. (i.e. build the
> > > > object once and have it live for as long as the server lives similar to
> > > > the way you can make objects server-wide global in mod_perl).
> > > >
> > > > Based on feedback I've gotten from the php-general list it looks like
> > > > this kind of thing hasn't been implemented yet for PHP. Correct?
> > > >
> > > > If not, could anyone provide pointers where I could start taking a look at
> > > > PHP internals to develop such a beast?
> > > >
> > > > Where I can find out:
> > > >
> > > > how are classes represented internally?
> > > > how are objects represented?
> > > >
> > > > how can I establish classes/functions/variables/objects that have
> > > > a server-wide global scope? What infrastructure needs to be kept
> > > > around in order to keep these objects valid?
> > > >
> > > > can one have php interpreter instances share data? (i.e. might
> > > > the best solution be to build "another" php interpreter instance
> > > > that persists and have an interface to pass references in and
> > > > out of it?)
> > > >
> > > > Any other suggestions would be greatly appreciated. From what I've been
> > > > able to gather having a long-lived object cache in the serverr would
> > > > make PHP much more viable for high load situations.
> > > >
> > > > On a related question, is there a way to pre-load class definitions when
> > > > the server starts so that class definition files don't have to be
> > > > re-parsed on a page by page basis?
> > > >
> > > > thanks,
> > > >
> > > > -- Yermo
> > > >
> > > > ---------------------------------------------------------------------
> > > > DTLink Software info@dtlink.com
> > > > Software Development and Consulting
> > > > http://services.dtlink.com
> > > > ---------------------------------------------------------------------
> > > >
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List
> > > > <http://www.php.net/>
> > > > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net
> > > > For additional commands, e-mail: php-dev-help@lists.php.net
> > > > To contact the list administrators, e-mail: php-list-admin@lists.php.net
> > >
> >
> > ---------------------------------------------------------------------
> > DTLink Software info@dtlink.com
> > Software Development and Consulting
> > ---------------------------------------------------------------------
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net
> > For additional commands, e-mail: php-dev-help@lists.php.net
> > To contact the list administrators, e-mail: php-list-admin@lists.php.net
> >
> >
>
---------------------------------------------------------------------
DTLink Software info@dtlink.com
Software Development and Consulting
---------------------------------------------------------------------