trlists@xxxxxxxxxx wrote: > On 15 Feb 2005 Richard Lynch wrote: > >> 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 -- > > Perhaps if you are already familiar with ab, which I'm not ... and if > the server supports it, which it does not at this moment, development > is on Windows, later testing and deployment on Linux. > >> 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. > > The data is an internal list of items on the form, all the form field > specs, the data for the fields, default data for resetting the form, > and a data structure for the forms class. Most of these are in > associative arrays, sometimes nested a couple of levels deep. If I'm > going to build a database structure that mirrors the array structure, > and update it every time the array changes during development, that's > hardly straightforward. Without that, I'll have to serialize and > unserialize the data -- and if I'm going to do that, I'd guess that I > might as well use the session vars. So maybe that answers the > question, and the remainder (below) is theoretical. YES! Don't try to change your whole application to use SQL instead of arrays. Use the exact same session stuff you have now and just dump the serialized data into SQL using the 5 functions for session handling. This is going to be *WAY* cheaper than doing an SQL query for every change to the data. It's literally an hour's work to alter the code to use MySQL to store the sessions instead of the hard drive. This might or might not improve performance. It's incredibly UNLIKELY that trying to send an SQL query for every single line of code that currently does $_SESSION[...] = ...; is going to be faster... I'd almost be willing to say IMPOSSIBLE that would be faster, but somebody would post a trivial example to prove me wrong :-) For your real-world application with a ton of data, you're now looking at: 1. Your existing file-based sessions. 2. Your existing sessions, but cram the serialized data in/out of SQL. 3. Re-write everything to send SQL back and forth instead of assigning to $_SESSION and then doing a serialize/unserialize at beginning/end of script. Ain't no way #3 is gonna win performance-wise in any REAL scenario where you care about performance. Not promising #2 is gonna be faster, much less "fast enough" but it's worth testing. >> Sending the actual query and getting/storing the results will be >> chump-change compared to opening the db connection, almost for sure. > > I do actually need a DB connection on every page anyway, so there's no > benefit to avoiding one for this purpose. But to me the likely > consumer of cycles here with a database structure matching the data > structure would be the conversion of MySQL data into an associative > array, and I'd be comparing that to serializing and unserializing. I > don't think either is going to be trivial. The PHP session stuff will do all that for you. You just handle the pre-serialized data and shlep it into MySQL instead of the files. There was another thread recently on loading large arrays and how to avoid having to serialize/unserialize the data if you wanted to, say, store those in some kind of cross-script common storage. The upshot was that you *COULD* use shared memory, if you really knew what you were doing, and avoid the serialize/unserialize, and if you could figure out a way to have only the first PHP process initialize the shared memory. But you'd probably find it easier to write a C extension and re-compile PHP to pre-load all the stuff. None of which applies to you, I don't think, but you may want to re-read that thread. -- 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
