Also, we'll soon be adding a substantial number of users to our system and I wonder if it would be wise to move away from the table locking that is currently being used with Apache::Session::MySQL.
It would be. Frankly, there is no value to the kind of mutual exclusion that the Apache::Session locking provides in a typical web application. If you use the null locker you will still get atomic updates, but you will have the possibility of someone opening up two browser windows, hitting submit in both, and having the last save overwrite the values from the first one, possibly losing some changes. In most web apps, that is not a big problem.
Note that this could become a problem if you use sessions incorrectly by putting tons of data in them. Most of your data should have its own normalized tables and persistence code. Sessions are for storing tiny little bits of data like the user's ID or some form data that from a multi-page form that hasn't been committed yet.
I'm looking at Apache::Session::Flex and setting "Lock=>'Null'"...however, I get the impression from an old email (see below) that Flex is for debugging only.
If you look at the actual contents of Apache::Session::MySQL, you'll see that it's essentially just a config file. There's no need to be concerned about using Flex, but you could easilly code up your own Apache::Session::MySQLNoLocks by changing a line in the current module.
First, any benchmarks on what kind of load I can realistically use with Apache::Session::MySQL?
It all depends on how much data you put in (lots of data in the session will slow things down) and how fast your database is. At eToys we used a slightly hacked version of Apache::Session::DBI with Oracle and it handled more traffic than most sites will ever see.
- Perrin
