Paginate Processor Load

Sorry for the late reply. I didn't see your post. The forum doesn't always send email notifications when there's new replies...
Anyway, maybe your performance problem has something to do with session locking. If the front-end makes multiple ajax queries at the same time, you can have performance issue where one query is waiting for the session lock to be released. Calling session_write_close() as early as you can, as soon as you no longer need the session data can help with this. Especially while you wait for the database query to return, you probably no longer need session data at this point.

Only MySQL and PostgreSQL databases are officially supported, due to lack of advisory locking mechanisms on other platforms. Using sessions without locks can cause all sorts of problems, especially with heavy usage of AJAX, and we will not support such cases. Use session_write_close() after you’ve done processing session data if you’re having performance issues.

Source: http://codeigniter.com/user_guide/librar...sions.html

That's a good point, thanks includebeer... I do remember reading this a long time ago and making a mental note to keep my eye on it at the time (since this little project is pretty much all Ajax, besides the initial background page load)... of course, in spite of my good intentions, it still managed to quietly slip back into the Ether.

If I recall correctly... and don't quote me on this.. but, when I experimented with session_write_close() at the time, it caused a problem by pretty much completely destroying ALL the user's session data (and signing them out).  I'm using MySQL, so made the mental note, removed all of the session_write_close() references, and left it at that.  I'll put it on a PostIt, so it doesn't drop off the radar again before I get to the point of doing some stress-testing on the site.

What I did find, regarding the processor loading- after a bit of additional experimentation- was that if I accessed the page from a client on another machine (other than the development machine, which had both the server and client on it during my initial tests), it didn't seem to cause a problem... even the 5000x loop, although observable, the increase in load was reasonable, and easily within palatable bounds.  So I ended up attributed the problem to an interaction with, or anomaly in the client-side JavaScript in a very vague, but still all-encompassing, hand-waving conclusion that justified having another glass of whine and moving on (albeit that this phenomenon still hasn't been observed to affect the combined server/client on any other page, even when all the routines are the same ones being invoked for the problem pagination pages (?)).