Re: [PHP] A no brainer...
# [EMAIL PROTECTED] / 2006-10-16 16:40:34 -0700: On Oct 16, 2006, at 6:20 PM, Roman Neuhauser wrote: Modern filesystems cope well with large directories (plus it's quite trivial to derive a directory hierarchy from the filenames). Looking at the numbers produced by timing various operations in a directory with exactly 100,000 files on sw RAID 1 (2 SATA disks) in my desktop i'd say this concern is completely baseless. I knew that you could get PHP to use a directory structure for the session data files, but hearing that you can have 100k files in a single directory and not run into performance issues or problems is news to me. Which OS are you running? FreeBSD. What do your tests show, on what OS/version/FS? It still uses files, but hopefully you don't hit them very often, especially when you're dealing with the same table records. A RDBMS is basically required to hit the disk with the data on commit. One of the defining features of a RDBMS, Durability, says that once you commit, the data is there no matter what. The host OS may crash right after the commit has been acked, the data must stay. You can turn on query caching in MySQL, but this will give you *nothing* for purposes of session storage. Unless session storage is used to save time in retrieving data, right? I'm seeing your point on the writing, but what about reading? I think it would be kind of fun to run some actual tests. Check out the query cache in the MySQL 5.0 manual, it clearly says that any modification of a table (INSERT, UPDATE, ALTER TABLE...) will invalidate all cache entries that use that table. IOW, request from any visitor such that it starts or updates a session invalidates query cache entries for all sessions. Max cache hits for any single cache entry depend on the number of requests a visitor can produce in sequence without updating the session table, number of concurrent visitors, request frequency... You're likely to max cache hits for any entry at 1, and all but that one will be purged with 0 cache hits. Also, having raw data is always faster than having to process it before you can use it. I don't know what that means. Bytes in files on disk are as raw as it gets, you get one roundtrip process - kernel - process; compare the communication protocol MySQL (or just any other DB) uses where data is marshalled by the client, and unmarshalled by the server, overhead of the database process(es) taking part in the write... If you pull a record from the db, you can access the data. Or you can query the db, get the serialized data, de-serialize it, and now access the data. That's not really filesystem vs. database, that's to serialize or not to serialize. I tested this previously and found the database to be faster. The references I gave supported this and listed additional benefits. The article from Chris Shiflett contains zero quantifications of the purported performance benefits. Things change tho, especially with technology. It seems like we should be able to test this pretty easily. I actually think it would be fun to do as well. Do you have a box we can test this on? Meanwhile, I'll check one of my boxes to see if I can use it. If anything, it'll be interesting to see if two systems report the same. Yes I can provide a testbed, just post a testing methodology proposal. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
Hi Guys :) I'm off today, so I'll follow-up with you tomorrow. Meanwhile, have a great day :) -Ed On Oct 17, 2006, at 2:20 AM, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2006-10-16 16:40:34 -0700: On Oct 16, 2006, at 6:20 PM, Roman Neuhauser wrote: Modern filesystems cope well with large directories (plus it's quite trivial to derive a directory hierarchy from the filenames). Looking at the numbers produced by timing various operations in a directory with exactly 100,000 files on sw RAID 1 (2 SATA disks) in my desktop i'd say this concern is completely baseless. I knew that you could get PHP to use a directory structure for the session data files, but hearing that you can have 100k files in a single directory and not run into performance issues or problems is news to me. Which OS are you running? FreeBSD. What do your tests show, on what OS/version/FS? It still uses files, but hopefully you don't hit them very often, especially when you're dealing with the same table records. A RDBMS is basically required to hit the disk with the data on commit. One of the defining features of a RDBMS, Durability, says that once you commit, the data is there no matter what. The host OS may crash right after the commit has been acked, the data must stay. You can turn on query caching in MySQL, but this will give you *nothing* for purposes of session storage. Unless session storage is used to save time in retrieving data, right? I'm seeing your point on the writing, but what about reading? I think it would be kind of fun to run some actual tests. Check out the query cache in the MySQL 5.0 manual, it clearly says that any modification of a table (INSERT, UPDATE, ALTER TABLE...) will invalidate all cache entries that use that table. IOW, request from any visitor such that it starts or updates a session invalidates query cache entries for all sessions. Max cache hits for any single cache entry depend on the number of requests a visitor can produce in sequence without updating the session table, number of concurrent visitors, request frequency... You're likely to max cache hits for any entry at 1, and all but that one will be purged with 0 cache hits. Also, having raw data is always faster than having to process it before you can use it. I don't know what that means. Bytes in files on disk are as raw as it gets, you get one roundtrip process - kernel - process; compare the communication protocol MySQL (or just any other DB) uses where data is marshalled by the client, and unmarshalled by the server, overhead of the database process(es) taking part in the write... If you pull a record from the db, you can access the data. Or you can query the db, get the serialized data, de-serialize it, and now access the data. That's not really filesystem vs. database, that's to serialize or not to serialize. I tested this previously and found the database to be faster. The references I gave supported this and listed additional benefits. The article from Chris Shiflett contains zero quantifications of the purported performance benefits. Things change tho, especially with technology. It seems like we should be able to test this pretty easily. I actually think it would be fun to do as well. Do you have a box we can test this on? Meanwhile, I'll check one of my boxes to see if I can use it. If anything, it'll be interesting to see if two systems report the same. Yes I can provide a testbed, just post a testing methodology proposal. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
On Mon, October 16, 2006 8:20 pm, Roman Neuhauser wrote: So no, it makes no sense for a database to be faster than filesystem. The database may, or may not, have finely-tuned a lot of things to write their records more quickly/efficiently than the PHP approach of writing individual files for each session. E.g., if the DB has allocate a larger chunk of disk-space, and is micro-managing it, and doing fread/fwrite in an fopen(, 'r+') environment (or similar) it *MIGHT* be more efficient than PHP's method -- even *with* the DB overhead you point out. The *only* way to be certain of any benchmark is to run it on your own hardware, and the only way to be certain that has any meaning is to make the benchmark as much like the real world as you can. And, as I have said alread in this thread, raw performance is seldom the be-all end-all of software develoment decisions. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
On Mon, October 16, 2006 9:43 pm, Larry Garfield wrote: I suspect that serialization overhead is trivial for scalar data, and only starts to kill you when one starts schlepping bloated OOP structures or arrays back and forth -- at which point you messed up your architecture, and the serialization performance is just a symptom, not the disease. Yes, serialization is trivial for scalar data. However, to use a real-world example, the Drupal CMS allows users to define an unlimited number of path aliases. They're just key/value mappings, one string to another. Any given page can have dozens of links on it, which means dozens of mappings. The database table is really just a simple two column table, user path to system path. In older versions, the system pulled the whole table out at once and built a look up array, once per page. Only one query per page, but it meant a lot of data to pull and build. On sites with lots of aliases, that got very slow. So the latest version now pulls records one at a time. But that's a ton of SQL queries, many of which simply find no data in the first place. So now there's talk of building the look up table one record at a time and caching that, but the serialization/deserialization costs there are non-trivial when you're talking about a large array. The balance is still being worked out. :-) I'm just pointing out that no matter how you slice it, there is no free lunch performance-wise when you need to store data. The right balance will depend greatly on your use case. One Idea: Pull all the records in one query at first request and keep the $result around -- but don't walk through the whole thing. *DO* sort the records by the input value with an ORDER BY on an indexed field. Now, to find an actual lookup, use a binary search with mysql_seek() and cache any lookup results in an array. Not sure it will be faster, but run some benchmarks and see. :-) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
Almost ALL of this is moot for any but the hardest-hit sites -- So choosing your session store based solely on performance for a boutique store is just plain silly. You don't have to be one of the hardest-hit sites to benefit. I won't go so far as to say that all sites benefit, but even the boutique benefits, if you're running multiple sites on one server, which is common. I agree with the other stuff you said about serialization :) -Ed -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
On Mon, October 16, 2006 2:44 pm, Ed Lazor wrote: Almost ALL of this is moot for any but the hardest-hit sites -- So choosing your session store based solely on performance for a boutique store is just plain silly. You don't have to be one of the hardest-hit sites to benefit. I won't go so far as to say that all sites benefit, but even the boutique benefits, if you're running multiple sites on one server, which is common. I agree with the other stuff you said about serialization :) My thesis is that choosing SOLELY on raw performance without regard to security, scalability is silly, and it's particularly silly on sites that get so little traffic that raw performance tests and benchmarks are rendered meaningless. E.g., I don't really CARE what happens when you run my shopping cart code 1 billion times, because it's not going to be run 1 billion times in its entire life-cycle :-) I want code I can maintain and not have to wrap my brain into a pretzel to change the price of a product. Yeah, sure, in a shared hosting environment, a really bad script can be problematic -- I know, cuz I've gotten those emails from my webhost :-) [not about a shopping cart, but about incorrectly-optimized geo-search queries, actually -- fixed.] -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
On Oct 16, 2006, at 1:03 PM, Richard Lynch wrote: My thesis is that choosing SOLELY on raw performance without regard to security, scalability is silly, and it's particularly silly on sites that get so little traffic that raw performance tests and benchmarks are rendered meaningless. I that case, I agree with you whole heartedly. Security and scalability are definitely important. Yeah, sure, in a shared hosting environment, a really bad script can be problematic -- I know, cuz I've gotten those emails from my webhost :-) So you're the one! ;) hehe -Ed -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
# [EMAIL PROTECTED] / 2006-10-15 16:54:29 -0700: On Oct 15, 2006, at 3:27 PM, Tony Di Croce wrote: Wow... well, I was certainly not speaking from direct experience, only from what seemed to make sense to me. This tells me that their is some serious room for improvement in PHP de-serialization code... Well, kinda. Hard disks are a lot slower than ram and that gives file storage a disadvantage. You can setup disk caching to help, but the OS still starts to lag when you have a lot of files in one directory, which is what happens with session data files. Modern filesystems cope well with large directories (plus it's quite trivial to derive a directory hierarchy from the filenames). Looking at the numbers produced by timing various operations in a directory with exactly 100,000 files on sw RAID 1 (2 SATA disks) in my desktop i'd say this concern is completely baseless. MySQL tries to cache data in memory as much as possible. It cannot (MUST NOT) cache writes. It still uses files, but hopefully you don't hit them very often, especially when you're dealing with the same table records. A RDBMS is basically required to hit the disk with the data on commit. One of the defining features of a RDBMS, Durability, says that once you commit, the data is there no matter what. The host OS may crash right after the commit has been acked, the data must stay. You can turn on query caching in MySQL, but this will give you *nothing* for purposes of session storage. Also, having raw data is always faster than having to process it before you can use it. I don't know what that means. Bytes in files on disk are as raw as it gets, you get one roundtrip process - kernel - process; compare the communication protocol MySQL (or just any other DB) uses where data is marshalled by the client, and unmarshalled by the server, overhead of the database process(es) taking part in the write... So no, it makes no sense for a database to be faster than filesystem. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
On Oct 16, 2006, at 6:20 PM, Roman Neuhauser wrote: Modern filesystems cope well with large directories (plus it's quite trivial to derive a directory hierarchy from the filenames). Looking at the numbers produced by timing various operations in a directory with exactly 100,000 files on sw RAID 1 (2 SATA disks) in my desktop i'd say this concern is completely baseless. I knew that you could get PHP to use a directory structure for the session data files, but hearing that you can have 100k files in a single directory and not run into performance issues or problems is news to me. Which OS are you running? It still uses files, but hopefully you don't hit them very often, especially when you're dealing with the same table records. A RDBMS is basically required to hit the disk with the data on commit. One of the defining features of a RDBMS, Durability, says that once you commit, the data is there no matter what. The host OS may crash right after the commit has been acked, the data must stay. You can turn on query caching in MySQL, but this will give you *nothing* for purposes of session storage. Unless session storage is used to save time in retrieving data, right? I'm seeing your point on the writing, but what about reading? I think it would be kind of fun to run some actual tests. Also, having raw data is always faster than having to process it before you can use it. I don't know what that means. If you pull a record from the db, you can access the data. Or you can query the db, get the serialized data, de-serialize it, and now access the data. Bytes in files on disk are as raw as it gets, you get one roundtrip process - kernel - process; compare the communication protocol MySQL (or just any other DB) uses where data is marshalled by the client, and unmarshalled by the server, overhead of the database process(es) taking part in the write... So no, it makes no sense for a database to be faster than filesystem. I tested this previously and found the database to be faster. The references I gave supported this and listed additional benefits. Things change tho, especially with technology. It seems like we should be able to test this pretty easily. I actually think it would be fun to do as well. Do you have a box we can test this on? Meanwhile, I'll check one of my boxes to see if I can use it. If anything, it'll be interesting to see if two systems report the same. -Ed -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
On Monday 16 October 2006 14:11, Richard Lynch wrote: I suspect that serialization overhead is trivial for scalar data, and only starts to kill you when one starts schlepping bloated OOP structures or arrays back and forth -- at which point you messed up your architecture, and the serialization performance is just a symptom, not the disease. Yes, serialization is trivial for scalar data. However, to use a real-world example, the Drupal CMS allows users to define an unlimited number of path aliases. They're just key/value mappings, one string to another. Any given page can have dozens of links on it, which means dozens of mappings. The database table is really just a simple two column table, user path to system path. In older versions, the system pulled the whole table out at once and built a look up array, once per page. Only one query per page, but it meant a lot of data to pull and build. On sites with lots of aliases, that got very slow. So the latest version now pulls records one at a time. But that's a ton of SQL queries, many of which simply find no data in the first place. So now there's talk of building the look up table one record at a time and caching that, but the serialization/deserialization costs there are non-trivial when you're talking about a large array. The balance is still being worked out. :-) I'm just pointing out that no matter how you slice it, there is no free lunch performance-wise when you need to store data. The right balance will depend greatly on your use case. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
Wow... well, I was certainly not speaking from direct experience, only from what seemed to make sense to me. This tells me that their is some serious room for improvement in PHP de-serialization code... td Sorry Tony, I should have been more clear. I already know that storing session data in MySQL is faster than storing it in files. I know that goes against what you're saying, but there are some examples if you Google PHP MySQL session performance. One of the more interesting examples is http://shiflett.org/articles/guru-speak- jan2005. PHP session management defaults to files because it's more portable and the performance difference doesn't matter for small sites with few concurrent users. MySQL also provides better scaleability and security for session data. On Oct 14, 2006, at 2:51 PM, Larry Garfield wrote: It depends on what your data is. Is your data basic (a few elements in a linear array) or complex (a deeply nested multi-dimensional array or complex object?) Deserializing a complex data structure can get expensive. Is your data built by a single simple query against the database, a single but very complex query with lots of joins and subqueries, or a bunch of separate queries over the course of the program? A single SQL query for cached data is likely faster than lots of little queries. Is your data something that's going to change every few seconds, every few minutes, or every few days? Caching something that will change by your next page request anyway is a waste of cycles. Is your data needed on every page load? Putting a complex data structure into the session if you only need it occasionally is a waste of cycles. You're better off rebuilding it each time or implementing your own caching mechanism that only loads on demand. There is no general answer here. Good points Larry. I have to look back, but I think we were originally talking about basic user data. ie. the user logs into the site and we store their login information and access rights in a session. That seems like basic enough information that it's better to just store the user id in session data and grab the rest of their information from the db - not much of a difference in performance, plus you end up avoiding stale data. Anyway, I like your distinction between simple and complex objects. -Ed -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Publish technical articles @ skilledwords.com and get 100% of the ad-revenue! http://www.skilledwords.com
Re: [PHP] A no brainer...
On Oct 15, 2006, at 3:27 PM, Tony Di Croce wrote: Wow... well, I was certainly not speaking from direct experience, only from what seemed to make sense to me. This tells me that their is some serious room for improvement in PHP de-serialization code... Well, kinda. Hard disks are a lot slower than ram and that gives file storage a disadvantage. You can setup disk caching to help, but the OS still starts to lag when you have a lot of files in one directory, which is what happens with session data files. MySQL tries to cache data in memory as much as possible. It still uses files, but hopefully you don't hit them very often, especially when you're dealing with the same table records. Also, having raw data is always faster than having to process it before you can use it. Make sense? -Ed -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
On Friday 13 October 2006 20:18, Tony Di Croce wrote:
Is their a slick way of automatically serializing Objects to the session
when a script exit()'s and de-serialize them in session_start()?
It seems to me that object oriented PHP might actually be useful if I could
persist an object across an entire session, and come to think of it, their
really ought to be an automatic way to do this... (IE, I'd not be suprised
one bit if its already a feature of PHP that I'm just not aware of)...
So, is their a way to do this?
class Foo {
...
}
session_start();
$foo = new Foo();
$_SESSION['myfoo'] = $foo;
Ta da. The catch is the class must be defined before you start the session,
so that it knows how to deserialize it.
Of course, the cost of serialization and deserialization is non-trivial for
any data structure that is of interesting size, and you have to keep in mind
that if you aren't syncing to the database periodically then you will end up
with stale data objects. (An issue in any case, but the longer the object
representing a view of your database exists, the more of a problem it
becomes. YMMV depending on the data you're holding.)
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it. -- Thomas
Jefferson
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
Of course, the cost of serialization and deserialization is non- trivial for any data structure that is of interesting size, and you have to keep in mind that if you aren't syncing to the database periodically then you will end up with stale data objects. (An issue in any case, but the longer the object representing a view of your database exists, the more of a problem it becomes. YMMV depending on the data you're holding.) Has anyone done tests on the difference between the value and performance of serializing data structures versus just pulling the data from the database? PHP stores session data in files by default. There's gotta be a performance hit for the file access. If you store session data in MySQL, you're still making a DB query. It seems to me that the performance is almost the same, which means grabbing the current record ends up better because you avoid stale data. What do you think? -Ed -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
On Saturday 14 October 2006 11:02, Ed Lazor wrote: Of course, the cost of serialization and deserialization is non- trivial for any data structure that is of interesting size, and you have to keep in mind that if you aren't syncing to the database periodically then you will end up with stale data objects. (An issue in any case, but the longer the object representing a view of your database exists, the more of a problem it becomes. YMMV depending on the data you're holding.) Has anyone done tests on the difference between the value and performance of serializing data structures versus just pulling the data from the database? PHP stores session data in files by default. There's gotta be a performance hit for the file access. If you store session data in MySQL, you're still making a DB query. It seems to me that the performance is almost the same, which means grabbing the current record ends up better because you avoid stale data. What do you think? -Ed It depends on what your data is. Is your data basic (a few elements in a linear array) or complex (a deeply nested multi-dimensional array or complex object?) Deserializing a complex data structure can get expensive. Is your data built by a single simple query against the database, a single but very complex query with lots of joins and subqueries, or a bunch of separate queries over the course of the program? A single SQL query for cached data is likely faster than lots of little queries. Is your data something that's going to change every few seconds, every few minutes, or every few days? Caching something that will change by your next page request anyway is a waste of cycles. Is your data needed on every page load? Putting a complex data structure into the session if you only need it occasionally is a waste of cycles. You're better off rebuilding it each time or implementing your own caching mechanism that only loads on demand. There is no general answer here. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] A no brainer...
On Oct 14, 2006, at 10:00 AM, Tony Di Croce wrote: I think that the cost of de-serializing a session stored in files should be significantly LESS than the cost of doing so through a database, for the following reasons: 1) The db will need to parse querys. Not an issue for files. 2) The session ID will tell PHP what file to open in O(1). 3) The entire session needs to be de-serialized, not just some portion of it. The database is optimized for returning subsets of all the data. Sorry Tony, I should have been more clear. I already know that storing session data in MySQL is faster than storing it in files. I know that goes against what you're saying, but there are some examples if you Google PHP MySQL session performance. One of the more interesting examples is http://shiflett.org/articles/guru-speak- jan2005. PHP session management defaults to files because it's more portable and the performance difference doesn't matter for small sites with few concurrent users. MySQL also provides better scaleability and security for session data. On Oct 14, 2006, at 2:51 PM, Larry Garfield wrote: It depends on what your data is. Is your data basic (a few elements in a linear array) or complex (a deeply nested multi-dimensional array or complex object?) Deserializing a complex data structure can get expensive. Is your data built by a single simple query against the database, a single but very complex query with lots of joins and subqueries, or a bunch of separate queries over the course of the program? A single SQL query for cached data is likely faster than lots of little queries. Is your data something that's going to change every few seconds, every few minutes, or every few days? Caching something that will change by your next page request anyway is a waste of cycles. Is your data needed on every page load? Putting a complex data structure into the session if you only need it occasionally is a waste of cycles. You're better off rebuilding it each time or implementing your own caching mechanism that only loads on demand. There is no general answer here. Good points Larry. I have to look back, but I think we were originally talking about basic user data. ie. the user logs into the site and we store their login information and access rights in a session. That seems like basic enough information that it's better to just store the user id in session data and grab the rest of their information from the db - not much of a difference in performance, plus you end up avoiding stale data. Anyway, I like your distinction between simple and complex objects. -Ed -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] A no brainer...
Is their a slick way of automatically serializing Objects to the session when a script exit()'s and de-serialize them in session_start()? It seems to me that object oriented PHP might actually be useful if I could persist an object across an entire session, and come to think of it, their really ought to be an automatic way to do this... (IE, I'd not be suprised one bit if its already a feature of PHP that I'm just not aware of)... So, is their a way to do this? -- Publish technical articles @ skilledwords.com and get 100% of the ad-revenue! http://www.skilledwords.com
