Re: [APC-DEV] Ideas for APC 3.0.15/16

Brian Shire wrote:
> I'm currently working on a binary dump that will dump the entire user 
> cache and file cache (with filter options as well) into a binary file 
> which can then be reloaded into APC.  

I have serious issues with letting people dumping the file cache onto
a disk file.

If I can implement a decent cache warming system as George
Schlossnagle had suggested, the requirement is fairly moot.

On the other hand, I don't want to end up maintaining another
"php encoder" which obfuscates source code as opcode binaries.

> One limitation of this is that it is binary, 
> so it is not compatible between different architectures

I have no issues with having a binary cache dump, as long as
I can add in an endian-safe header which gives errors when loaded
in the wrong place.

> int apc_binload(string data);
> int apc_binload_file(string file);

I'd love if there wasn't a user API for this. Just a config file
option to point to a binary dump and which is loaded exactly once
during start up.

I've recently become a fan of not letting anybody do anything
while serving an HTTP request, if possible - especially things
like exhaust shm memory with something like the above.

> The JSON mode for apc.php would be useful.  

> Least recently used algorithm for cleaning up the cache.

Doesn't atime + ttl essentially do this ?

Of course, the idea sort of is to never let it hit expunge that
often :)

> Multiple memory segment support, which would allow you to create two 
> segments with different configurations.

What exactly do you mean different configurations ?

> Do you have plans to rework some of the memory management?

Not as of now. My last couple of attempts to redo memory management,
more accurately with partitioned locks has ended up in a mess.

Have sort of decided that the current allocator is good enough if
you're allocating. But free() could use a bit of work, but I'm
not complaining :)

Cheers,
Gopal
-- 
If I learn from my mistakes, pretty soon I'll know everything