I have thousands of sites with thousands of pages getting thousands of hits everyday that have the following characteristics and I'd like to know if people here think APC would give me a performance boost or not:

1. I would estimate that 60-75% of the pages on each of these sites get visited AT MOST once. Of the remaining 25%, some pages get visited as many as 100-200 times, but most of these pages get visited somewhere between 10-20 times. These numbers all happen over the course of 1-2 months when the traffic mysteriously disap

pear

 s. 

2. The way the pages are built is EXTREMELY inefficient. Here's a generalization of the steps:

A. Load a template from disk into memory
B. Load some

javascript

  from disk into memory
C. Load the page's content from the database (the tables here are small, so not too expensive)
D. Search and replace variables in the template with the

javascript

  and the content using str_replace

One thing I was thinking of doing is adding another column to my database to store the built page. That way I would just need to check that one field and if it's there I could just dump it out and exit(). I realize this won't be as fast as APC could potentially be, but I have concerns that I'll be churning through APC's cache and it won't help me anyway.

Thoughts?

Is this loading into memory being accomplished by a script, effectively a page puilder (presumably

PHP

 , well duhh!)?

If so, then there should be significant gains IMHO in the fact that this "page builder script" doesn't need to be pulled off the disk each time.

Or have I read this wrong?

Cheers,
td

Yes, you're correct in that it's a

PHP

  script that does all this work.

Are my concerns that I'll be churning the cache unfounded? I know I can increase the cache size, but will I have to make it so large that my other applications suffer tremendously?

The more I think about it, the more a DB driven cache makes sense to me. After writing the first post I realized that what I said about the pages being accessed is only true about the users that visit my site. It does not account for the bot visits, which are visiting many more pages much more often than I outlined above. I believe this will only add to the probability of me churning the APC cache.

Somebody talk me out of doing this with my database please. 

Your "pages", as such won't be stored in the cache if I'm reading you right but the "page builder" script that runs for every page requested will run in the APC cache and should be magnitudes faster (I don't speak from experience, but I think that's right). You should also be able to store data you access repeatedly (

javascript

 , templates, etc) in the cache as well. Which would mean only your db content pulls are left, someone might have an idea on that one, but I'd leave it as is I think.

So, maybe store your templates,

javascript

 , and

PHP

  construction/"page builder" script in APC and pull your content from the db (optimised as per the discussion in the db forum) as required. That's the theory, I'd love to have a go at the implementation but I think perk or some of the other guys could fast track you better.

HTH,
td

TD is correct.

First off, simply implementing APC on your server will stop recompilation of your scripts ie/. you'll compile once and they'll live in memory until the mtime of the file changes. So it doesn't even hit the disk... the code comes out of RAM ready to go. This alone increased performance on one of my WH sites by over 1000%... yes, you read that right. And it's a sweet implementation - if you see APC in the

php

 info() page, you're live. Compiling it can be a little bit of a headache, but once it's on, you're done.

Second, TD is correct about what exactly it is that you cache. The user portion of APC allows you to store any kind of variable in native

PHP

  format (so arrays do not become serialized or have any "retrieval penalty" - they just come back into a variable ready to go). I do cache some of my pages, but more importantly I cache headers/footers, config details and such... so the

net

  throughput of my apps is incredibly fast because they make very few calls to either the DB or the file system. Add to that putting your user state into cache and you can make some really impressive throughput leaps.

A nice thing about APC as opposed to, say, memcached (which I have also used extensively) is that you can query the cache manager for what's inside. So I wrote a little management page that allows me to see everything that is currently cached, modify or delete it. This is particularly handy for pages that are cached and will never normally be changed - if I do change one, I need a way to kill <that> file page without killing the server.

Which leads to the only downside: APC is child memory of the

Apache

  instance that calls

PHP

 . Therefore, you cannot write shell scripts that access the cache - you must go through

apache

 . This has caused me a couple headaches in the past when I forgot that they were inaccessible to me, but once I started remembering it didn't bother me again.

/p

It's painfully obvious that I don't fully understand how APC works (and I plan on reading more about it, I promise) but I wanted to clear something up that I made confusing.

Yes, I have a script that builds all my pages for me, but I have 1000+ instances of this script; one for each domain I have. So on my server there is /home/viagra/public_html/script.

php

 , /home/casino/public_html/script.

php

 , etc. This is where my concern about the cache size comes into play. APC caches my viagra/script.

php

  file and then that's not hit until after it gets bumped from the cache.

If my concerns stem from my ignorance of APC I apologize. Just let me know and I'll shut up until after I read more about it.

No not at all, I understand your concern.

Are the scripts all the same? Do you have something like a "dispatch.

php

 " and themes to colorize your stuff and a repository of text?

If not, and you've literally copied and pasted code then tweaked it just a bit for each domain, then you will do exactly what you fear.

Perhaps you could post a little more about how your system works, or how you'd like it to work so we could give you tips on restructuring and rebuilding.

/p