3

I am in charge of hosting a PHP application that is large and slow, but easy to scale. The application is entirely static, with writable disk storage needed. We've profiled the application, and the main bottleneck appears to come from loading the application and not the work the application does. The application is not CPU-intensive, although it does use a fair amount of memory (think Magento).

Currently we distribute it by having a series of servers with the same PHP files on their hard drive and a load balancer in front of them. Easy but expensive.

I've been reading about RAM disks and the IO benefits they offer, and was wondering if they would be well-suited to PHP applications.

Since PHP applications are loaded from disk for every request and often involve lots of different files (as opposed to being kept in memory like with a Java application), I would figure that disk performance can be a severe bottleneck.

Would placing the PHP files on a RAM disk and using the mount point as Apache's document root offer performance benefits? A startup script could create the RAM drive and then copy the files (which are plain-text and small) from a permanent location to the temporary RAM drive.

Does this make sense, or should I just trust the linux kernel to cache the appropriate files in memory by itself?

Improve this question
6
  • What ARE you hosting? You mentioned Magento, but reference it incorrectly, Magento is CPU bound, not RAM or I/O. Nevertheless, testing would quickly give you your answer.
    – Ben Lessani
    Commented Jul 8, 2012 at 7:49
  • Try maybe xcache or wincache.
    – Andrew Smith
    Commented Jul 8, 2012 at 8:14
  • @sonassi our experience has not been that the typical bottleneck in Magento is processor speed. I would be interested to know in what situations you observe this, though. Possibly this could be the case with an underpowered machine, but we haven't seen that on any of our server-grade equipment.
    – Tom Marthenal
    Commented Jul 8, 2012 at 15:20
  • @TomMarthenal - Our experience is that of hosting several hundred Magento stores, from shared to dedicated, to clustered. We build, own and manage ~100 dedicated servers and only host Magento stores. Typically store size ranging from <1k daily unique visitors to 250k daily unique visitors. I could also provide several dozen monitoring graphs to support this. Magento is CPU bound - nothing else. Oh, and all our equipment uses Supermicro chassis and boards, all Intel CPUs, ranging from 1-way 1U systems, to multi-node 2-way blade systems. See docs.sonassihosting.com/go_dedicated.pdf
    – Ben Lessani
    Commented Jul 8, 2012 at 16:58
  • @sonassi interesting that you would have those issues, typically CPU is not our bottleneck with Magento. I would hesitate to say that something is bound by only one metric, though-- you should reconsider that, as there can always be multiple possible causes for problems.
    – Tom Marthenal
    Commented Jul 9, 2012 at 12:27

4 Answers 4

Reset to default
7

No, a ramdisk would actually hurt PHP (when combined with better solutions such as a PHP accelerator).

The best way to improve PHP performance is to use a PHP accelerator. These are modules that plug into the web engine (apache httpd for example) and cache the compiled bytecode of PHP scripts. This cache is then stored in ram. The result is that future calls to the PHP script don't go to disk at all, the pre-compiled byte code is pulled from the cache. Meaning that you don't gain anything from using a ramdisk, and instead end up consuming ram that could be used elsewhere.

Depending on your distro and which web server engine your'e using, it's likely you already have a PHP accelerator running.

.

Here's 2 good wikipedia articles on the subject:
PHP accelerator
List of PHP accelerators

Improve this answer
4
  • 2
    How could the Ramdisk ever hurt performance? It might not add much with a properly configured accelerator but how could it ever be bad?
    – Danack
    Commented Aug 23, 2013 at 13:25
  • @Danack "when combined with better solutions such as a PHP accelerator". By storing files (which are large and uncompressed) in a ramdisk you're stealing memory from more legitimate uses, such as the accelerator. The accelerator already stores a bytecode version of the code, storing the original version serves no purpose.
    – phemmer
    Commented Aug 23, 2013 at 13:45
  • 1
    But if people have enough ram for both the ramdisk and accelerator, then how could it hurt?
    – Danack
    Commented Aug 23, 2013 at 14:14
  • @Danack You're making the assumption that the system doesn't opportunistically utilize all ram for whatever it can. Most operating systems will also use available ram for filesystem caching, IO buffers, and other things. You end up steal memory from that. In any case, you're loading things into memory for no benefit. Wasting memory is never good for performance.
    – phemmer
    Commented Aug 23, 2013 at 14:26
5

I'd be inclined to think that if you've got a machine with enough RAM, the OS disk cache will do just as well at caching the appropriate content (if not better, because it won't cache files that aren't used), but you should benchmark it on a test server, after verifying that you are, in fact, hitting disk excessively (with sar).

Improve this answer
2

The biggest hog of PHP is, for every request the interpreter has to

  1. fetch the file from the filesystem
  2. read it
  3. translate it into executable form
  4. execute it

With APC you can skip all steps and jump straight to execution. If you have performance issues, and especially after having observed the profiling results you mention, do install and configure APC. You will be astonished what performance gains you get.

I faced the problem of optimizing a large set of wikis for the Howtopedia organization; after press releases, the newspaper coverage they'd get was systematically taking system load to 100%. Configuring APC with just 25 MB of cache brought system load straight to less than 5%. Some further basic tuning to less than 1%.

At the same time, since most of what steps 1-3 do is introduce latency, the response time experienced by users improved dramatically.

Some further tips for the scenario you describe:

  • give APC a cache segment of 25MB or more (make sure your OS allows SHM segments of this size). The cache replacement policy APC uses makes sure your most-requested contents will be in cache, so this will likely give you a hit rate over 95%. Increasing allocated memory gives exponentially less significant benefits.
  • with the mostly static application you mention, disable apc.stat to gain further performance. This allows APC to look up PHP files directly in cache, without having to sanity-check on the filesystem if they were modified since the last execution. Each request gets served entirely from memory, filesystem is never reached, resulting in dramatic performance.
  • after having APC running, your performance bottleneck may move to inside the application. Especially, database and filesystem if you use either. Memcached can help you addressing those with relatively minor changes in your application code.
Improve this answer
0

No, it won't if RAM is already the bottleneck.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .