dmBridge is much more resource-intensive than the default CONTENTdm® templates. The page load process works like this:

  1. User hits the templating engine
  2. Templating engine fires off multiple (often dozens) of requests to the HTTP API
  3. For each request, the core (HTTP API provider) is compiled and executed
  4. The templating engine completes the request and sends the page to the user

Step 3 is by far the most resource-intensive. When it comes down to it, PHP is not the best language in which to implement a RESTful HTTP API. Unfortunately, it's what we've got. Beyond rewriting the HTTP API component in C++, there are some steps you can take to hopefully make the performance bearable.

Run the HTTP API on a server with a fast CPU.

Compilation of the HTTP API is mostly CPU-bound. In addition, a few fast CPUs are preferable to a lot of slow CPUs. Keep in mind that the server running the HTTP API is also running the rest of CONTENTdm®, including the CPU-gobbling getimage.exe image generator, which means it needs all the CPU it can get.

Run the template engine on a different server than the HTTP API.

This may make a slight difference. Moving the template engine onto another server means one less thing that the already-overtaxed HTTP API server to has to deal with. If possible, the HTTP API server should be the faster one.

Disable .htaccess support on the API server.

The performance hit caused by .htaccess files is generally imperceptibly slight, but is magnified by the great number of requests made to the HTTP API. If you are depending on the rewrite rules in your .htaccess files to enable clean URLs, copy them into the web server's configuration instead.

Install an opcode cache.

We have not yet tested this and would not expect it to do much for the HTTP API due to its use of a class autoloader. Please post a comment if you have experience with this.

If you are using CONTENTdm® on Windows with IIS, switch your server to Linux.

Apache with mod_php is faster than running PHP in CGI or even FastCGI mode under IIS. Running PHP as an ISAPI module on IIS is deprecated, and ISAPI has been removed as of PHP 5.3.