APCu from a cron job?

[mikekasprzak]

I realize apc.enable_cli just makes APCu work from the CLI. It doesn't give you access to the data used by your web server.

I have a bunch of usage data I'm tracking with APCu from my REST API (calls per minute, per user limits). Data integrity isn't important. What's most important is having the smallest impact on performance as I collect it (hence APCu), but I want to occasionally dump some of the data to the database on a schedule to graph later. Ideally in a cron job, but the important part is "on a schedule" without risk of triggering DB writes twice.

Is there any sensible way to do this that I'm missing?

I don't like the idea of a running a localhost-only web server, and making a call to a PHP script with curl.

[ryanaslett]

I don't like the idea of a running a localhost-only web server, and making a call to a PHP script with curl.

Thats the only place the data you are interested in resides. APCu is an in memory cache, connected only via its api to the rest of php. It's persistence means that its tied to whatever server your REST API is on. If you've got a REST API already built, I would assume you've already got rate limiting / authentication /authorization built into that endpoint. Why not add some GET endpoints, that only admins can access, that gives you the stats you want?

[dugwood]

If you are already running PHP-FPM, just use the wonderful https://github.com/hollodotme/fast-cgi-client (available in Composer too).

[DennisBirkholz]

I realize apc.enable_cli just makes APCu work from the CLI. It doesn't give you access to the data used by your web server.

The way APCu allocates its memory (using mmap either anonymously or via a file with a name created by mktemp/mkstemp, see apc_mmap.c) allows only processes from the same process tree (e.g. spawned from the main PHP-FPM process or the apache2 process in case of mod_php) to access the memory segments.

Even if you set the apc.mmap_file_mask runtime configuration setting, it must be a mask and APCu still calls mktemp/mkstemp on it, so you can not force two unrelated processes to use the same memory segment.

I would recommend you to use something like memcached or redis for your use case.

It would be nice if APCu allowed you to specify a backing file instead of only a mask so you could have persistent APCu content between restarts and the possibility to access the content in a CLI script for e.g. cache warming.

[dugwood]

I don't recommend Memcached or Redis for performance reasons. I've got rid of Memcached for this exact reason (using multiple servers), and created a local PHP server to invalidate old keys (or timestamp based), because APC will always be faster that any other distributed system.

As long as you use only one server, you must stick with APCu. The good option is to use a fastcgi client to access data from the cron, if it's created by your main process (if it's a fastcgi server, as PHP-FPM is, of course).

But I do agree with you that it would be great if we can access it another way, perhaps it's a mktemp limitation.