When should I switch to NGinx?

Solution 1:

Several points:

The major difference between Apache and Nginx or Lighttpd (that I personally very like) is architecture:

1. Apache handles one connection per-process or per-thread (depending on mod-XYZ)
2. Nginx and Lighttpd are single threaded handle multiple connections in single event loop.

As a result:

1. Nginx and Lighttpd scales much better under high number of simultaneous connections, let's say with 1000 connections Apache would almost die as it would require 1000 processes in mod-prefork or 1000 threads in mod-worker.

   If you are planning to use Comet technologies where each connection requires long polling HTTP connection then Apache would not be acceptable as it does not scales well.

2. Nginx and Lighttpd consume less memory as each connection require +- two sockets (HTTP and FastCGI), intermediate memory buffer and some state, while Apache would need entire thread including stack and other things.

From my personal experience in benchmarks I did Lighttpd (and I assume Nginx as well) is slightly faster with FastCGI backend then Apache but this is for low amount of connections.

Now another point is when you want to do some load-balancings using FastCGI connections.

In traditional architecture there is

                               |
                              HTTP
                               |
         Balancer (Nginx/Lighttpd/Cherooke/something-else)
            /      |           |            |      \
         HTTP    HTTP         HTTP        HTTP     HTTP
         /         |           |            |         \
 Apache+PHP   Apache+PHP   Apache+PHP   Apache+PHP   Apache+PHP   
  Server 2    Server 3     Server 4      Server 5     Server 6

Because Apache handles pools of processes each of them running mod-PHP (or other modes)

When you using CppCMS that handles pools on its own you can do something different:

                               |
                              HTTP
                               |
         Balancer (Nginx/Lighttpd/Cherooke/something-else)    
                           Server 1
            /      |           |            |      \
         FCGI    FCGI         FCGI        FCGI     FCGI
         /         |           |            |         \
    CppCMS App  CppCMS App  CppCMS App    CppCMS App  CppCMS App
     Server 2    Server 3     Server 4      Server 5     Server 6

So basically you do not need another indirection level because CppCMS handles process, thread and connection pool for you. While PHP/Ruby/Perl need some Apache mod-XYZ or handle its own FastCGI connector.

Solution 2:

Nginx, speaking very (very) generally, can obtain much higher throughput than Apache thanks to a different architectural approach to the problem of serving pages to the web. Nginx was also built primarily as a reverse proxy, and it fills that role exceptionally well (this is the load-balancing bit you alluded to); Apache, on the other hand, was built to serve web pages, and later gained the ability to proxy.

That said, there are almost certainly areas will Apache will consistently outperform Nginx, while there are others where Nginx will just as consistently outperform Apache.

The short answer is that if Apache is working for you, there's no need to switch. (And I'm saying this as a former Apache user who has become a fully converted Nginx disciple.) Only when traffic to your server starts reaching levels where Apache is becoming your bottleneck (this is on the order of some thousands of simultaneous connections, but will vary wildly based on your server specs and other server load), or if you're trying to run Apache in a resource-poor environment where it can barely fit, does switching to Nginx give you solid benefit.

That said, if you want to switch to Nginx (which I do encourage!), then go for it. Will you see any benefit? 9 times out of 10: No, you won't. But you mentioned that you like the configuration file language of Nginx better, so if it makes you feel more comfortable to configure Nginx than Apache, well, that is a benefit for you! (Personally, I find Apache configurations easier to read in general, but that could be because I spent many, many years reading them, and only a few short months have been spent on Nginx!)

On a side note: You mentioned your desire to build a web app in C++. For the sake of your sanity, I strongly urge you to instead use a higher-level language like PHP, Python, or even Java. Then profile your code and consider creating C++-based modules to address specific bottlenecks (Python and PHP both allow this rather easily; don't know about Java). If you're worried about overall performance, consider this: EVE Online, the single largest unsharded MMORPG in the world, is built on a variant of Python (Stackless Python), with only key components (e.g. the graphics libraries) written in C++. If Python can handle that, surely it can handle your web app?

Solution 3:

Nobody can really answer the "when should I switch" part -- it will depend on your load, the performance of your own application code, etc.

NGinx, that seems to be more performant than Apache

nginx uses a single process (or a very small number of worker processes) to handle all client connections using evented I/O. Apache has several "Multi-Processing Modules" available, but they all lean more towards many many processes / many threads. As a result, Apache will generally consume more RAM and CPU than nginx for basic HTTP connection handling. You can get an overview of the different connection handling approaches on Kegel's C10K page.

very performance-intensive web application (using C++ with CPPCMS)

I would strongly suggest to consider doing the basic webapp in a higher-level language (Python, or maybe Ruby, Scala), and use a messsage queue to send work tickets to worker machines which handle the "performance-intensive" tasks asynchronously.

NGinx would be the best choice when you want load-balancing,

nginx is a good load balancer; but there are many options in that space.

Can I use Apache and NGinx both on the same machine without any problem?

Yes. Just run them on different IP port numbers and/or IP addresses.