Re: PHP 5 and Shared objects
| From: | Greg Beaver | Date: | Tue, 22 Apr 2003 07:24:08 +0000 |
| Subject: | Re: PHP 5 and Shared objects | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-144776@lists.php.net to get a copy of this message | ||
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 objectsassociated-variablesHi 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() http://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:willEventhough after php 5? I thought may be PHP 5 and the new object modelbestop the need-to-serialize imagine my object class has a destructur function.. that means it's gonnacalled 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 objectsThe 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
somesowe don't have to serialize them, do we? so when I share an object over
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
isregisteredobject is not being recreated while keeping its resource-id in asession variable, or I'm wrong? About the global object, it could be a security risk if the programmer
wouldgonna 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 objectsThis 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
andbe 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,
allsharedretrieve 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-levelobjects 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
sessions (immortal object)? can this be a good feature to request?