Greg Donald wrote: > On Mon, 14 Feb 2005 16:03:10 -0500, trlists@xxxxxxxxxx > <trlists@xxxxxxxxxx> wrote: >> I have a multi-page form which I build up and store in session >> variables. The data saved includes all an internal list of items on >> the form (derived from a database table), all the form field specs >> (derived from the internal item list), the data for the fields (from >> another table), default data for restting the form (from yet another >> table), and a data structure for my forms class. >> >> It adds up to about 250KB in the actual session file -- that is, the >> serialized data. >> >> I'm not clear of the impact this will have in performance when it's in >> a multi-user environment, and I'm not sure at what point the overhead Throw an ab (Apache Benchmark) test at it and find out. Don't just guess or sit there wondering. You could run test in about the time it took to compose this email -- certainly as fast as the total man-hours put in by all of us reading/discussing it on the list :-) >> of serializing and unserializing gets to be more than the overhead of >> sticking this stuff in a temporary database table and then retrieving >> it. Serializing is simpler but my git says there has to be a point at >> which it gets inefficient. Testing is complex since I would have to >> write all the database code in order to do any performance measurement. Actually... All the database code is already written for you on the PHP web-site, and it's about one 8.5x11 page of five (5) functions. Doesn't really sound like a complex test to me. Even if it *IS* a "lot" to do... The database connection is going to dwarf the rest of it, almost for sure, so just time how long it takes to open up a database connection, compared to loading your existing file-based sessions. Sending the actual query and getting/storing the results will be chump-change compared to opening the db connection, almost for sure. *UNLESS* every page that needs session data already *HAS* a db connection. At which point you are comparing: Hard drive access, with hard drive cache and page faults Database access, with database buffers These two will be neck-and-neck on performance, and will depend more on your hardware than on somebody else's experience with their hardware. Particularly if you've got a 2-tier setup with database on one box and PHP on another, where your network hardware and cabling gets involved. >> Anyone have relevant experience in this area, and/or some educated >> guesses? > > You can minimize the data storage requirements by using short variable > names and casting your numeric values to integers when possible. > > PHP sessions store everything as strings unless you specify otherwise. > For example, here is the integer 123 stored in a session both ways, > as a string and cast to an integer: > > v|s:3:"123"; > > v|i:123; > > There are other things too.. like converting IP addresses to longs > with ip2long(). Storing a long int is more efficient than storing > 7-15 bytes of character data. > > Just look at your session data and see what can be stored smaller, > variable names included. [shudder] If you have to choose between a meaningful variable name and performance considerations, buy more hardware! :-) The cost you'll save in the long run for code maintenance will make it worth it. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
