It’s rare to find a web server with slow disk I/O performance, but Amazon’s EC2 micro-instances are one such example. Their EBS disk subsystem access is rated “low”, and this can have a detrimental effect on HTTP throughput. Static resources can be cached in memory or pushed to CDN, and dynamic pages can be cached with APC (setting
apc_stat off on production servers also provides in-memory caching for interpreted PHP bytecode). Also access and error logs can be written to the
rsyslog daemon, which will perform asynchronous disk writes or forward logs to a central server.
This leaves sessions, which can be written to a redundant and fault tolerant storage system. But if sessions are stateless, only storing small amounts of reconstructable data (a user ID for example) they do not need redundancy, and writing to disk is acceptable. In order to speed up the disk access, a RAM-based disk can be mounted over the session directory. This has the disadvantage of being volatile – the data is lost in case of a server reboot, or the mount point being unmounted. However if tolerable, storing sessions in RAM insulates the application from poor filesystem performance.
There are two filesystem types distributed with newer kernels: ramfs and tmpfs (kernel 2.4+, previously called shmfs).
One downside of ramfs is you can keep writing data into it until you fill up all memory, and the VM can’t free it because the VM thinks that files should get written to backing store (rather than swap space), but ramfs hasn’t got any backing store. Because of this, only root (or a trusted user) should be allowed write access to a ramfs mount.
A ramfs derivative called tmpfs was created to add size limits, and the ability to write the data to swap space. Normal users can be allowed write access to tmpfs mounts.