Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>First of all, let me try to think with you on your direct questions:<br><br> - For the performance that you're aiming at, I would say that demanding shared memory access to lookup-tables is overkill. For example, memcache developers on expected performance: "On a fast machine with very high speed networking (or local access - ed.), memcached can easily handle 200,000+ requests per second."<br><br> - You're currently probably limited by cpu-time since you're generating every page dynamically. If at all possible: cache, cache, cache! Cache your frontpage and rebuilt it just once every minute or five minutes. For logged-in users, cache user-specific pages that they might visit again in their session. For example: Where 50 requests a second is not too bad for a dynamic page, a reverse-proxy such as varnish can serve <a href="http://deserialized.com/reverse-proxy-performance-varnish-vs-squid-part-1/" rel="nofollow noreferrer">thousands</a> of static pages a second on a pretty mediocre server. My best hint would be to look into setting up a reverse proxy using <a href="http://varnish-cache.org/" rel="nofollow noreferrer">varnish</a> or <a href="http://www.squid-cache.org/" rel="nofollow noreferrer">squid</a>.<br><br> - if you still need to generate a lot of pages dynamically, use a <a href="http://en.wikipedia.org/wiki/PHP_accelerator" rel="nofollow noreferrer">php accelerator</a> to avoid having to compile the php code every time the script is run. According to wikipedia, this is a 2 to 10-fold performance increase right there.<br><br> - mod_php is the fastest way to run php.<br><br> - Besides using fastcgi, you could write an apache module and have your data in shared memoryspace with the webserver itself. This could be very fast. However, I've never heard of anybody doing this to increase performance, and it's a very inflexible solution.<br><br> - If you move towards more static content or go the fastcgi way: <a href="http://www.lighttpd.net/" rel="nofollow noreferrer">lighthttpd</a> is faster than apache.<br><br> - Still not fast enough? <a href="http://en.wikipedia.org/wiki/In-kernel_web_server" rel="nofollow noreferrer">in-kernel webservers</a> such as <a href="http://en.wikipedia.org/wiki/Khttpd" rel="nofollow noreferrer">TUX</a> can be very fast.<br><br><br></p> <p>Secondly: You are not the first one to encounter this challenge, and fortunately some of the bigger fish are kind enough to share their 'tricks' with us. I guess this is beyond the scope of your question, but it can be truly inspiring to see how these guys have solved their problems, and I decided to share the material known to me.<br><br> Look at <a href="http://www.slideshare.net/adityaagarwal/qcon" rel="nofollow noreferrer">this</a> presentation on facebook architecture, and <a href="http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches/138" rel="nofollow noreferrer">this</a> presentation on 'building scalable web-services', containing some notes on the flickr design.<br></p> <p>Moreover, facebook lists an <a href="http://developers.facebook.com/opensource/" rel="nofollow noreferrer">impressive toolset</a> that they have developed and contributed to, Moreover, they share notes on their <a href="http://www.facebook.com/Engineering" rel="nofollow noreferrer">architecture</a>. Some of their performance-improving tricks:<br> - some performance-improving customizations to <a href="http://memcached.org/" rel="nofollow noreferrer">memcache</a>, such as memcache-over-udp.<br> - <a href="http://wiki.github.com/facebook/hiphop-php/" rel="nofollow noreferrer">hiphop</a> is a php-to-optimized-c++ compiler. Facebook engineers claim a 50% cpu-usage reduction.<br> - implement computationally intensive services in a 'faster language', and wire everything together using <a href="http://incubator.apache.org/thrift/" rel="nofollow noreferrer">thrift</a>.<br><br></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload