Wedge

Are you referring to our SFTP story ('scenario 3'), or to the PURLs talk ('ton of crap in the DB')...?

Actually, the former (file access). The alternative to allowing file uploads is to push it all into the DB and call for it as necessary, pushing it out to the cache folder to make it faster. But if that includes executable code, you're still making executable code writable by the webserver owner which makes it vulnerable to abuse from outside. (Cache files are less of a risk because they're purged periodically)

So, no file cache then?

I would guess if you had a real memory caching system it would be faster, as for file caching, it is basically useless and DB caching is wasteful.

For me, DB storage I only have 1GB per database. So DB caching for me isn't a option and file caching looks to have no beneficial gain.

I would guess the only benefit you can gain on file caching is if the information is in the DB, other stuff like computing power PHP seems to be able to compute these things faster than a read from a file, well the read isn't the problem, seems like it is the write.

That would imply then that you want to extend the TTL on caching so that you do fewer writes.

You could leave the caching subsystem in, but only cache things if it's level 2 or higher (so that you actually have to have a proper memory cache in order to use it)

You know under different circumstances you might want different settings here. Just because my disk I/O is slow doesn't mean that is the case for every server setup. Who knows what scheduler is being used on my server, if writes are slower than reads than there might be a higher priority on them, sounds like deadline to me, but can't be sure.

Then you have your accelerators, if one of these are installed then caching might not be a bad idea.

Maybe these are things that can be determined during setup. Certain test to determine the best setting on the server the site is on.

Disk I/O is always slower than using memory caches - always. That's why you have memory caches ;) In any case, writes are physically more intensive to perform than reads, in whatever environment you care to name. It's really about the comparative performance which is almost impossible to test meaningfully.

That's really the thing, if cache level >= 2, cache pretty URL stuff, if not, don't.

I know memory is faster, my comparison was processing vs disk I/O. Processing seems faster than I/O speeds, but can that be the case on all systems, is the processing always going to be faster than disk I/O on every system?

Writes don't always have to be costly though, but the chances of running into a environment like this is rare, on a server even rarer. Most of my setups, on my local devices I always set up the environments where it favors reads more than writes. Reading is what the user cares the most about.

I agree though, the simple solution is usually the best, if there isn't a memory cache available then only process it.

So... Do I remove db caching? :P

Yes, remove DB caching and if any caching is going to occur, do it via cache_put_data if (isset($settings['cache_level']) && $settings['cache_level'] >= 2)

Why only on these? Because we are to assume that's only for non-file-based caches?

Also, I wouldn't know how best to store these URLs in a file cache... Per-page basis is meh to me.

Because for file based caches, the available evidence would seem to suggest that the overhead of performing the writing would erode the benefit of caching.

I'm not sure about handling caching either though.