Martin Fjordvald

Yesterday Nginx Inc announced that it had taken $3 million USD in funding. No one deserves this more than Igor Sysoev and it’s hard to believe that Nginx wasn’t commercialized sooner. Well deserved or not, though, whether this funding is good for Nginx or not is up for debate.

To understand the whole aspect of the deal I’ll first cover the worst-case scenario that people might fear happening. I’ll later on cover why this case is unlikely, so please do finish reading before considering me a moron.

The FUD Aspect

Getting funded means a business person has seen potential and decided to invest money to get a return. There’s really no way to deny this, philanthropy simply does not happen in the start-up world unless you’re being funded by your rich but slightly senile aunt. Eventually this business man will want to get a return on his investment and this means the Nginx Inc will have to become profitable. How does an open source project become profitable, though?

• Going closed source and commercializing the product.
• Creating a closed source enterprise version to develop alongside open source version.
• Keeping the core product open and developing commercial extensions of that product.
• Keeping product open sourced and selling support, training and resources.

There might be a few more options that I haven’t thought of, but these are the most commonly seen ones. Based on the press release and statements made to the press we know that Nginx Inc plans to release a commercial version of Nginx for paying customers. To quote Andrew Alexeev:

“we think that it’s the most valuable approach for open source projects to be open core, in order to provide the commercial features that are really needed”

So that leaves us with an open core and most likely commercial modules for enterprise customers. Modules, perhaps such as high availability, proper load balancing or actual backend monitoring. Things normal people obviously do not need.

I’ll be the first to admit that the slippery slope argument is not a proper argument, it cannot be used as evidence of Nginx going in the wrong direction. Nevertheless, it is still a fun thought-experiment. For Nginx Inc to be profitable it’s in their interest to get as many people as possible on their paid plans, as such it is in their interest to keep the functionality in the free version limited to just enough that they can keep attracting new users.

They might promise to not want to upsell users, however, we all know how much a promise is worth when it comes to making money. If the commercial modules fail then commercial version is introduced, then the free version is scraped and eventually you’ve got a new Oracle on your hands. Business people are running Nginx Inc now and the death of Nginx as open source might be coming.

The Rational Aspect

The above is, of course, pure FUD. There’s no evidence that actually points to such a scenario happening and it is merely the worst case scenario I could think up. So what do we know? What are the actual facts about this move.

• Nginx Inc is getting new offices in San Francisco.
• Nginx Inc will release a commercial arm based on the open source Nginx core. Whether a full version or just modules is not known.

We can infer another fact based on this – namely that Nginx Inc will hire new people. Before Nginx Inc formed as a company back in July it was largely a one man project. If you followed the development it was Igor writing code with a few rare patches from third party. Mostly other developers were told to develop modules.

Today Nginx has 3 full-time developers working on the code instead of just Igor working after-hours, this alone is a win for everyone who uses Nginx. I think it’s safe to say that development on the Nginx core should increase even if they only dedicate a single person to working on it.

Having a resourceful company behind Nginx is also a plus as it allows enterprise customers to be confident in using Nginx to power their infrastructure. They’ll be able to get support and know that the product isn’t a fly-by-night operation. More companies using Nginx means an increased need for people familiar with Nginx and that might increase the value of people with Nginx as a skill set.

The Rational Worst-Case Scenario

Lets assume for a second that the FUD aspect holds true and Nginx becomes a close source project, or even that the open source version is crippled to where it’s just a bare bones httpd which even lighttpd outshines.

Nginx Inc actually has very little control over the entire infrastructure that is Nginx, in fact, the only two things controlled by Nginx Inc are the Nginx domain(and product) and the mailing list. For the longest time Nginx support has been handled by Igor on the mailing list and the community everywhere else. The IRC channel, which these days has 300+ people idling, is controlled by community volunteers, the Nginx wiki is controlled by the same community volunteers and the Nginx forum is controlled by Jim Ohlstein who has no connection to the Nginx company.

All this means that should the worst case scenario happen with Nginx Inc blinking and suddenly having dollar signs appear in their eyes, then the community can pull an OpenSSH and fork Nginx due to it using the BSD 2-clause license. If the community so desires the documentation and support structure can follow along.

Of course, it’s important to note that this scenario is far-fetched and that forking software is a last-measure. I don’t see it happening.

My Personal Thoughts

I’m personally not too concerned at this point. Nginx has a long history of being open source and while it’s going open-core now I still feel confident that the core will not be neglected or crippled in favour of making money. On the other hand, I don’t know how much ownership Igor had to give up, nor do I know how strong of a leader/owner he’s going to be. At this point I’m positive about the funding, extra developers means good things and until I see signs otherwise I really have no reason to panicking. Should my FUD scenario ever come true I’m also pretty confident we’ll see an Nginx fork with a lot of the support structure migrating over. This of course makes it in the best interest of Nginx Inc to continue working closely with the community which has supported Nginx for so long.

I would like to see a more open development approach, though. A road map of planned features and more details what exactly they plan to offer in their commercial version would be very welcome and would allow people to know how to react.

Yesterday Nginx Inc announced that it had taken $3 million USD in funding. No one deserves this more than Igor Sysoev and it's hard to believe that Nginx wasn't commercialized sooner. Well deserved or not, though, whether this funding is good for Nginx or not is up for debate.To understand the whole aspect of the deal I'll first cover the worst-case scenario that people might fear happening. I'll later on cover why this case is unlikely, so please do finish reading before considering me a moron.The FUD AspectGetting funded means a business person has seen potential and decided to invest money to get a return. There's really no way to deny this, philanthropy simply does not happen in the start-up world unless you're being funded by your rich but slightly senile aunt. Eventually this business man will want to get a return on his investment and this means the Nginx Inc will have to become profitable. How does an open source project become profitable, though?Going closed source and commercializing the product. Creating a closed source enterprise version to develop alongside open source version. Keeping the core product open and developing commercial extensions of that product. Keeping product open sourced and selling support, training and resources.There might be a few more options that I haven't thought of, but these are the most commonly seen ones. Based on the press release and statements made to the press we know that Nginx Inc plans to release a commercial version of Nginx for paying customers. To quote Andrew Alexeev: "we think that it's the most valuable approach for open source projects to be open core, in order to provide the commercial features that are really needed" So that leaves us with an open core and most likely commercial modules for enterprise customers. Modules, perhaps such as high availability, proper load balancing or actual backend monitoring. Things normal people obviously do not need.I'll be the first to admit that the slippery slope argument is not a proper argument, it cannot be used as evidence of Nginx going in the wrong direction. Nevertheless, it is still a fun thought-experiment. For Nginx Inc to be profitable it's in their interest to get as many people as possible on their paid plans, as such it is in their interest to keep the functionality in the free version limited to just enough that they can keep attracting new users.They might promise to not want to upsell users, however, we all know how much a promise is worth when it comes to making money. If the commercial modules fail then commercial version is introduced, then the free version is scraped and eventually you've got a new Oracle on your hands. Business people are running Nginx Inc now and the death of Nginx as open source might be coming.The Rational AspectThe above is, of course, pure FUD. There's no evidence that actually points to such a scenario happening and it is merely the worst case scenario I could think up. So what do we know? What are the actual facts about this move.Nginx Inc is getting new offices in San Francisco. Nginx Inc will release a commercial arm based on the open source Nginx core. Whether a full version or just modules is not known.We can infer another fact based on this - namely that Nginx Inc will hire new people. Before Nginx Inc formed as a company back in July it was largely a one man project. If you followed the development it was Igor writing code with a few rare patches from third party. Mostly other developers were told to develop modules.Today Nginx has 3 full-time developers working on the code instead of just Igor working after-hours, this alone is a win for everyone who uses Nginx. I think it's safe to say that development on the Nginx core should increase even if they only dedicate a single person to working on it.Having a resourceful company behind Nginx is also a plus as it allows enterprise customers to be confident in using Nginx to power their infrastructure. They'll be able to get support and know that the product isn't a fly-by-night operation. More companies using Nginx means an increased need for people familiar with Nginx and that might increase the value of people with Nginx as a skill set.The Rational Worst-Case ScenarioLets assume for a second that the FUD aspect holds true and Nginx becomes a close source project, or even that the open source version is crippled to where it's just a bare bones httpd which even lighttpd outshines.Nginx Inc actually has very little control over the entire infrastructure that is Nginx, in fact, the only two things controlled by Nginx Inc are the Nginx domain(and product) and the mailing list. For the longest time Nginx support has been handled by Igor on the mailing list and the community everywhere else. The IRC channel, which these days has 300+ people idling, is controlled by community volunteers, the Nginx wiki is controlled by the same community volunteers and the Nginx forum is controlled by Jim Ohlstein who has no connection to the Nginx company.All this means that should the worst case scenario happen with Nginx Inc blinking and suddenly having dollar signs appear in their eyes, then the community can pull an OpenSSH and fork Nginx due to it using the BSD 2-clause license. If the community so desires the documentation and support structure can follow along.Of course, it's important to note that this scenario is far-fetched and that forking software is a last-measure. I don't see it happening.My Personal ThoughtsI'm personally not too concerned at this point. Nginx has a long history of being open source and while it's going open-core now I still feel confident that the core will not be neglected or crippled in favour of making money. On the other hand, I don't know how much ownership Igor had to give up, nor do I know how strong of a leader/owner he's going to be. At this point I'm positive about the funding, extra developers means good things and until I see signs otherwise I really have no reason to panicking. Should my FUD scenario ever come true I'm also pretty confident we'll see an Nginx fork with a lot of the support structure migrating over. This of course makes it in the best interest of Nginx Inc to continue working closely with the community which has supported Nginx for so long.I would like to see a more open development approach, though. A road map of planned features and more details what exactly they plan to offer in their commercial version would be very welcome and would allow people to know how to react.

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 »

The Big PictureSo 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.Nginx Event Based Processing:Receive request, trigger events in a process. The process handles all the events and returns the outputOn the surface it seems fairly similar, except there's no blocking. This is because the process handles events in parallel. One connection is not allowed to affect another connection even if run simultaneously. This adds some limitations to how you can program the web server, but it makes for far faster processing as one process can now handle tons of simultaneous requests.Remember those limitations, though? Yeah, they'll affect how we, as users, have to use Nginx. For instance, we can no longer embed PHP into our Nginx process as PHP is not asynchronous. Essentially, if we embedded PHP into Nginx the event based architecture of Nginx would be rendered void as PHP would be blocking and connections would just pile up.Since a web server isn't all that desirable without the ability to use dynamic scripting languages Nginx has support for various communication protocols such as FastCGI, SCGI and UWSGI. Conveniently enough, PHP happens to support FastCGI, which means we can still use PHP.FastCGI Versus EmbeddingThe thing that confuses most first time users of something not Apache is that suddenly they have to actually handle the PHP part themselves. Nginx takes a complete hands off approach to all dynamic scripting languages and reverse proxy situations. (more on this later)With Apache you just configure it to use PHP, start it and forget about it. With Nginx you have to spawn a number of PHP processes and tell Nginx to talk to them. This has both advantages and disadvantages.The primary advantage is that you now have complete separation of your web server and PHP. If you change something in PHP you don't have to restart Nginx, only PHP. Similarly, if you want to restart Nginx then PHP keeps running. Since Nginx supports upgrading the binary and changing the configuration on-the-fly this means you can upgrade your web server or change its configuration without any down time at all.The primary disadvantage is that you have to handle the spawning and process control of PHP yourself, or rather Nginx won't do it for you. A year ago this was a bit troublesome. You had to use a script called spawn-fcgi to spawn the fastcgi processes and then monitor them with something secondary like Monit. Alternatively you could use a patch to the PHP source code called PHP-FPM - quite literally FastCGI Process Manager. As of PHP 5.3.3 PHP-FPM is now part of the PHP core, which means you don't have to patch the source code yourself, but can just set a compile time configure flag. Naturally, most distribution repositories have a PHP build with PHP-FPM enabled as well. So really, this disadvantage is barely a disadvantage any more as PHP-FPM is a very cool thing in itself. More on that another day.A second disadvantage, which is heavily disputed is that since the PHP process is no longer embedded there is an overhead in talking to PHP. This is used as an argument by some people as for why you should use Nginx to handle static files and Apache to handle the PHP files. Theoretically there is an overhead in talking with Apache as well, so I personally doubt there's much of a disadvantage, but I don't have the tests to back that up.The Configuration DifferencesOkay so we now know what the big picture is, time to understand how Apache and Nginx differs on a configure level. This is where we'll actually spend most of our time so this is what is important to know about. I have to stress that it's important to actually learn about Nginx. Nginx has undergone a huge amount of development in the last few years and as a result there is a lot of different advice out on various blogs. To be quite frank, a lot of it is bollocks and should be removed as it is often down right wrong. In general, if a tutorial or guide is making heavy use of ifs then avoid it, there are far better alternatives such as try_files, I'll cover that a bit in this section..htaccessThe biggest headache for a lot of people is that they no longer have access to .htaccess. There is no way to change your Nginx configuration without issuing a reload command to Nginx. The effect can be simulated by using include directives in the main Nginx configuration file, but any change will not take effect until the configuration file has been reloaded. This is also the primary reason why Nginx is not very suited for shared hosting, not even in a situation where you reverse proxy to Apache.There is no alternative in Nginx so if you want to use Nginx this is one thing you have to live with, in the beginning it might be annoying but after a few hours you really won't notice or miss it.Apache & Nginx RewritesTypically in Apache you will specify your rewrites in .htaccess or at least in a global context so that they are always evaluated. Nginx provides locations to prevent this exact thing. We don't want to execute something that we don't need to, so if we need to rewrite the URI example.org/forum/index.php?topic=3 into forum.example.org/index.php?topic=3 we should use a location to ensure we only execute this rewrite when absolutely required.Another thing about Nginx rewrites is that by default they are internal rewrites, which means that they won't change the URI the browser sees. They will only do that if you specify the "redirect" or "permanent" rewrite flag or if you rewrite to an absolute URL including the http:// part.Apache RewriteCondRewrite Conditions is something which doesn't really exist in Nginx. Something you might see in Apache is the following: RewriteCond   %{HTTP_HOST}   ^example.org$   [NC] RewriteRule   ^(.*)$   http://www.example.com/$1   [R=301,L] The directly translated Nginx equivalent would be if ($host != 'example.org' ) { rewrite ^/(.*)$ http://www.example.org/$1 permanent; } I took this from an actual tutorial out there. This is wrong for two reasons. Most importantly Nginx does a lot of optimization to vhosts. If you use an if like this you miss out on that optimization as a request for example.org and www.example.org will both have to go to the vhost, then parse the if and then the regex. Less important is that you're capturing data Nginx has already captured for you.The Nginx way to do this is the following: server { server_name example.org; rewrite ^ http://www.example.org$request_uri? permanent; } This way a request for example.org will not parse to the www.example.org server block, we won't have to actually parse a regex since it's just a starting character and nothing else, and the rewrite still uses the URI captured by Nginx.Another popular RewriteCond is the following: rewritecond %{REQUEST_FILENAME}!-d rewritecond %{REQUEST_FILENAME}!-f rewrite ^ /index.php [L] Basically, if the requested file doesn't exist and isn't a directory then do execute a rewrite, this is often used to implement pretty URLs. In Nginx you'd do this like the following: location / { try_files $uri $uri/ /index.php$is_args$args; } What this means is that it will first check if $uri exists, (in relation to your root directive) then it will check if $uri/ exists, which would be a directory. Finally, if none of these exists it will do an internal rewrite to index.phpA quick thing to note is that while ifs are usually discouraged there are some cases where they cannot be avoided. For example if you want to check the request method is GET before you send to the backend then you are forced to use if ($request_method = GET) This will usually work just fine and isn't too bad considering there isn't a more optimal way to do it.Using Apache and Nginx TogetherA common scenario is for people to use both Apache and Nginx. They'll have Nginx handle the static files and then proxy the dynamic requests to PHP. This can be beneficial if you are not completely ready to ditch Apache, for instance if you have a legacy application relying on Apache or .htaccess files. There are also a few cases where Nginx alone cannot handle all use cases. A common one is when people need a HTTP front end for SVN. The Nginx WebDAV module supports only a limited set of the protocol so in this case you need to reverse proxy to Apache and let it handle it.On the flip side, having Apache handle your dynamic requests introduces another layer of complexity in your server setup, causing more potential problem areas. Usually you don't actually need Apache so there's really no reason to keep it around as a crutch, in the long run it will benefit you more to use just one of them.if you do decide to use both, and plenty of people do, then there are a few things you should know. I won't cover how to configure Nginx for this as the Wiki is plenty resourceful there. But keep this in mind:When you reverse proxy to Apache, Nginx will handle the connection, parse it and then create a new connection to Apache. It does not tunnel the connection so you have to specify which headers to pass on. Furthermore, the connection Nginx establishes is using HTTP/1.0, and not HTTP/1.1. This means things such as chunked encoding is not supported.To make your reverse proxy experience as easy as possible you should therefore keep a few things in mind.Let Nginx handle SSL and keep the connection between Nginx and Apache in plain text. There is no reason to add the overhead of SSL unless you are afraid of a man-in-the-middle attack on your internal network. Let Nginx handle the gzipping of content. Don't gzip on the Apache side as that will most likely cause you some major headaches.If you want a more comprehensive guide for reverse proxying and are too lazy to read the wiki then see kblessinggr's Apache and Nginx Together guide.A Note on Shared HostingI mentioned earlier that Nginx isn'tt very suited for shared hosting. You might think that if you let Nginx handle just static files while proxying non-existing files and dynamic files to Apache then you'll be good. This isn't quite the case, though. As an example, consider basic authentication, if you want to have basic authentication on a static file then you will need to add it in the Nginx configuration, and users cannot do this without having to reload the configuration file. If you allow them to change it and reload it then they can make a mistake and ruin it for everyone.Think very carefully about every aspect before you decide to use Nginx in your shared hosting setups.