PHP5 OOP - Caching out SQL query results securly - 05/31/08 10:02 AM
Sup peoples. I promised another tut on PHP5 caching and I am actually going to do it. If you are like me, you have spent hours shaving precious Milli seconds off queries trying to speed up applications. Maybe you have that one query that hits 10 tables across 3 databases. Damn shame. Meanwhile your applications gets bogged down. Your users complain the site has slowed down since the new features. You know you want to keep the application but the time is killing you.
Or maybe your hoster has said your application take up too many resources. I first looked into caching when Gizmo mentioned it to me. About a year maybe two years ago, we were yucking it up on the tele. I thought, caching... Ole red beard is drinking again. Caching is for desktops. Sigh, seems I was wrong.
While working at the Census Department I coded quite a few LARGE data apps. There are over 300,000,000 people living in the US. So just imagine database table with more rows than 300,000,000 rows. Now we would partition the tables, that helped a lot. We had one kick [censored] DBA. But in the end, I still was lacking some speed. Enter caching
If you have data you know you can count on being the same for 15 minutes or more in a high use environment... Caching is for you. When I started thinking seriously about caching I layed out some requirements.
So with my requirements I set off to code a SQL (or array caching system.)
Or maybe your hoster has said your application take up too many resources. I first looked into caching when Gizmo mentioned it to me. About a year maybe two years ago, we were yucking it up on the tele. I thought, caching... Ole red beard is drinking again. Caching is for desktops. Sigh, seems I was wrong.
While working at the Census Department I coded quite a few LARGE data apps. There are over 300,000,000 people living in the US. So just imagine database table with more rows than 300,000,000 rows. Now we would partition the tables, that helped a lot. We had one kick [censored] DBA. But in the end, I still was lacking some speed. Enter caching
If you have data you know you can count on being the same for 15 minutes or more in a high use environment... Caching is for you. When I started thinking seriously about caching I layed out some requirements.
- The dataset being cached had to be secure (no web surfer should be able to directory surf and get them.)
- The file names had to be unique enough That I could reasonably be sure now accidental overwriting would happen
- The structure of the save data would have to be easy to work with. (I didn't want to write whole new code just to read and work with cache files)
- I had to be able to code this thing one time and use it for all apps.
- It had to document the cache files it created.
- It had to be flexible and allow me to change a few things.
- File extensions it uses for the cache files
- The hashing algarythm it uses, Not all systems use SHA1
- The time frame a cache is good for.
So with my requirements I set off to code a SQL (or array caching system.)