"Curiosity is the very basis of education and if you tell me that curiosity killed the cat, I say only the cat died nobly." - Arnold Edinborough

Martin Fjordvald

Ingenious Community Engagement

User EngagementUsually when you browse the internet you get your information and you’re on your way. Sometimes a website isn’t properly constructed and prevents you from getting your information easily, this causes you to become annoyed. Rarely you find something that is so awesome you just have to admire it and the thoughts that have gone into it. Today I found one of those things.

There are a lot of difficult aspects of starting and running a site. You have to consider how to drive traffic, how to rank on search engines, how to convert traffic to paying customers of participating users, and today I saw an ingenious example of how to engage users and encourage participation.

The image on the right is taken from a news post on the NBC Dallas site, it shows the general reader feedback and allows readers to submit their own feedback. The unique aspect is of course how they group the feedback. It’s not a generic 1 to 10 rating, it’s not a “let your voice be heard” sentence, it’s a colourful, graphic and quantified display. I cannot stress enough how awesome this is executed. What they manage to do is immediately quantify the response to an article which encourage users to add their voice.

Read More

flattr this!

Implementing Full-Page caching with Nginx and PHP

This is part two in my caching series. Part one covered the concept behind the full page caching as well as potential problems to keep in mind. This part will focus on implementing the concept in actual PHP code. By the end of this you’ll have a working implementation that can cache full pages and invalidate them intelligently when an update happens.

Requirements

I’ll provide a fully functional framework with the simple application I used to get my benchmark figures. You’ll need the following software to be able to run it.

  • Nginx. I’m not sure which exact version but I generally use and recommend the latest development version.
  • PHP 5.3.0. I recommend at least 5.3.3 so you’ll have PHP-FPM for your fastcgi process management.
  • MySQL
  • Memcached

The Framework

I’ll be referencing the code on github instead of pasting it in this post to keep the size down, so you will probably want to download it.

Read More

flattr this!

WordPress Performance Benchmarks

Recently a post of mine was linked on yCombinator and for some reason a lot of the comments talked about the efficiency of WordPress. While it’s technically not related to the subject of the linked post I just want to point out that the performance of WordPress is pretty horrible regardless of whether you use Apache or nginx.

My friend Karl Blessing and I recently talked about WordPress caching plugins. He uses WP SuperCache and I use W3 Total Cache and he subsequently decided to do some WordPress caching benchmarks on the different methods. He’s done an awesome job and generated some pretty graphs for you to look at.

What I took away from the whole thing is that W3 Total Cache and WP SuperCache can offer similar performance if you’re willing to do static file caching, however, W3 Total Cache can offer a cleaner solution with caching in Memcached if you’re willing to sacrifice a bit of performance. The benefit to this, and why I use this method, is that you don’t need complicated rules in your nginx (or Apache) configuration files.

flattr this!

Nginx Primer 2: From Apache to Nginx

The Big Picture

So you’ve finally decided to make the switch from Apache to nginx. You most likely did this for performance reasons; perhaps all those blogs have been writing about how fast nginx is or perhaps your webmaster friends have been raving about how they can now handle a lot more traffic without spending money on hardware.

This is usually all true, but why exactly is nginx so much faster than the typical Apache setup of the prefork MPM and mod_php? The technical explanation is that nginx is a non-blocking event based architecture while Apache is a blocking process based architecture. To simplify it heavily the theory is like this:

Apache Prefork Processes:

  • Receive PHP request, send it to a process.
  • Process receives the request and pass it to PHP.
  • Receive an image request, see process is busy.
  • Process finishes PHP request, returns output.
  • Process gets image requests and returns the image.

While the process is handling the request it is not capable of serving another request, this means the amount of requests you can do simultaneously is directly proportional to the amount of processes you have running. Now, if a process took up just a small bit of memory that would not be too big of an issue as you could run a lot of processes. However, the way a typical Apache + PHP setup has the PHP binary embedded directly into the Apache processes. This means Apache can talk to PHP incredibly fast and without much overhead, but it also means that the Apache process is going to be 25-50MB in size. Not just for requests for PHP requests, but also for all static file requests. This is because the processes keep PHP embedded at all times due to cost of spawning new processes. This effectively means you will be limited by the amount of memory you have as you can only run a small amount of processes and a lot of image requests can quickly make you hit your maximum amount of processes.

Compare this to the nginx event based method.

Read More

flattr this!