Re: [PHP] SESSIONS vs. MySQL
Eric Butera wrote: Wouldn't you (probably) loose sessions in /tmp if the box crashed also? No, that wouldn't be the default behaviour. /tmp is typically on the filesystem, and it's not cleared on every reboot (unless your system has been configured to do so). /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
Philip Thompson wrote: Ok, so I've implemented this in several places where information basically does not change from page to page. Jumping to the point/ question... when does it become more inefficient to store lots of information in SESSION variables than to run several more queries? Note, we are actually storing sessions in the database - so a read/ write is required on each page load - it's not file sessions. I don't think you're likely to see any measurable difference, not until your sessions get VERY big (I'm guessing megabytes). There's is overhead associated with both forms - the SESSION data must be serialized/de-serialized, the mysql calls organises data to/from an associative array etc., but what is hauled out of the database is essentially the same, it's only the transmission method that differs. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
Per Jessen a écrit : No, that wouldn't be the default behaviour. /tmp is typically on the filesystem, and it's not cleared on every reboot (unless your system has been configured to do so). In Debian based, it is the default behaviour. i hope it is the same in other major distributions. The last fashion is to use a tmpfs to mount /tmp -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
Lupus Michaelis wrote: Per Jessen a écrit : No, that wouldn't be the default behaviour. /tmp is typically on the filesystem, and it's not cleared on every reboot (unless your system has been configured to do so). In Debian based, it is the default behaviour. i hope it is the same in other major distributions. Well, it isn't. SUSE and openSUSE have never cleared /tmp by default. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On Sep 20, 2008, at 7:28 AM, Ashley Sheridan wrote: On Fri, 2008-09-19 at 10:17 -0500, Philip Thompson wrote: Hi all. Let me start out by saying, I have STFW and read through the list archives. Now that that's out of the way. To speed up our application, we want to implement using SESSIONs in some locations. Beforehand, on every page, we would run approximately 30-40 queries just to get the page setup - user information and other stuff. Now while we can't take away all of the setup queries, we would like to reduce the startup number. Ok, so I've implemented this in several places where information basically does not change from page to page. Jumping to the point/ question... when does it become more inefficient to store lots of information in SESSION variables than to run several more queries? Note, we are actually storing sessions in the database - so a read/ write is required on each page load - it's not file sessions. Now I know this can depend on the complexity of the queries and how much data is actually stored inside the sessions... but initial thoughts? To give you a number, the strlen of the _SESSION array is 325463 - which is equivalent to the number of bytes (I think). Thanks, ~Philip Why do you have so many queries? Is there any way you could use joins to drop that number down. It might not seem like lot when only a few people are using the site, but it will start being a problem when you get more people using it. Ash Well, there are different queries depending on how *far* you get into the app. If you fail at level 2, why already grab the data that's need at level 5 or 6? And besides, using joins is expensive. The queries pull different data - if there's no relation between tables, a join won't work. However, because the database is normalized (to the 3rd degree), we use joins all over the place. ~Phil -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
Philip Thompson schreef: Hi all. Let me start out by saying, I have STFW and read through the list archives. Now that that's out of the way. To speed up our application, we want to implement using SESSIONs in some locations. Beforehand, on every page, we would run approximately 30-40 queries just to get the page setup - user information and other stuff. Now while we can't take away all of the setup queries, we would like to reduce the startup number. Ok, so I've implemented this in several places where information basically does not change from page to page. Jumping to the point/question... when does it become more inefficient to store lots of information in SESSION variables than to run several more queries? Note, we are actually storing sessions in the database - so a read/write is required on each page load - it's not file sessions. Now I know this can depend on the complexity of the queries and how much data is actually stored inside the sessions... but initial thoughts? To give you a number, the strlen of the _SESSION array is 325463 - which is equivalent to the number of bytes (I think). not exactly - depends on how you measure it, also the serialized form of the session data is longer still because it contains data type descriptions et al. are you running on a linux box? if so try using session files again and sticking your session data in /dev/shm/some-dir which effectively means your sticking the files in RAM ... generally much faster than using a DB or the FS, on the other hand this is rather volatile (if the box goes down you lose all the data ... but then you have other problems probably, you can get round it by regularly backing up the contents of /dev/shm/some-dir and restoring the backup if/when the machine reboots ... the backup can occur out of process, so your page performance isn't directly effected, you'd still have to think about file locking etc) I use this trick quite often, generally without bothering to backup the session data (I figure if the site goes down completely then losing session data is the least of my worries ... and a user won't be all that surprised to find his login status wiped when the site comes back up ... although he/she might be a little miffed) Thanks, ~Philip -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On Sun, Sep 21, 2008 at 6:48 PM, Jochem Maas [EMAIL PROTECTED] wrote: Philip Thompson schreef: Hi all. Let me start out by saying, I have STFW and read through the list archives. Now that that's out of the way. To speed up our application, we want to implement using SESSIONs in some locations. Beforehand, on every page, we would run approximately 30-40 queries just to get the page setup - user information and other stuff. Now while we can't take away all of the setup queries, we would like to reduce the startup number. Ok, so I've implemented this in several places where information basically does not change from page to page. Jumping to the point/question... when does it become more inefficient to store lots of information in SESSION variables than to run several more queries? Note, we are actually storing sessions in the database - so a read/write is required on each page load - it's not file sessions. Now I know this can depend on the complexity of the queries and how much data is actually stored inside the sessions... but initial thoughts? To give you a number, the strlen of the _SESSION array is 325463 - which is equivalent to the number of bytes (I think). not exactly - depends on how you measure it, also the serialized form of the session data is longer still because it contains data type descriptions et al. are you running on a linux box? if so try using session files again and sticking your session data in /dev/shm/some-dir which effectively means your sticking the files in RAM ... generally much faster than using a DB or the FS, on the other hand this is rather volatile (if the box goes down you lose all the data ... but then you have other problems probably, you can get round it by regularly backing up the contents of /dev/shm/some-dir and restoring the backup if/when the machine reboots ... the backup can occur out of process, so your page performance isn't directly effected, you'd still have to think about file locking etc) I use this trick quite often, generally without bothering to backup the session data (I figure if the site goes down completely then losing session data is the least of my worries ... and a user won't be all that surprised to find his login status wiped when the site comes back up ... although he/she might be a little miffed) Thanks, ~Philip -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Wouldn't you (probably) loose sessions in /tmp if the box crashed also? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On Fri, 2008-09-19 at 10:17 -0500, Philip Thompson wrote: Hi all. Let me start out by saying, I have STFW and read through the list archives. Now that that's out of the way. To speed up our application, we want to implement using SESSIONs in some locations. Beforehand, on every page, we would run approximately 30-40 queries just to get the page setup - user information and other stuff. Now while we can't take away all of the setup queries, we would like to reduce the startup number. Ok, so I've implemented this in several places where information basically does not change from page to page. Jumping to the point/ question... when does it become more inefficient to store lots of information in SESSION variables than to run several more queries? Note, we are actually storing sessions in the database - so a read/ write is required on each page load - it's not file sessions. Now I know this can depend on the complexity of the queries and how much data is actually stored inside the sessions... but initial thoughts? To give you a number, the strlen of the _SESSION array is 325463 - which is equivalent to the number of bytes (I think). Thanks, ~Philip Why do you have so many queries? Is there any way you could use joins to drop that number down. It might not seem like lot when only a few people are using the site, but it will start being a problem when you get more people using it. Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
At 5:00 PM -0400 9/19/08, Robert Cummings wrote: On Fri, 2008-09-19 at 21:31 +0100, Stut wrote: I can modify this: http://webbytedd.com/bb/pdf/ He said EXPENSIVE you insensitive clod! Ahh, mood swings from ink poisoning? Tedd: Charge $100 per certificate, Rob'll buy one, maybe even two!! I've managed to avoid getting the Zend certification until now despite many many people trying to convince me it's worth it. As both an employee and an employer I just don't see the value. The last practice tests I saw were primarily memory tests - that's not a useful measure in my book. I'm also in the camp of avoiding getting Zend certification. As you point out, it's merely a test on memorization of simple (and occasionally obscure) language constructs. It's hardly an example of how a person thinks, tackles problems, and can effectively develop solutions. I'm of the same notion. If my three degrees, on-line code examples, past work, willingness to show what I can do, and website aren't enough, then I'm not sure a Zend certification (or any certification for that matter) will help. From my experience, I have more than enough to open any door, the problem is finding more doors. I find it interesting that there are few programmers that can we and so many businesses have/want web sites, but I'm usually the one who's knocking on doors -- one would think it would be the other way around. For the past year, I've worked with a company who provide me jobs. They find the clients and I do the work and that's worked out very well. But last month they told me that they are not happy with their business -- too many headaches dealing with clients and they will not be looking for more clients. So, I will be pounding the streets looking for work again. I have clients looking for customers and I seem to be able to solve their problems, maybe I should hire myself? In any event, my website is going to receive a minor facelift and I'm trolling again. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
At 9:31 PM +0100 9/19/08, Stut wrote: On 19 Sep 2008, at 21:22, Robert Cummings wrote: On Fri, 2008-09-19 at 16:15 -0400, tedd wrote: At 3:11 PM -0400 9/19/08, Eric Butera wrote: On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings [EMAIL PROTECTED] wrote: 4. lack of industry adoption There needs to be some sort of expensive test to certify one may wear the badge. Then it will have higher adoption rates. I can modify this: http://webbytedd.com/bb/pdf/ He said EXPENSIVE you insensitive clod! Ahh, mood swings from ink poisoning? Tedd: Charge $100 per certificate, Rob'll buy one, maybe even two!! I've thought about making a site where the user could enter in whatever degree they wanted (i.e, Harvard, Yale, whatever) and the site would print out the certificate for free. Then for $5.00, I would give them a one-time key to remove the VOID from the document. How's that? Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
At 4:53 PM -0400 9/19/08, Jason Pruim wrote: Time's off by an hour :) That's probably a day-light saving thing -- doesn't matter anyway. I could have my graphic designer whip something up hehee :) The problem is not designing the form, but rather programming it. Each form takes a lot of time to get each element exactly where it should be. But, anything a graphic designer can create, I can copy. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] SESSIONS vs. MySQL
Hi all. Let me start out by saying, I have STFW and read through the list archives. Now that that's out of the way. To speed up our application, we want to implement using SESSIONs in some locations. Beforehand, on every page, we would run approximately 30-40 queries just to get the page setup - user information and other stuff. Now while we can't take away all of the setup queries, we would like to reduce the startup number. Ok, so I've implemented this in several places where information basically does not change from page to page. Jumping to the point/ question... when does it become more inefficient to store lots of information in SESSION variables than to run several more queries? Note, we are actually storing sessions in the database - so a read/ write is required on each page load - it's not file sessions. Now I know this can depend on the complexity of the queries and how much data is actually stored inside the sessions... but initial thoughts? To give you a number, the strlen of the _SESSION array is 325463 - which is equivalent to the number of bytes (I think). Thanks, ~Philip -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
Philip Thompson [EMAIL PROTECTED] wrote: Hi all. Let me start out by saying, I have STFW and read through the list archives. Now that that's out of the way. To speed up our application, we want to implement using SESSIONs in some locations. Beforehand, on every page, we would run approximately 30-40 queries just to get the page setup - user information and other stuff. Now while we can't take away all of the setup queries, we would like to reduce the startup number. Ok, so I've implemented this in several places where information basically does not change from page to page. Jumping to the point/ question... when does it become more inefficient to store lots of information in SESSION variables than to run several more queries? Note, we are actually storing sessions in the database - so a read/ write is required on each page load - it's not file sessions. Now I know this can depend on the complexity of the queries and how much data is actually stored inside the sessions... but initial thoughts? To give you a number, the strlen of the _SESSION array is 325463 - which is equivalent to the number of bytes (I think). Thanks, ~Philip We carry a sh!tload of information in our session, without slowing anything down. In fact, it takes the servers longer to run a full query then to use the session information. But we use the $_SESSION information. Our first query sets everything up in the session and we take on from there, and use stuff from the $_SESSION to actually make the rest of the pages faster. 30-40 queries just to set up a page? That's an abomination that shouldn't see the light of day. Anything slower then 2 seconds without any interaction back to the users will be short-lived Wolf -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On Sep 19, 2008, at 10:54 AM, Wolf wrote: Philip Thompson [EMAIL PROTECTED] wrote: Hi all. Let me start out by saying, I have STFW and read through the list archives. Now that that's out of the way. To speed up our application, we want to implement using SESSIONs in some locations. Beforehand, on every page, we would run approximately 30-40 queries just to get the page setup - user information and other stuff. Now while we can't take away all of the setup queries, we would like to reduce the startup number. Ok, so I've implemented this in several places where information basically does not change from page to page. Jumping to the point/ question... when does it become more inefficient to store lots of information in SESSION variables than to run several more queries? Note, we are actually storing sessions in the database - so a read/ write is required on each page load - it's not file sessions. Now I know this can depend on the complexity of the queries and how much data is actually stored inside the sessions... but initial thoughts? To give you a number, the strlen of the _SESSION array is 325463 - which is equivalent to the number of bytes (I think). Thanks, ~Philip We carry a sh!tload of information in our session, without slowing anything down. In fact, it takes the servers longer to run a full query then to use the session information. But we use the $_SESSION information. Our first query sets everything up in the session and we take on from there, and use stuff from the $_SESSION to actually make the rest of the pages faster. 30-40 queries just to set up a page? That's an abomination that shouldn't see the light of day. Anything slower then 2 seconds without any interaction back to the users will be short-lived Wolf Even with 30-40 queries upon setup, it's very fast - less than 1 second... for now. We starting having speed issues in other locations. Hence, we decided to address every potential reason and possible slowndown in the future. Thanks for your input, Wolf. Any others storing sh!tloads in their SESSION array? =D ~Philip -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On 19 Sep 2008, at 17:05, Philip Thompson wrote: On Sep 19, 2008, at 10:54 AM, Wolf wrote: Philip Thompson [EMAIL PROTECTED] wrote: Hi all. Let me start out by saying, I have STFW and read through the list archives. Now that that's out of the way. To speed up our application, we want to implement using SESSIONs in some locations. Beforehand, on every page, we would run approximately 30-40 queries just to get the page setup - user information and other stuff. Now while we can't take away all of the setup queries, we would like to reduce the startup number. Ok, so I've implemented this in several places where information basically does not change from page to page. Jumping to the point/ question... when does it become more inefficient to store lots of information in SESSION variables than to run several more queries? Note, we are actually storing sessions in the database - so a read/ write is required on each page load - it's not file sessions. Now I know this can depend on the complexity of the queries and how much data is actually stored inside the sessions... but initial thoughts? To give you a number, the strlen of the _SESSION array is 325463 - which is equivalent to the number of bytes (I think). Thanks, ~Philip We carry a sh!tload of information in our session, without slowing anything down. In fact, it takes the servers longer to run a full query then to use the session information. But we use the $_SESSION information. Our first query sets everything up in the session and we take on from there, and use stuff from the $_SESSION to actually make the rest of the pages faster. 30-40 queries just to set up a page? That's an abomination that shouldn't see the light of day. Anything slower then 2 seconds without any interaction back to the users will be short-lived Wolf Even with 30-40 queries upon setup, it's very fast - less than 1 second... for now. We starting having speed issues in other locations. Hence, we decided to address every potential reason and possible slowndown in the future. Thanks for your input, Wolf. Any others storing sh!tloads in their SESSION array? =D How much of that data do you actually need on each request? I can't believe you need it all for every single page so why bother loading it? My take on storing stupid amounts of data in sessions: http:// stut.net/blog/2008/07/26/sessionless-sessions-2/ - take it or leave it. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On Fri, Sep 19, 2008 at 12:05 PM, Philip Thompson [EMAIL PROTECTED]wrote: On Sep 19, 2008, at 10:54 AM, Wolf wrote: Philip Thompson [EMAIL PROTECTED] wrote: Hi all. Let me start out by saying, I have STFW and read through the list archives. Now that that's out of the way. To speed up our application, we want to implement using SESSIONs in some locations. Beforehand, on every page, we would run approximately 30-40 queries just to get the page setup - user information and other stuff. Now while we can't take away all of the setup queries, we would like to reduce the startup number. Ok, so I've implemented this in several places where information basically does not change from page to page. Jumping to the point/ question... when does it become more inefficient to store lots of information in SESSION variables than to run several more queries? Note, we are actually storing sessions in the database - so a read/ write is required on each page load - it's not file sessions. Now I know this can depend on the complexity of the queries and how much data is actually stored inside the sessions... but initial thoughts? To give you a number, the strlen of the _SESSION array is 325463 - which is equivalent to the number of bytes (I think). Thanks, ~Philip We carry a sh!tload of information in our session, without slowing anything down. In fact, it takes the servers longer to run a full query then to use the session information. But we use the $_SESSION information. Our first query sets everything up in the session and we take on from there, and use stuff from the $_SESSION to actually make the rest of the pages faster. 30-40 queries just to set up a page? That's an abomination that shouldn't see the light of day. Anything slower then 2 seconds without any interaction back to the users will be short-lived Wolf Even with 30-40 queries upon setup, it's very fast - less than 1 second... for now. We starting having speed issues in other locations. Hence, we decided to address every potential reason and possible slowndown in the future. Thanks for your input, Wolf. Any others storing sh!tloads in their SESSION array? =D ~Philip -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I'm storing a lot also. I store sessions in the database also, and utilize session_set_save_handler(). Works well, and less overhead. Like you said, you're under 1 second *NOW*. 1 second might actually even be a long time. -- -Dan Joseph www.canishosting.com - Plans start @ $1.99/month. Build a man a fire, and he will be warm for the rest of the day. Light a man on fire, and will be warm for the rest of his life.
Re: [PHP] SESSIONS vs. MySQL
On Fri, Sep 19, 2008 at 12:05 PM, Philip Thompson [EMAIL PROTECTED] wrote: On Sep 19, 2008, at 10:54 AM, Wolf wrote: Philip Thompson [EMAIL PROTECTED] wrote: Hi all. Let me start out by saying, I have STFW and read through the list archives. Now that that's out of the way. To speed up our application, we want to implement using SESSIONs in some locations. Beforehand, on every page, we would run approximately 30-40 queries just to get the page setup - user information and other stuff. Now while we can't take away all of the setup queries, we would like to reduce the startup number. Ok, so I've implemented this in several places where information basically does not change from page to page. Jumping to the point/ question... when does it become more inefficient to store lots of information in SESSION variables than to run several more queries? Note, we are actually storing sessions in the database - so a read/ write is required on each page load - it's not file sessions. Now I know this can depend on the complexity of the queries and how much data is actually stored inside the sessions... but initial thoughts? To give you a number, the strlen of the _SESSION array is 325463 - which is equivalent to the number of bytes (I think). Thanks, ~Philip We carry a sh!tload of information in our session, without slowing anything down. In fact, it takes the servers longer to run a full query then to use the session information. But we use the $_SESSION information. Our first query sets everything up in the session and we take on from there, and use stuff from the $_SESSION to actually make the rest of the pages faster. 30-40 queries just to set up a page? That's an abomination that shouldn't see the light of day. Anything slower then 2 seconds without any interaction back to the users will be short-lived Wolf Even with 30-40 queries upon setup, it's very fast - less than 1 second... for now. We starting having speed issues in other locations. Hence, we decided to address every potential reason and possible slowndown in the future. Thanks for your input, Wolf. Any others storing sh!tloads in their SESSION array? =D ~Philip -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I used to store objects in the session. I figured I used it a lot so why not. Then my app got really nasty and slow. Now I only store enough of the state to render the page. So instead of storing a complete user object I store the auth details to load a user object if needed. Only very simple parts of the state get loaded into my apps now. Now things are quite snappy again. Why do you have so many queries? Perhaps we can attack this issue from another angle. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
Use memcached based session handler Regards Sancar -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On Sep 19, 2008, at 11:10 AM, Eric Butera wrote: On Fri, Sep 19, 2008 at 12:05 PM, Philip Thompson [EMAIL PROTECTED] wrote: On Sep 19, 2008, at 10:54 AM, Wolf wrote: Philip Thompson [EMAIL PROTECTED] wrote: Hi all. Let me start out by saying, I have STFW and read through the list archives. Now that that's out of the way. To speed up our application, we want to implement using SESSIONs in some locations. Beforehand, on every page, we would run approximately 30-40 queries just to get the page setup - user information and other stuff. Now while we can't take away all of the setup queries, we would like to reduce the startup number. Ok, so I've implemented this in several places where information basically does not change from page to page. Jumping to the point/ question... when does it become more inefficient to store lots of information in SESSION variables than to run several more queries? Note, we are actually storing sessions in the database - so a read/ write is required on each page load - it's not file sessions. Now I know this can depend on the complexity of the queries and how much data is actually stored inside the sessions... but initial thoughts? To give you a number, the strlen of the _SESSION array is 325463 - which is equivalent to the number of bytes (I think). Thanks, ~Philip We carry a sh!tload of information in our session, without slowing anything down. In fact, it takes the servers longer to run a full query then to use the session information. But we use the $_SESSION information. Our first query sets everything up in the session and we take on from there, and use stuff from the $_SESSION to actually make the rest of the pages faster. 30-40 queries just to set up a page? That's an abomination that shouldn't see the light of day. Anything slower then 2 seconds without any interaction back to the users will be short-lived Wolf Even with 30-40 queries upon setup, it's very fast - less than 1 second... for now. We starting having speed issues in other locations. Hence, we decided to address every potential reason and possible slowndown in the future. Thanks for your input, Wolf. Any others storing sh!tloads in their SESSION array? =D ~Philip -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I used to store objects in the session. I figured I used it a lot so why not. Then my app got really nasty and slow. Now I only store enough of the state to render the page. So instead of storing a complete user object I store the auth details to load a user object if needed. Only very simple parts of the state get loaded into my apps now. Now things are quite snappy again. Why do you have so many queries? Perhaps we can attack this issue from another angle. I've narrowed it down to 10 initial queries... 1. Grab system config data (that's used in lots of places) 2. Grab session data (for SESSION array) 3. Grab page id 4. Grab user privs 5. Grab user session (for application) 6. Begin transaction 7. Lock user session row 8. Update user session 9. Commit transaction 10. Add page tracking (an insert-only table that keeps track of pages you visit) Note that these are the 10 queries that happen after the initial SESSION load. I supposed I could reduce this by 1 or 2 queries - I could store the page id/information in the session. Now with that said, the queries are negligible (in elapsed time) and required. However, I'm always open up to suggestions/improvements =D Thanks, ~Phil -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On Fri, 2008-09-19 at 12:47 -0500, Philip Thompson wrote: Why do you have so many queries? Perhaps we can attack this issue from another angle. I've narrowed it down to 10 initial queries... 1. Grab system config data (that's used in lots of places) Why not use some form of cache system that writes the config data to a file containing PHP code. Then this can be included at run-time and benefit from compile cachee accelerators like eAccelerator and APC? 2. Grab session data (for SESSION array) Fine. 3. Grab page id Grab the page ID? Don't you already have it if you're on the page? 4. Grab user privs This should be cached. Cache can be updated when you detect that user information has changed (do this when verifying user session). 5. Grab user session (for application) How is this different than the session data? 6. Begin transaction 7. Lock user session row 8. Update user session 9. Commit transaction Are you performing a transaction with locking for a single table row update? Seems wasteful. I'm sure the above could just consist of the update. 10. Add page tracking (an insert-only table that keeps track of pages you visit) Fair enough. Note that these are the 10 queries that happen after the initial SESSION load. I supposed I could reduce this by 1 or 2 queries - I could store the page id/information in the session. Now with that said, the queries are negligible (in elapsed time) and required. However, I'm always open up to suggestions/improvements =D I agree, these queries are probably quite negligible. If your page is taking a long time to load there's probably lower hanging fruit for optmization attempts. The problem is determining what they are. Another thing to improve database queries btw, if you're not already doing it... is to use the direct socket connection if you are on the same server as the database. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On 19 Sep 2008, at 18:47, Philip Thompson wrote: I've narrowed it down to 10 initial queries... 1. Grab system config data (that's used in lots of places) Does it change often? No? Then cache it in a PHP script. Use var_export to create a file that you can include which will create the configuration array. Alternatively cache it in a Memcache instance which is where my system-wide config usually lives. 2. Grab session data (for SESSION array) Meaning what? You say below that this is after the initial session load. What are you loading here and why is it being loaded on every page request if it's ending up in the $_SESSION array? 3. Grab page id What does this do, how is it used, is it needed? 4. Grab user privs IMHO you should only grab these when you need them. 5. Grab user session (for application) Again, why isn't this already in $_SESSION for every page request expect the first per visit? 6. Begin transaction 7. Lock user session row 8. Update user session 9. Commit transaction If all you're doing is issuing an update command there is no need to do so in a transaction and definitely no need to lock the row. An update is atomic. Maybe what you actually mean to do here is lock it before you get the session data, make changes to it and then unlock it once you're done changing it. Doing that would likely keep the row locked for the entire duration of a request which can start causing problems as traffic increases. 10. Add page tracking (an insert-only table that keeps track of pages you visit) I handle this using files and then have an offline processor to push that data into the database. If all you're doing is adding a row to the table you probably don't need this, but we do a fair amount of work for each page view to record the data in a set of tables designed for meaningful and speedy retrieval. Note that these are the 10 queries that happen after the initial SESSION load. I supposed I could reduce this by 1 or 2 queries - I could store the page id/information in the session. Now with that said, the queries are negligible (in elapsed time) and required. However, I'm always open up to suggestions/improvements =D You may think they're required, but I'm betting they're not if you really think about it. However, if your DB can handle it then why fix something that ain't broken. The way I approach this stuff is always with the knowledge that the database is the most expensive resource in the infrastructure, so anything I can do to avoid using it when it's not strictly necessary is something I consider well-worth the effort. With the rise of frameworks and the lazy architectures it's pretty common to end up with this mass of DB access at the start of each request, but it won't scale and it leads to assumptions that are extremely expensive to find and fix when you do need to scale. Trust me, I've been there many times and it's been painful every time! Oh, and by scale I don't necessarily mean to tens of millions of page views a month. Scalability is as much about going from 10 visitor a day to 1000 as it is from 1000 to several million. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On Fri, 2008-09-19 at 19:12 +0100, Stut wrote: Oh, and by scale I don't necessarily mean to tens of millions of page views a month. Someone needs to take away your coder badge if you make a site that can't handle 1000 views a day :) Not withstanding extreme edge cases doing unlikely processing for the typical website :B Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On 19 Sep 2008, at 19:20, Robert Cummings wrote: On Fri, 2008-09-19 at 19:12 +0100, Stut wrote: Oh, and by scale I don't necessarily mean to tens of millions of page views a month. Someone needs to take away your coder badge if you make a site that can't handle 1000 views a day :) Not withstanding extreme edge cases doing unlikely processing for the typical website :B Have you seen some of the advanced websites kicked out by design companies? Also consider the sites that get stuck on shared servers with 1000's of sites per machine using database servers with 1000's of DBs where limiting your resource usage can become the difference between a snappy site and one that nobody will use! And then try convincing your local plumber that it's worth paying more than £2 a month for their hosting! Actually, scrap that. It's usually the design company that's overloading their dedicated server, the plumber is then stuck paying £25+ a month + content change charges when they don't know any better. Anyways, where can I get a coder badge, they sound cool!! ;) -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On Fri, 2008-09-19 at 19:32 +0100, Stut wrote: On 19 Sep 2008, at 19:20, Robert Cummings wrote: On Fri, 2008-09-19 at 19:12 +0100, Stut wrote: Oh, and by scale I don't necessarily mean to tens of millions of page views a month. Someone needs to take away your coder badge if you make a site that can't handle 1000 views a day :) Not withstanding extreme edge cases doing unlikely processing for the typical website :B Have you seen some of the advanced websites kicked out by design companies? Also consider the sites that get stuck on shared servers with 1000's of sites per machine using database servers with 1000's of DBs where limiting your resource usage can become the difference between a snappy site and one that nobody will use! And then try convincing your local plumber that it's worth paying more than £2 a month for their hosting! Actually, scrap that. It's usually the design company that's overloading their dedicated server, the plumber is then stuck paying £25+ a month + content change charges when they don't know any better. Anyways, where can I get a coder badge, they sound cool!! ;) I just draw one with a pen on my chest to show interviewers. So far it really hasn't worked out well but I've narrowed the problem down to the following four possibilities: 1. they don't like to see my pudgy body when I take my shirt off to show it off 2. they're blinded by the light... my glowing white northern European complexion exacerbated by flourescent office lighting 3. they're not impressed enough with my ball point pen artwork 4. lack of industry adoption So far I'm leaning towards a combination of 1 and 2 ;) Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings [EMAIL PROTECTED] wrote: 4. lack of industry adoption There needs to be some sort of expensive test to certify one may wear the badge. Then it will have higher adoption rates. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On 19 Sep 2008, at 19:50, Robert Cummings wrote: On Fri, 2008-09-19 at 19:32 +0100, Stut wrote: Anyways, where can I get a coder badge, they sound cool!! ;) I just draw one with a pen on my chest to show interviewers. So far it really hasn't worked out well but I've narrowed the problem down to the following four possibilities: 1. they don't like to see my pudgy body when I take my shirt off to show it off I'll take your word for that! 2. they're blinded by the light... my glowing white northern European complexion exacerbated by flourescent office lighting Yeah, I'm gonna ignore that one too. 3. they're not impressed enough with my ball point pen artwork Possible. I've always found it difficult to draw on myself in the mirror. 4. lack of industry adoption This one sounds like a winner. In my experience employers don't assign any importance to non-standard qualifications, even if they are hand- drawn badges. So far I'm leaning towards a combination of 1 and 2 ;) Yeah, probably 1 more than 2. This makes me wonder if there really are any idiots out there who've had the PHP logo tattooed somewhere on their person. Scary thought. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On Sep 19, 2008, at 1:12 PM, Stut wrote: On 19 Sep 2008, at 18:47, Philip Thompson wrote: I've narrowed it down to 10 initial queries... 1. Grab system config data (that's used in lots of places) Does it change often? No? Then cache it in a PHP script. Use var_export to create a file that you can include which will create the configuration array. Alternatively cache it in a Memcache instance which is where my system-wide config usually lives. 2. Grab session data (for SESSION array) Meaning what? You say below that this is after the initial session load. What are you loading here and why is it being loaded on every page request if it's ending up in the $_SESSION array? 3. Grab page id What does this do, how is it used, is it needed? 4. Grab user privs IMHO you should only grab these when you need them. 5. Grab user session (for application) Again, why isn't this already in $_SESSION for every page request expect the first per visit? 6. Begin transaction 7. Lock user session row 8. Update user session 9. Commit transaction If all you're doing is issuing an update command there is no need to do so in a transaction and definitely no need to lock the row. An update is atomic. Maybe what you actually mean to do here is lock it before you get the session data, make changes to it and then unlock it once you're done changing it. Doing that would likely keep the row locked for the entire duration of a request which can start causing problems as traffic increases. 10. Add page tracking (an insert-only table that keeps track of pages you visit) I handle this using files and then have an offline processor to push that data into the database. If all you're doing is adding a row to the table you probably don't need this, but we do a fair amount of work for each page view to record the data in a set of tables designed for meaningful and speedy retrieval. Note that these are the 10 queries that happen after the initial SESSION load. I supposed I could reduce this by 1 or 2 queries - I could store the page id/information in the session. Now with that said, the queries are negligible (in elapsed time) and required. However, I'm always open up to suggestions/improvements =D You may think they're required, but I'm betting they're not if you really think about it. However, if your DB can handle it then why fix something that ain't broken. The way I approach this stuff is always with the knowledge that the database is the most expensive resource in the infrastructure, so anything I can do to avoid using it when it's not strictly necessary is something I consider well-worth the effort. With the rise of frameworks and the lazy architectures it's pretty common to end up with this mass of DB access at the start of each request, but it won't scale and it leads to assumptions that are extremely expensive to find and fix when you do need to scale. Trust me, I've been there many times and it's been painful every time! Oh, and by scale I don't necessarily mean to tens of millions of page views a month. Scalability is as much about going from 10 visitor a day to 1000 as it is from 1000 to several million. -Stut Robert/Stut, Thanks for your words of wisdom. ;) I will take what you've said back to my team for us to discuss. That's why I like this list - allows me to view the problem(s) from a different angle, or two. ;) ~Philip -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
At 3:11 PM -0400 9/19/08, Eric Butera wrote: On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings [EMAIL PROTECTED] wrote: 4. lack of industry adoption There needs to be some sort of expensive test to certify one may wear the badge. Then it will have higher adoption rates. I can modify this: http://webbytedd.com/bb/pdf/ Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On Fri, 2008-09-19 at 16:15 -0400, tedd wrote: At 3:11 PM -0400 9/19/08, Eric Butera wrote: On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings [EMAIL PROTECTED] wrote: 4. lack of industry adoption There needs to be some sort of expensive test to certify one may wear the badge. Then it will have higher adoption rates. I can modify this: http://webbytedd.com/bb/pdf/ He said EXPENSIVE you insensitive clod! Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On 19 Sep 2008, at 21:22, Robert Cummings wrote: On Fri, 2008-09-19 at 16:15 -0400, tedd wrote: At 3:11 PM -0400 9/19/08, Eric Butera wrote: On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings [EMAIL PROTECTED] wrote: 4. lack of industry adoption There needs to be some sort of expensive test to certify one may wear the badge. Then it will have higher adoption rates. I can modify this: http://webbytedd.com/bb/pdf/ He said EXPENSIVE you insensitive clod! Ahh, mood swings from ink poisoning? Tedd: Charge $100 per certificate, Rob'll buy one, maybe even two!! I've managed to avoid getting the Zend certification until now despite many many people trying to convince me it's worth it. As both an employee and an employer I just don't see the value. The last practice tests I saw were primarily memory tests - that's not a useful measure in my book. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On Fri, Sep 19, 2008 at 4:31 PM, Stut [EMAIL PROTECTED] wrote: On 19 Sep 2008, at 21:22, Robert Cummings wrote: On Fri, 2008-09-19 at 16:15 -0400, tedd wrote: At 3:11 PM -0400 9/19/08, Eric Butera wrote: On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings [EMAIL PROTECTED] wrote: 4. lack of industry adoption There needs to be some sort of expensive test to certify one may wear the badge. Then it will have higher adoption rates. I can modify this: http://webbytedd.com/bb/pdf/ He said EXPENSIVE you insensitive clod! Ahh, mood swings from ink poisoning? Tedd: Charge $100 per certificate, Rob'll buy one, maybe even two!! I've managed to avoid getting the Zend certification until now despite many many people trying to convince me it's worth it. As both an employee and an employer I just don't see the value. The last practice tests I saw were primarily memory tests - that's not a useful measure in my book. -Stut -- http://stut.net/ Bingo. :) I can search php.net/func in 5 seconds to know the odd param order of some string function if I forget. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
I have more questions/responses throughout... On Sep 19, 2008, at 1:12 PM, Stut wrote: On 19 Sep 2008, at 18:47, Philip Thompson wrote: I've narrowed it down to 10 initial queries... 1. Grab system config data (that's used in lots of places) Does it change often? No? Then cache it in a PHP script. Use var_export to create a file that you can include which will create the configuration array. Alternatively cache it in a Memcache instance which is where my system-wide config usually lives. Good idea. 2. Grab session data (for SESSION array) Meaning what? You say below that this is after the initial session load. What are you loading here and why is it being loaded on every page request if it's ending up in the $_SESSION array? Because I'm using your class, Stut, (at least as a reference) to store my sessions in the database. Hence, I have to pull them from the database. 3. Grab page id What does this do, how is it used, is it needed? I was able to add this to the SESSION. 4. Grab user privs IMHO you should only grab these when you need them. I will need these on most pages anyway. Because of the architecture, the security class (which uses these a lot) is a separate part. 5. Grab user session (for application) Again, why isn't this already in $_SESSION for every page request expect the first per visit? This user session deals with merely keeping up with the time - how long has it been since this user accessed the site? Keep logged in? Logged in elsewhere? This uses the db and cookies. Note, this was designed into the app from the beginning... using the _SESSION var is new to the app as of this week. Yes, we can probably move this functionality into the new _SESSION stuff 6. Begin transaction 7. Lock user session row 8. Update user session 9. Commit transaction If all you're doing is issuing an update command there is no need to do so in a transaction and definitely no need to lock the row. An update is atomic. Maybe what you actually mean to do here is lock it before you get the session data, make changes to it and then unlock it once you're done changing it. Doing that would likely keep the row locked for the entire duration of a request which can start causing problems as traffic increases. I'm starting the transaction because MySQL SELECT... FOR UPDATE requires a transaction to lock the row. But now that I think about it... the reason we use the lock is so that we don't have collisions in data - specifically here the user session. However, the user session row is only accessed by a single user (his/her own). And since they can only be logged in at one location, there's virtually no way for a collision. Right? I can remove queries 6, 7, and 9, right? 10. Add page tracking (an insert-only table that keeps track of pages you visit) I handle this using files and then have an offline processor to push that data into the database. If all you're doing is adding a row to the table you probably don't need this, but we do a fair amount of work for each page view to record the data in a set of tables designed for meaningful and speedy retrieval. Note that these are the 10 queries that happen after the initial SESSION load. I supposed I could reduce this by 1 or 2 queries - I could store the page id/information in the session. Now with that said, the queries are negligible (in elapsed time) and required. However, I'm always open up to suggestions/improvements =D You may think they're required, but I'm betting they're not if you really think about it. However, if your DB can handle it then why fix something that ain't broken. It can handle it now. But I'm not worried about now. We have less than 10 clients/offices using the app. This may grow up to 100 within the next year. That's when there's gonna be lots and lots of data and we may start to see a slow down. The way I approach this stuff is always with the knowledge that the database is the most expensive resource in the infrastructure, so anything I can do to avoid using it when it's not strictly necessary is something I consider well-worth the effort. With the rise of frameworks and the lazy architectures it's pretty common to end up with this mass of DB access at the start of each request, but it won't scale and it leads to assumptions that are extremely expensive to find and fix when you do need to scale. Trust me, I've been there many times and it's been painful every time! Can you explain why it won't scale and may lead to assumptions? Oh, and by scale I don't necessarily mean to tens of millions of page views a month. Scalability is as much about going from 10 visitor a day to 1000 as it is from 1000 to several million. -Stut Thanks, ~Philip -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
Time's off by an hour :) I could have my graphic designer whip something up hehee :) On Sep 19, 2008, at 4:15 PM, tedd wrote: At 3:11 PM -0400 9/19/08, Eric Butera wrote: On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings [EMAIL PROTECTED] wrote: 4. lack of industry adoption There needs to be some sort of expensive test to certify one may wear the badge. Then it will have higher adoption rates. I can modify this: http://webbytedd.com/bb/pdf/ Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- 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] SESSIONS vs. MySQL
On Fri, 2008-09-19 at 21:31 +0100, Stut wrote: I can modify this: http://webbytedd.com/bb/pdf/ He said EXPENSIVE you insensitive clod! Ahh, mood swings from ink poisoning? Tedd: Charge $100 per certificate, Rob'll buy one, maybe even two!! I've managed to avoid getting the Zend certification until now despite many many people trying to convince me it's worth it. As both an employee and an employer I just don't see the value. The last practice tests I saw were primarily memory tests - that's not a useful measure in my book. I'm also in the camp of avoiding getting Zend certification. As you point out, it's merely a test on memorization of simple (and occasionally obscure) language constructs. It's hardly an example of how a person thinks, tackles problems, and can effectively develop solutions. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SESSIONS vs. MySQL
On 19 Sep 2008, at 21:44, Philip Thompson wrote: On Sep 19, 2008, at 1:12 PM, Stut wrote: On 19 Sep 2008, at 18:47, Philip Thompson wrote: 4. Grab user privs IMHO you should only grab these when you need them. I will need these on most pages anyway. Because of the architecture, the security class (which uses these a lot) is a separate part. Fair enough, but I would suggest this is an ideal candidate for being kept in the session. 5. Grab user session (for application) Again, why isn't this already in $_SESSION for every page request expect the first per visit? This user session deals with merely keeping up with the time - how long has it been since this user accessed the site? Keep logged in? Logged in elsewhere? This uses the db and cookies. Note, this was designed into the app from the beginning... using the _SESSION var is new to the app as of this week. Yes, we can probably move this functionality into the new _SESSION stuff Sounds like a lot of work for little benefit, but it sounds like it might be hard to remove so I'd probably live with it for a while too. 6. Begin transaction 7. Lock user session row 8. Update user session 9. Commit transaction If all you're doing is issuing an update command there is no need to do so in a transaction and definitely no need to lock the row. An update is atomic. Maybe what you actually mean to do here is lock it before you get the session data, make changes to it and then unlock it once you're done changing it. Doing that would likely keep the row locked for the entire duration of a request which can start causing problems as traffic increases. I'm starting the transaction because MySQL SELECT... FOR UPDATE requires a transaction to lock the row. But now that I think about it... the reason we use the lock is so that we don't have collisions in data - specifically here the user session. However, the user session row is only accessed by a single user (his/her own). And since they can only be logged in at one location, there's virtually no way for a collision. Right? I can remove queries 6, 7, and 9, right? Yes, you only need the update statement. Note that these are the 10 queries that happen after the initial SESSION load. I supposed I could reduce this by 1 or 2 queries - I could store the page id/information in the session. Now with that said, the queries are negligible (in elapsed time) and required. However, I'm always open up to suggestions/improvements =D You may think they're required, but I'm betting they're not if you really think about it. However, if your DB can handle it then why fix something that ain't broken. It can handle it now. But I'm not worried about now. We have less than 10 clients/offices using the app. This may grow up to 100 within the next year. That's when there's gonna be lots and lots of data and we may start to see a slow down. That's not even close to a large number of users, but it depends a lot on what else the servers you're hosting it on are being used for. The way I approach this stuff is always with the knowledge that the database is the most expensive resource in the infrastructure, so anything I can do to avoid using it when it's not strictly necessary is something I consider well-worth the effort. With the rise of frameworks and the lazy architectures it's pretty common to end up with this mass of DB access at the start of each request, but it won't scale and it leads to assumptions that are extremely expensive to find and fix when you do need to scale. Trust me, I've been there many times and it's been painful every time! Can you explain why it won't scale and may lead to assumptions? Sure. With an architecture like this you start to assume that X is available anywhere in your code because at the moment you know the framework loads it for you. This makes it exceedingly difficult to strip the initialisation code down if you end up needing to optimise the crap out of it. As far as scaling goes you're placing all the load on the database so if you get to a stage where you can no longer vertically scale the DB hardware you're left with a major rewrite of your entire codebase to allow it to scale horizontally. It's possible that your app is capable of being sharded across multiple servers but chances are that's still going to take major surgery to achieve. Some on the list may have noticed I'm a bit anal about scalability issues, but it's only because I've inherited several systems now that were never designed with scalability in mind and I ended up almost completely rewriting each one. Every new site I develop now is built so it's modular, can spread across multiple servers if/when needed and doesn't waste resources. No doubt most web developers never hit these problems, but I guess I've just been unlucky in that respect. -Stut -- http://stut.net/ -- PHP
Re: [PHP] SESSIONS vs. MySQL
On Sep 19, 2008, at 4:01 PM, Stut wrote: On 19 Sep 2008, at 21:44, Philip Thompson wrote: On Sep 19, 2008, at 1:12 PM, Stut wrote: On 19 Sep 2008, at 18:47, Philip Thompson wrote: 4. Grab user privs IMHO you should only grab these when you need them. I will need these on most pages anyway. Because of the architecture, the security class (which uses these a lot) is a separate part. Fair enough, but I would suggest this is an ideal candidate for being kept in the session. Yes, I agree - these can prob be moved into the session. 5. Grab user session (for application) Again, why isn't this already in $_SESSION for every page request expect the first per visit? This user session deals with merely keeping up with the time - how long has it been since this user accessed the site? Keep logged in? Logged in elsewhere? This uses the db and cookies. Note, this was designed into the app from the beginning... using the _SESSION var is new to the app as of this week. Yes, we can probably move this functionality into the new _SESSION stuff Sounds like a lot of work for little benefit, but it sounds like it might be hard to remove so I'd probably live with it for a while too. It may be some work... but it doesn't make sense to have session stuff in two different places. (I inherited this architecture, so I've been limited as to what I can do to some extent.) The question I have to ask myself now... will it be worth it in the future to have moved the session stuff to 1 class now? And do I have the time/resources to? =D 6. Begin transaction 7. Lock user session row 8. Update user session 9. Commit transaction If all you're doing is issuing an update command there is no need to do so in a transaction and definitely no need to lock the row. An update is atomic. Maybe what you actually mean to do here is lock it before you get the session data, make changes to it and then unlock it once you're done changing it. Doing that would likely keep the row locked for the entire duration of a request which can start causing problems as traffic increases. I'm starting the transaction because MySQL SELECT... FOR UPDATE requires a transaction to lock the row. But now that I think about it... the reason we use the lock is so that we don't have collisions in data - specifically here the user session. However, the user session row is only accessed by a single user (his/her own). And since they can only be logged in at one location, there's virtually no way for a collision. Right? I can remove queries 6, 7, and 9, right? Yes, you only need the update statement. Ok, here, only the update is needed. But for other locations where multiple users may be accessing the same record, I should lock it. Note that these are the 10 queries that happen after the initial SESSION load. I supposed I could reduce this by 1 or 2 queries - I could store the page id/information in the session. Now with that said, the queries are negligible (in elapsed time) and required. However, I'm always open up to suggestions/improvements =D You may think they're required, but I'm betting they're not if you really think about it. However, if your DB can handle it then why fix something that ain't broken. It can handle it now. But I'm not worried about now. We have less than 10 clients/offices using the app. This may grow up to 100 within the next year. That's when there's gonna be lots and lots of data and we may start to see a slow down. That's not even close to a large number of users, but it depends a lot on what else the servers you're hosting it on are being used for. A client may have 1 user or 50 users. It's not the user-size I'm concerned about. This software is for doctor's offices. So, last week when we had our first import from another practice management system (aptly acronym'd, PMS), our patient records jumped from about 1,000 to 65,000. That's just 1 client! Now, I still know that's not a whole lot, but multiply that by 100 clients in the next year: 64000 * 100 = 6.4 million patient records. That's more of a significant number. We're using a dedicated server that hosts the website and the database. I *know* we're going to need to expand... but that's beyond my control as a mere pawn. As of today, it's okay. The way I approach this stuff is always with the knowledge that the database is the most expensive resource in the infrastructure, so anything I can do to avoid using it when it's not strictly necessary is something I consider well-worth the effort. With the rise of frameworks and the lazy architectures it's pretty common to end up with this mass of DB access at the start of each request, but it won't scale and it leads to assumptions that are extremely expensive to find and fix when you do need to scale. Trust me, I've been there many times and it's been painful every time! Can you
Re: [PHP] SESSIONS vs. MySQL
On 19 Sep 2008, at 22:33, Philip Thompson wrote: On Sep 19, 2008, at 4:01 PM, Stut wrote: On 19 Sep 2008, at 21:44, Philip Thompson wrote: On Sep 19, 2008, at 1:12 PM, Stut wrote: On 19 Sep 2008, at 18:47, Philip Thompson wrote: 6. Begin transaction 7. Lock user session row 8. Update user session 9. Commit transaction If all you're doing is issuing an update command there is no need to do so in a transaction and definitely no need to lock the row. An update is atomic. Maybe what you actually mean to do here is lock it before you get the session data, make changes to it and then unlock it once you're done changing it. Doing that would likely keep the row locked for the entire duration of a request which can start causing problems as traffic increases. I'm starting the transaction because MySQL SELECT... FOR UPDATE requires a transaction to lock the row. But now that I think about it... the reason we use the lock is so that we don't have collisions in data - specifically here the user session. However, the user session row is only accessed by a single user (his/her own). And since they can only be logged in at one location, there's virtually no way for a collision. Right? I can remove queries 6, 7, and 9, right? Yes, you only need the update statement. Ok, here, only the update is needed. But for other locations where multiple users may be accessing the same record, I should lock it. Yes and no. If all you're going to do while it's locked is issue the update statement then it's pointless. However, if you need to prevent anyone from updating the row from when you read it to when you write it back then you need to lock it for the duration. Note that these are the 10 queries that happen after the initial SESSION load. I supposed I could reduce this by 1 or 2 queries - I could store the page id/information in the session. Now with that said, the queries are negligible (in elapsed time) and required. However, I'm always open up to suggestions/improvements =D You may think they're required, but I'm betting they're not if you really think about it. However, if your DB can handle it then why fix something that ain't broken. It can handle it now. But I'm not worried about now. We have less than 10 clients/offices using the app. This may grow up to 100 within the next year. That's when there's gonna be lots and lots of data and we may start to see a slow down. That's not even close to a large number of users, but it depends a lot on what else the servers you're hosting it on are being used for. A client may have 1 user or 50 users. It's not the user-size I'm concerned about. This software is for doctor's offices. So, last week when we had our first import from another practice management system (aptly acronym'd, PMS), our patient records jumped from about 1,000 to 65,000. That's just 1 client! Now, I still know that's not a whole lot, but multiply that by 100 clients in the next year: 64000 * 100 = 6.4 million patient records. That's more of a significant number. Not particularly, and to be honest the traffic to the site will be your problem, not the number of users or records stored on it. Queries can always be optimised but the architecture of the site is harder and more expensive to change. We're using a dedicated server that hosts the website and the database. I *know* we're going to need to expand... but that's beyond my control as a mere pawn. As of today, it's okay. Sounds like you've got an easy sharding option so you should be ok. Once you outgrow that single server it should be pretty simple to put a redirector on to a main server which will redirect after login to another server (shard) which contains all the data for that client. This is commonly the easiest sharding scenario to implement but it only works so long as a single client doesn't outgrow a single server. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions vs MySQL
Alberto García Gómez wrote: I'm seeking for some class to work with sessions against a mysql DB, please examples are welcome. http://php.stut.net/104-mysql_sessions.html -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Sessions vs MySQL
I'm seeking for some class to work with sessions against a mysql DB, please examples are welcome. Este correo ha sido enviado desde el Politécnico de Informática Carlos Marx de Matanzas. La gran batalla se librará en el campo de las ideas -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Sessions VS MySQL
I've recently begun work on a web-based RPG game with some friends, and have recently been thinking about the best solution for loading and saving persistent variables like player life/stats and other information. I am both familiar with sessions and mysql for saving and loading variables, and that's not my question, but I am instead interested in which method would be more efficient to use. If the data is getting reloaded on each individual page, would it be more efficient on the system hosting the game to save certain numbers and variables in a session, or to reaccess the database each time it needs those numbers. My biggest concern with using sessions, is if someone were to exit the browser mid saves to the database, all information would be lost. Since it is web-based, there is no real way for me to be able to expect everyone to follow certain procedures to load/save, and I would really like to stay away from that as well, as it's not as user-friendly and intuitive as an auto-save feature. I guess my main question here is, are there ways to auto-save and guarantee data wouldn't be lost without having to load, read, write, and close a connection to mysql on each page load? I appreciate any tips, insight, thoughts, stories, or help in absolutely any fashion that I can get. Even a tip of a nature outside my question related to my project would be great. it's my first project of this kind, and I'd like to avoid any problems I can, so I'm putting a lot of forethought into it all. Also, I'm the only coder, so to have to go back and rewrite a ton of code from one save method to another is just way too much work.
Re: [PHP] Sessions VS MySQL
On Wed, May 30, 2007 4:00 am, Matt Fielding wrote: I've recently begun work on a web-based RPG game with some friends, and have recently been thinking about the best solution for loading and saving persistent variables like player life/stats and other information. I am both familiar with sessions and mysql for saving and loading variables, and that's not my question, but I am instead interested in which method would be more efficient to use. If the data is getting reloaded on each individual page, would it be more efficient on the system hosting the game to save certain numbers and variables in a session, or to reaccess the database each time it needs those numbers. My biggest concern with using sessions, is if someone were to exit the browser mid saves to the database, all information would be lost. Since it is web-based, there is no real way for me to be able to expect everyone to follow certain procedures to load/save, and I would really like to stay away from that as well, as it's not as user-friendly and intuitive as an auto-save feature. I guess my main question here is, are there ways to auto-save and guarantee data wouldn't be lost without having to load, read, write, and close a connection to mysql on each page load? I appreciate any tips, insight, thoughts, stories, or help in absolutely any fashion that I can get. Even a tip of a nature outside my question related to my project would be great. it's my first project of this kind, and I'd like to avoid any problems I can, so I'm putting a lot of forethought into it all. Also, I'm the only coder, so to have to go back and rewrite a ton of code from one save method to another is just way too much work. There are several approaches you could take, and you may even want to consider a mix of approaches. The first question is how much this has to scale, and how much data is stored per user? Becuase if you need a Meg per user and expect to scale out to XBox, then you've got a very different problem than if you expect you and your 10 buddies to be playing this RPG for years on end, but that's about it... You may want to classify data into broad buckets such as: Transient Data - store it in the cookie value Active Data - store it in session Permanent Data - auto-save to database Background Data - the game state as opposed to the individual user state You might choose to auto-save at certain mile-markers, such as every time the player gains an experience point, or achieves a specific goal in the game, or both. (Got the key, rescued the princess, whatever) Probably be best to have a simple save function to call, and call it as often as needed. You may also need to consider solving a Race Condition within the saved states -- At some point, you have to purge a saved state if a user is gone long emough and the others had to move forward... Either that, or suddenly both Biblo *and* Gandalf has the key and your game is all messed up... There may be some OpenSource RPG engines you could research, or even link in to PHP as a custom extension -- or throw it into PECL if enough users want to write RPGs in PHP :-) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie 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] Sessions VS MySQL
As far as scalability goes, there's actually a game we're referencing a lot to help us make it work at the get go called Kingdom of Loathing ( http://www.kingdomofloathing.com ). This game seems to have on average around 1,000-1,500 users on at any given time. I've noticed when visiting the page also, that is sends you to a random mirror of the site such as www2..., www3..., etc.. I'm not sure if those shows that it's directing people to various servers for the website, and that the database is possibly stored on one server by itself. This seems a bit bulky a solution for an online text/2d low res image rpg game, even with 1,000 users playing simultaneously. The point of saving only when I need to I get, and was planning to implement. Such things as exploring around the game world, and, well, that's all really, don't need to be saved as you'll start at the main location each time you log in, but other things like battle, buying/selling/upgrading items and inventory, and quest locations on the map, all need to be saved. I guess one of my bigger concerns about saving is if it would seem natural or strange to have it only save after the end of each battle, because the way the battle system is planned to work is that you attack, it loads the page, says how much dmg you did and the enemy did, then you may have to attack again, loading the page howveer many more times is needed until you die, or the enemy dies. There will be a function to run built in, but aside from that the only other way to get out is to exit the browser. It seems a bit cumbersome to have to access the db everytime an attack takes place, but at the same time the player will be limited to a number of moves per day, to make the game more fun, and help the server from dying. From what I recall, mysql database calls take only .002 seconds, or something very quick like that, so I suppose I shouldn't be too worried about the database overloading from people using it, or should I? That's really one of my main concerns. Anyways, thanks for all the help and input so far, it's greatly appreciated.
[PHP] Sessions vs. MySQL records?
I have an application where I want users to only be allowed 5 searches per day unless they create an account. There may not be a simple answer to this, but in general, would it be preferred to do this with 24-hour session variables, or by writing a MySQL record for each visitor with the date and their IP address and tracking their usage count? Thanks in advance for any thoughts. - Brian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions vs. MySQL records?
On Wednesday 04 February 2004 00:05, Brian Dunning wrote: I have an application where I want users to only be allowed 5 searches per day unless they create an account. Unless you require that a user logs in before they can perform a search then there is no meaningful way to track how many searches they have performed. There may not be a simple answer to this, but in general, would it be preferred to do this with 24-hour session variables, or by writing a MySQL record for each visitor with the date and their IP address and tracking their usage count? Never use an IP address as a unique identifier unless you're in a closed network environment under your control. -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * -- Search the list archives before you post http://marc.theaimsgroup.com/?l=php-general -- /* Good news. Ten weeks from Friday will be a pretty good day. */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions vs. MySQL records?
Hi, By sessions i assume you mean cookies (session information can be stored in other places such as a mysql database). If you do store the information in a cookie, your visitors can easily delete the cooky and get past your protection mechanism. Having said that opting for a mysql table that stores IP information isn't good enough either. Most dialup and ADSL users have dynamic IPs. So they may also get past your restrictions. Your best best would be to have a password protected website and limit the number of searchs per user based on userid. all the best. Brian Dunning wrote: I have an application where I want users to only be allowed 5 searches per day unless they create an account. There may not be a simple answer to this, but in general, would it be preferred to do this with 24-hour session variables, or by writing a MySQL record for each visitor with the date and their IP address and tracking their usage count? Thanks in advance for any thoughts. - Brian -- Raditha Dissanayake. http://www.radinks.com/sftp/ | http://www.raditha.com/megaupload Lean and mean Secure FTP applet with | Mega Upload - PHP file uploader Graphical User Inteface. Just 150 KB | with progress bar. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions vs. MySQL records?
On Tue, 2004-02-03 at 11:05, Brian Dunning wrote: I have an application where I want users to only be allowed 5 searches per day unless they create an account. There may not be a simple answer to this, but in general, would it be preferred to do this with 24-hour session variables, or by writing a MySQL record for each visitor with the date and their IP address and tracking their usage count? This is one of those tricky problems with web applications. If you rely on sessions then they can just delete the cookie and start over. If you use IP address than people can either disconnect and reconnect. Or even worse if someone gets an IP from their isp someone else already used on your site then they won't be able to do even one search. Lastly, If you have them create a 'basic' account so you can track it they can just create as many accounts as they want. Armed with that knowledge I would suggest the following: First of all, forget IP addresses. They are not reliable enough to assume that multiple requests from the same IP are the same person, especially if you are targeting business customers. Using a non-authenticated session is an easy way to solve your problem, however it will be *dead* simple to get around - switch browsers or delete your cookies. If your searches are relevant to each other (the second search uses session information from the first search, etc.) then this may be more useful since the only way around this is to destroy the session, effectively starting over. Lastly, using basic user accounts (just a username, password, and e-mail) would be your best solution. Granted someone can create 50 yahoo accounts and sign up 50 times. However, the cost to them of creating those accounts, maintaining 50 accounts on your site, and having to log-out and back in every 5 searches may be enough to convince them to pay you instead. Good Luck, Adam P.S. Should you find a 'magic' bullet to the web authentication problem please let all of us know! -- Adam Bregenzer [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] sessions and mysql: easy question
i'm using session on my page basically my need is this: certain values wil be set for every visitor some for only certain visitors (for example: only if they fill out their nameadress) when the session is closed i want the ones that have those values filled out (let's say their nameaddress) stored in a mysql-table i have 2 ideas: * only storing the ones needed in a mysql-table because of a lot of traffic and variables and places where they can modify them, i'd prefer to store all of it at closing the session: is this possible?? (since i don't have control on when they close the session: is it possible to have php run a mysql-query after their browser is closed, with their inserted data?) * storing all the sessions in a mysql-table, deleting the ones that aren't relevant pretty much the same question: how can I check on their variables after they've closed the session, and delete their record if needed? does this make sense? any other suggestions? anything most welcome grace michiel -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] sessions and mysql
We recently upgraded to php4.1.0 from 4.0.6 and now our custom session
handling doesn't work! We are running on linux with apache, attempting to
save session info to a MySQL database (I have session.save_handler=user).
There are a couple issues:
1) Occassionally (can't seem to pin down exactly when) I try and access my
site and get a The page cannot be displayed error in IE.
a. The session_start() command seems to be causing this error - If i put
die(here); before session_start(), I see the message. If I move
die(here); after session_start(), I get the error.
b. Clicking refresh (sometimes 1 time, sometimes 10 times) will
eventually allow me to access my page.
2) When I access my page, I attempt to set a session variable
($_SESSION[foo] = bar;). When the page finishes loading the first time,
the session write handler is called which puts the session information in
the database. However, there is nothing written to the value field! (It's
still blank!) foo was never registered.
a. If I refresh the page, the session information is updated in the
database, and now the value field has the correct entry (foo|s:3:bar;)
My session save handler is based on a
href=http://www.onlamp.com/pub/a/php/2001/05/10/sessions.html?page=2;this
article/a I read:
I'm attaching a copy of my sesssions.php file in case that will help anyone.
The only modifications I made were to the read handler - I put in a return
of the value from the SELECT. If I take that statement out, problem 1) goes
away, but I would NEVER get session information saved into the database!??!
(only the SessionID would be stored)
Did something change in session handling from 4.0.6 to 4.1.0? If I can't
figure this out, we have no choice but to roll back to 4.0.6, but I really
love the security additions of 4.1.0 - Help!!! MUCH THANKS IN ADVANCE.
John
begin 666 sessions.php.txt
M/#]P:' -@T*+RH-BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BH-BHJ#0HJ*@E.86UE.B!T96UP;%T92YP:' -BHJ#0HJ*@E!
M=71H;W(Z($-OGD@1F%C=]R#0HJ*@T**BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*@T**B\-@T*+R\@5AEV4@=F%R:6%B;5S
M(%R92!S970@:6X@=AE(1A=%B87-E7W-E='1I;F=S+G!H!F:6QE#0HO
M+R!W:EC:!IR!I;F-L=61E9!UVEN9R!T:4@875T;U]PF5P96YD7V9I
M;4@4$A0(-O;F9I9W5R871I;VX-B\O#0HD4T534U]$0DA/4U0@/2 D1VQO
M8F%L7T12$]35#L)2\J(1A=%B87-E('-EG9EB!H;W-T;F%M92 J+PT*
M)%-%4U-?1$).04U%(#T@)$=L;V)A;%]$0DY!344[0DO*B!D871A8F%S92!N
M86UE(HO#0HD4T534U]$0E5315(@/2 D1VQO8F%L7T155-%4CL)2\J(1A
M=%B87-E('5S97(@*B\-B1315-37T14$%34R ](1';]B86Q?1$)005-3
M.PD)+RH@9%T86)AV4@%SW=OF0@*B\-B\O#0HO+R!%;F0@;V8@875T
M;U]PF5P96YD7V9I;4@=F%R:6%B;5S#0H-@T*)%-%4U-?5$%3$4@/2 B
MV5SVEO;G,B.PT*)%-%4U-?3$E12 ](=E=%]C9F=?=F%R*)S97-S:6]N
M+F=C7VUAQI9F5T:6UE(BD[#0HD4T534U]$0B ]((B.PT*#0HO*@T*')I
M;G0H(FAOW0Z(1315-37T12$]35#QBCXB*3L-G!R:6YT*)N86UE.B D
M4T534U]$0DY!344\8G(^(BD[#0IPFEN=@B=7-ECH@)%-%4U-?1$)54T52
M/)R/B(I.PT*')I;G0H(G!AW,Z(1315-37T14$%34SQBCXB*3L-G!R
M:6YT*)S97-S:60Z(102%!315-3240\8G(^(BD[#0IPFEN=@B;EF93H@
M)%-%4U-?3$E13QBCXB*3L-B\O9EE*D[#0HJ+PT*#0IF=6YC=EO;B!S
M97-S7V]P96XH)'-A=F5?%T:P@)'-EW-I;VY?;F%M92D@PT*6=L;V)A
M; D4T534U]$0DA/4U0L(1315-37T155-%4BP@)%-%4U-?1$)005-3+ D
M4T534U]$0DY!344L(1315-37T1.PT*#0H):68@* A;7ES6Q?-O;FYE
M8W0H)%-%4U-?1$)(3U-4+ D4T534U]$0E5315(L(1315-37T14$%34RDI
M('L-@D)96-H;R B/QI/D-A;B=T(-O;FYE8W0@=\@)%-%4U-?1$)(3U-4
M(%S(1315-37T155-%4B([#0H)65C:\@(CQL:3Y-5-13!%G)OCH@
M(BP@;7ES6Q?97)R;W(H*3L-@D)9EE.PT*7T-@EI9B H($@;7ES6Q?
MV5L96-T7V1B*1315-37T13D%-12DI('L-@D)96-H;R B/QI/E5N86)L
M92!T;R!S96QE8W0@9%T86)AV4@)%-%4U-?1$).04U%(CL-@D)9EE.PT*
M7T-GT-@T*9G5N8W1I;VX@V5SU]C;]S92@I('L-@ER971UFX@=')U
M93L-GT-@T*9G5N8W1I;VX@V5SU]R96%D*13240I('L-@EG;]B86P@
M)%-%4U-?1$(L(1315-37U1!0DQ%.PT*#0H))'%R2 ]()314Q%0U0@=F%L
M=64@1E)/32 D4T534U]404),12!72$5212!S97-S:V5Y(#T@)R13240G($%.
M1!E'!IGD@/B B(X@=[EMAIL PROTECTED]*21R97-U;'0@/2!M7-Q;%]Q=65R
M2@D7)Y*3L-@T*#0H):68@*QIW0H)'9A;'5E*2 ](UYW%L7V9E=-H
M7W)O=R@DF5S=6QT*2D@PT*0ER971UFX@)'9A;'5E.PT*7T-GT-@T*
M9G5N8W1I;VX@V5SU]WFET92@D4TE$+ D=F%L*2![#0H)9VQO8F%L(13
M15-37T1+ D4T534U]404),12P@)%-%4U-?3$E13L-@T*21E'!IGD@
M/2!T:6UE*D@*R D4T534U],249%.PT*0T*21QGD@/2 B24Y315)4($E.
M5$\@)%-%4U-?5$%3$4@5D%,5453(@G)%-)1L(D97AP:7)Y)RP@)R1V
M86QU92I(CL-@DDF5S=6QT(#T@;7ES6Q?75EGDH)'%R2D[#0H-@EI
M9B H(2 DF5S=6QT*2R!!3D0@97AP:7)Y(#X@(B N('1I;64H*3L-
M@D))')EW5L= ](UYW%L7W%U97)Y*1QGDI.PT*7T-GT-@T*9G5N
M8W1I;VX@V5SU]D97-TF]Y*13240I('L-@EG;]B86P@)%-%4U-?5$%
M3$4[#0H-@DD7)Y(#T@(D1%3$5412!4D]-(1315-37U1!0DQ%(%=(15)%
M('-EW-K97D@/2 G)%-)1B.PT*21R97-U;'0@/2!M7-Q;%]Q=65R2@D
M7)Y*3L-GT-@T*9G5N8W1I;VX@V5SU]G8R@D4T534U],249%*2![#0H)
M9VQO8F%L(1315-37U1!0DQ%.PT*#0H))'%R2 ]()$14Q%5$4@1E)/32 D
M4T534U]404),12!72$5212!E'!IGD@/ B(X@=EM92@I(T@)%-%4U-?
M3$E13L-@DDF5S=6QT(#T@;7ES6Q?75EGDH)'%R2D[#0H-@ER971U
MFX@;7ES6Q?869F96-T961?F]WR@DF5S=6QT*3L-GT-@T*V5SVEO
M;E]S971?V%V95]H86YD;5R* T*2)S97-S7V]P96XB+ T*2)S97-S7V-L
M;W-E(BP-@DBV5SU]R96%D(BP-@DBV5SU]WFET92(L#0H)(G-EW-?
[PHP] Sessions with MySQL
I'm using a MySQL-database to store my session variables by using the following code: session_set_save_handler sess_open, sess_close, sess_read, sess_write, sess_destroy, sess_gc ); session.gc_probability in the php.ini file is set to 1. In a book I read that this means that the function sess_gc will then be call everytime I start a new session by using: session_start(); But the function sess_gc will never be called so my table including the session variables is growing up and never be cleaned. Only if I call the sess_gc function myself the old sessions will be deleted. Do I always have to do this myself or what's wrong with my code? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
