[eluser]Damien K.[/eluser]
If I understand you correctly, you're trying to manage cached pages for authenticated users although your subject suggest otherwise. I'm not sure if this will help you, but I'll throw it out there anyway.
Generally speaking, I find that most protected pages are dynamic thus has little use for caching. Caching the site index page, which is public, may make sense for some website. Say if you do have a need and, for example, you want to show protected blog posts, which rarely changes after it is posted. So one may take the route to cache those posts and recreate the cache upon individual update.
This begs the question: how do you handle authentication in the first place? In order to access any protected url (ie, pages), you will always detect if the user is loggged in. To do this securely, you need to do this on the server side. Other technologies such as Java and .Net handles session data on the application server (database not always required, unless you have a session server because your web/application servers are load balanced), so testing if a user is logged in can be done simply by testing against a flag in the session. However, for PHP/CI you will have your sessions in a database for validation against user cookies. So before you even get to your caching "problem" for protected pages, you will have to test if the user is authenticated/authorized. You cannot skip this test for protected pages hence you will always be hitting the database (to validate the cookie).
For public pages, on the other hand, you can serve the cache page if they're static. If they're dynamic, then there's no point for caching unless you want to refresh the content of the page over a certain period of time, like every 2 hours.
One feature available for "enterprise" technologies is that you can pre-compile the pages, something sort of like caching. You can do something similar to this by creating a cache of all of your pages upon "application start-up". One way to do this is to "visit" all your pages like what a bot would do and that initial visit will trigger a "create_cache()" for each page.
Something tell me that your authentication/authorization tier is not clearly separated from the business logics of your application or at least not "securely" implemented, hence you're running into this "problem". I'm not quite sure what you're asking exactly, so maybe I'm WAY off. But I hope this has help.
Performance is not as high a concern for myself, but many in the community think otherwise. If it is, you probably won't leverage a framework for those certain use cases. Leveraging tools from the developer community usually has some sort of performance hit. However, I'll take the hit for what the tools can offer. Furthermore, if you have that much traffic causing a performance issue, you will probably have enough revenue or justifications to scale up and out.
