Re: PHP 5 and Shared objects

From: Date: Tue, 22 Apr 2003 07:28:33 +0000
Subject: Re: PHP 5 and Shared objects
References: 1 2 3 4 5 6 7 8  Groups: php.general 
Request: Send a blank email to php-general+get-144781@lists.php.net to get a copy of this message
Hi Greg again, I wasn't actually facing a problem but I was just thinking that might help in the future, and my worry is not needed. You're totally right about your advice. Thanks ----- Original Message ----- From: "Greg Beaver" <greg@chiaraquartet.net> To: "Salah Faya" <salah@e-touch.ws> Cc: <php-general@lists.php.net> Sent: Tuesday, April 22, 2003 10:24 AM Subject: [PHP] Re: PHP 5 and Shared objects > Hi Salah, > > I see your concern. You will benefit most from using persistent > database connections, such as using mysql_pconnect. If the content does > not change often, consider using a compiling template. There isn't > really much overhead from object creation/destruction unless we're > talking about hundreds of objects in the same file, and that code would > be slow even if it weren't objects. I know there are a number of > profilers out there that you can use to test your concerns, and pear > bundles both a profiler/debugger extension (apd) and a benchmark package > (see pear.php.net). I haven't tested either myself, but there is a > large userbase for apd. > > Note that the default object destructor simply frees the memory it used > to occupy. The only overhead is any code you put in __sleep(). php 5 > will have explicit destructors, and you can use this for slowing things > down further, if you'd like :). > > It should be noted that in the abstract, it is hard to quantify what you > need. You would benefit most from testing. Perhaps compare the > performance of rapid file requests with PHP, ASP, JSP, Cold Fusion, and > whatever else you want to attempt. This is a hard thing to measure, > however. The way that the language interfaces with the webserver is > often a major factor in speed, so your best bet is to choose a language > because you like it, and start writing code :). Worry about performance > problems in the design, and make sure you can scale/upgrade easily, and > you'll have fewer problems along the line. Don't know if this helps at > all :) > > Greg > -- > phpDocumentor > http://www.phpdoc.org > > Salah Faya wrote: > > >Hi Greg, > >Thanks for the clarification. > >My concern in my question is about the performance and the machine > >resources, I thought that keeping the object alive while session is on will > >use less memory and computer resources compared to what may happen when > >thousands of requests for the same application files which need the same > >object: > >1- currently, on every request the script is gonna create the object.. so > >1000 x Object creation + Object destruction (including making db > >connections, files and etc) > >2- in my opinion, on the first request the object is being created once, and > >in the other 999 request it's just the object is being used not recreated, > >and get destructed when the session/s is closed, logically the second way is > >gonna use less computer resources? > > > >----- Original Message ----- > >From: "Greg Beaver" <greg@chiaraquartet.net> > >To: "Salah Faya" <salah@e-touch.ws> > >Cc: <php-general@lists.php.net> > >Sent: Monday, April 21, 2003 11:51 PM > >Subject: [PHP] Re: PHP 5 and Shared objects > > > > > > > > > >>Hi Salah, > >> > >>Imagine this scenario: you create an object. PHP saves it somewhere so > >>that only a handle need be passed back. The session that the object > >>belongs to is stored. No one accesses the session for 2 days. Where > >>was the object during those 2 days? Taking up memory? This would be > >>very inefficient use of resources and lead to a MS Windows-esque > >>resource crash. Serialization is the only way to preserve an object > >>after program termination. PHP scripts do not sit in memory cycling the > >>way that GUI applications do. They work more like old DOS commands > >>(excepting php-gtk, which doesn't need serialization at all to keep > >>objects). Destructors should be called at the end of scripts. If an > >>object opens a database connection, the destructor that closes this > >>connection should be called when the script is concluded. If I > >>understand what you mean by auto-loading, auto-loading is simply an > >>automation of serialization. > >> > >>There is no detectable difference between a serialized object and the > >>original object, why would you need to keep it alive? If you're > >>concerned about what happens when an object serializes, you might > >>benefit from reading about magic methods__sleep() and __wakeup() > >> > >>4o©¬þ>4ÂW > >>˜ýZXOhttp://www.php.net/manual/en/language.oop.magic-functions.php > >> > >>The new object model removes the need to use the & operator like > >>$myobject = &$thatobject as objects will always be passed by handle > >>*when in memory*. This is still great news, as anyone who has tried to > >>do a linked list implementation or parent->child->parent linking in php > >>4 knows about. > >> > >>Regards. > >>Greg > >>-- > >>phpDocumentor > >>http://www.phpdoc.org > >> > >>Salah Faya wrote: > >> > >> > >> > >>>Eventhough after php 5? I thought may be PHP 5 and the new object model > >>> > >>> > >will > > > > > >>>stop the need-to-serialize > >>>imagine my object class has a destructur function.. that means it's gonna > >>> > >>> > >be > > > > > >>>called between files in same session! > >>>and what about the autoloading function and etc? > >>> > >>>----- Original Message ----- > >>>From: "Greg Beaver" <greg@chiaraquartet.net> > >>>To: <php-general@lists.php.net>; "Salah Faya" > >>><salah@e-touch.ws> > >>>Sent: Monday, April 21, 2003 11:29 PM > >>>Subject: [PHP] Re: PHP 5 and Shared objects > >>> > >>> > >>> > >>> > >>> > >>> > >>>>The object itself is being serialized and re-created. You can read > >>>>about how sessions affect objects at: > >>>> > > >>>>>>>>http://www.php.net/manual/en/language.oop.serialization.php > >>>> > >>>>PHP is still cool, don't be dismayed :) > >>>> > >>>>Regards, > >>>>Greg > >>>> > >>>>Salah Faya wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>What I meant is with PHP5 objects aren't treated as > >>>>> > >>>>> > >associated-variables > > > > > >>>>> > >>>>> > >>>so > >>> > >>> > >>> > >>> > >>>>>we don't have to serialize them, do we? so when I share an object over > >>>>> > >>>>> > >>>>> > >>>>> > >>>some > >>> > >>> > >>> > >>> > >>>>>session the object itself will actually stay alive and only the > >>>>> > >>>>> > >>>>> > >>>>> > >>>resource-id > >>> > >>> > >>> > >>> > >>>>>will be passed from file to file trhough same session, in other words > >>>>> > >>>>> > >the > > > > > >>>>>object is not being recreated while keeping its resource-id in a > >>>>> > >>>>> > >>>>> > >>>>> > >>>registered > >>> > >>> > >>> > >>> > >>>>>session variable, or I'm wrong? > >>>>> > >>>>>About the global object, it could be a security risk if the programmer > >>>>> > >>>>> > >is > > > > > >>>>>gonna use it badly (u r right) > >>>>> > >>>>>----- Original Message ----- > >>>>>From: "Greg Beaver" <greg@chiaraquartet.net> > >>>>>To: "Salah Faya" <salah@e-touch.ws> > >>>>>Cc: <php-general@lists.php.net> > >>>>>Sent: Monday, April 21, 2003 11:05 PM > >>>>>Subject: Re: PHP 5 and Shared objects > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>This is already possible in php 4. However, both file1.php and > >>>>>>file2.php must begin with a session_start() call. > >>>>>> > >>>>>>A global object (common to all sessions) is a big security risk, I > >>>>>> > >>>>>> > >would > > > > > >>>>>>be surprised if it is considered a feature by the php team. You can > >>>>>>simulate such a thing yourself, by using a database, or a file on the > >>>>>>server backend that contains the serialized contents of the object, > >>>>>> > >>>>>> > >and > > > > > >>>>>>retrieve them in the beginning of each file. > >>>>>> > >>>>>>Regards, > >>>>>>Greg > >>>>>>-- > >>>>>>phpDocumentor > >>>>>>http://www.phpdoc.org > >>>>>> > >>>>>>Salah Faya wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>As I've understood that PHP5 OOP will allow us to use a session-level > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>shared > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>>objects smoothly, as in example: > >>>>>>> > >>>>>>>- file1.php > >>>>>>>session_register('myObj'); > >>>>>>>$myObj = new myClass(2003); > >>>>>>>$x = $myObj->year; // returns 2003 > >>>>>>>header('location: file2.php?PHPSESID='.session_id()); > >>>>>>> > >>>>>>>- file2.php > >>>>>>>if (isset($_SESSION['myObj'])) { > >>>>>>> $myObj=$_SESSION['myObj']; > >>>>>>> echo $myObj->year; // should also return 2003 > >>>>>>>} > >>>>>>> > >>>>>>>am I right? please correct me > >>>>>>> > >>>>>>>And if that's correct, is there a way to make a global object > >>>>>>>over > >>>>>>> > >>>>>>> > >all > > > > > >>>>>>>sessions (immortal object)? can this be a good feature to request? > >>>>>>>

« previous php.general (#144781) next »