Monitor IO to tmpfs partition

My gut suggests that memcached would be noticeably more efficient as the filesystem will be maintaining ownership and permissions flags for each object on each create, and checking them on every file open to read. Also, you are likely to find that memcached's structures are better indexed than the tmpfs filesystem which IIRC uses an unordered linear list for directory listings so has to scan (on average) half a directory listing to find an object instead of being able to do a more efficient divide-and-conquer search.

I'm assuming in the above that you are meaning storing many cached results, most of which are relatively small in size, each in their own file on the RAM based filesystem. If you are meaning keeping many results in a single file on tmpfs then a memory based sqlite database would be more efficient and saves you reinventing the wheel in terms of index management and efficient searching.

Of course, as you say, being able to manipulate your cache with any tool that understands filesystems may be an advantage strong enough to make most efficiency arguments moot points.

Which technique is better will depend greatly on what you are using it for of course, so it might be a good idea to add more detail about your project to the question. As a code/data optimisation query, this might be a questions for StackOverflow rather than ServerFault (a server admin is not likely to be in a position of choosing a project's cache storage option, unless the programmers have implemented more than one to choose from) - you might find people over there who have benchmarked memcached/sqlite/tmpfs/custom_solution for their project and can give you some useful comparative figures.

I answered a similar question here when someone was asking how to load a MySQL database to memory. There's a native ENGINE in MySQL among other potential solutions, which are better for most situations.

For MyISAM tables, your proposed solution would be functional.

The rsync shouldn't necessarily penalize performance but it could if your system was really low on resources, as high I/O utilization would impact system performance as a whole. In most cases, I'd say it wouldn't but only way to be sure is to test.

The ramdisk solution seems risky to me. In case of power loss, data could be lost, as your rsync would not be realtime. You could replication the database to a slave, which could store on a disk. The startup on MySQL on the ramdisk server could scp from that host into the ramdisk before starting the instance.

If your MySQL instance was not well optimized, you would notice substantial performance gains. If well optimized, I'd suspect that the gains would be less. The only way to be sure is to use tools like Super Smack, MySQL Benchmark, and sysbench to quantity the performance.

Good luck.