Announcement

Collapse
No announcement yet.

NGINX Might Be Included With Ubuntu Server ISOs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • NGINX Might Be Included With Ubuntu Server ISOs

    Phoronix: NGINX Might Be Included With Ubuntu Server ISOs

    While Apache is the predominant open-source web-server software currently used by Linux systems, including Ubuntu, NGINX continues to rise in popularity. NGINX continues its push with high performance while having a smaller memory footprint and carrying a BSD license. The NGINX server might be included in future releases of the Ubuntu Server and part of the Ubuntu "main" repository...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Hiawatha

    I use the Hiawatha web server myself. Not sure if it's adequate for commercial applications, but fine for a standalone home system. I just use it to test my own web site.

    If you aren't connecting Hiawatha to the web, you can configure it to be inaccessible to the big bad Internet. Just edit file /etc/hiawatha.conf and uncomment the line that says:

    # Interface = 127.0.0.1

    Somewhat related to this topic, it might interest a lot of readers here that there is a serious vulnerability issue that is hitting Linux sites running apache, nginx and lighttpd:



    If you're actually running a server connected to the outside world, I think at a minimum you ought to be running selinux as well. Not 100% sure that would protect the server, but probably would, at least from what I'm reading. This particular vulnerability is not yet fully understood.

    Comment


    • #3
      I like Cherokee, myself. It's a decent little server, and has a nice configuration interface. Can be a little confusing to set up for certain things, but there are helpful tutorials, if you need them. It was sufficient for my tinkering at home, at least.

      Comment


      • #4
        Nginx is a great server for sure.

        As for me, I enjoy by using Nginx on my servers. Why?
        1) Absolutely great at serving static files! After one guy has replaced apache with nginx on his server, I was able to notice speed increase in page load by naked eye. That's because it has been mostly static page. So there was quite a reasonable speedup I can see with naked eye. I have a fast connection. So page no longer has been "loading". It has been literally "shot" into my browser. Quite an impressive effect.
        2) Lower resources usage. It's enough to have cheap microserver/VPS/... to serve quite a lot of stuff. OTOH apache is resource hog and without expensive and powerful server it performs really bad. So apache maybe not so bad for some large corporation who can afford large server farm but it really suxx for anyone on tighter budgets or those who needs more speed. You see, top busiest sites ARE using nginx for a reason. And reason is simple: they can buy far less servers than they have to if they about to handle same load levels with Apache.
        3) As for me, I like Nginx config format more than Apache. Also no stupid .htaccess crap. So no moron extra disk seeks for each and every file server is serving. Maybe not a large prob on SSD but really kills Apache performance once more on mechanic HDDs.
        4) Nginx haves really cool caching system. In many cases you can serve static version of page from cache instead of starting PHP for each and every request. Why re-generate the very same page 1000 times a second if the result is known to be same all the time? And I already told nginx is great at serving static.
        5) Latest versions have some uber-modern features like SPDY and websockets. Something you would really expect from leading server software in year 2013, isn't it?
        6) It's both decent front-end, static uploader and load balancer. It can work as standalone fully featured server, running both PHP and whatever else can use fastcgi/scgi/wsgi/... - it's really nice in smaller installations when server could be both "app server" and "frontend". In larger installations it could do load balance without suffering performance prob's.

        In fact, if you're not dumb, you can easily withstand a serious slashdot effect even on cheap/weak hardware in many cases. As for me, it has got it's popularity on top busiest sites just because it really deserves it. A really decent masterpiece of software.

        It haves some couple of disadvantages.
        1) No dynamic modules loading. Those who needs it could try to look on Tengine, fork of nginx server made by popular chinese Taobao portal. It's a bit lagging behind in terms of versions and features though.
        2) It's devs have quite specific preferences and views.
        Last edited by 0xBADCODE; 29 May 2013, 12:48 AM.

        Comment


        • #5
          Originally posted by SevenOfMine
          Ngninx users have sure been eager to promote it. Sometimes almost too much, I'd say.

          It's easy to sell to an Apache user, but for a lighttpd guy like me - meh, show me some impressive unbiased test results and I'll consider.
          Lighttpd is a worth mention, sure. I even used it for some time for myself. Though obvious disadvantages compared to nginx are:
          1) It can't scale as well as nginx on multiple CPUs. Nginx could launch several workers. Each worker still remains lightweight state machine (just like lighttpd is and unlike apache workers) but then OS could spread them over different CPUs. Lighttpd internally uses some threads but at least (release-quality 1.4) can't scale well in this regard. Though this only matters for really busy sites.
          2) It haves worse flaw. Lighttpd have to cache WHOLE backend response. So if your backend have to upload something large or script has gone mad, lighttpd could consume non-trivial amounts of RAM (equals to response size) and would not return RAM to OS even when request has been served. This is known design issue and will not be not fixed in 1.4.x series.
          3) To make it even more "funny", lighttpd 1.5.x development appears to be completely stuck/abandoned. And lighttpd 2.x not seems to be released anyhow soon. Furthermore, lighty devs have gone mad and dare to require some Gnome parts (glib) on server for 2.x. Kinda weird dependencies for server software, doh. Nginx lacks all those issues and does not needs gnome parts on server...

          Conclusion: major trouble of lighttpd is crappy project management. It's handled by some students and they're not a great PMs at all. So they were #3 with only apache and IIS on top some time before. But thanks to their crappy project management they were outrun by nginx. You see, I need to serve stuff today and it's not like if I could wait for years when such major design flaw as mentioned in 2) will be fixed. Nginx project handling is much better. At least those guys are well aware of what is "production server" and what "dos" and "donts" apply and able to deal with serious issues in more or less timely fashion. Not something lighttpd team could afford. As "bonus", lighty lacks really cool cache system nginx haves. Otherwise it's not so bad server. I used it for some time but then I got some server out of RAM due to runaway script. After reading bug tracker I figured out it will literally take some years or undefined time to get it fixed. OTOH nginx does not attempts to cache whole backend response and rather passes whatever is ready to client. Which is much smarter approach and works better in various situations.
          Last edited by 0xBADCODE; 29 May 2013, 02:13 AM.

          Comment


          • #6
            Just out of curiosity, if someone is already doing a good job on a full Microsoft stack does it make any sense or are there any benefits to use Apache / NGINX / etc over the latest shipping version of IIS?

            Comment


            • #7
              Originally posted by Sonadow View Post
              Just out of curiosity, if someone is already doing a good job on a full Microsoft stack does it make any sense or are there any benefits to use Apache / NGINX / etc over the latest shipping version of IIS?
              You see, neither nginx, nor Linux cost you a single buck on it's own (unless you want some high-quality support or so). And it's a matter of preferences, but from admin's standpoint I would rather configure nginx to run some large PHP app (after all I can google similar config file and fix it in a few minutes to match my needs) rather than configure IIS which is a real pain in the a$$ (as you have to spend half hour on mouse clicking) and another crapload of time to get things like PHP running ("native" stuff like ASP.NET seriousty lacks good webapps, especially free/opensource ones). And if it comes to benchmarks, M$ stack happens to be unimpressive, to say the least. You see, all large M$ downloads are actually served by ... Linux servers of AKAMAI CDN. Ain't this cool? You see, MS haves thier own data centers and could use as many windows copies as they want. And even under these conditions they resort to using Linux servers from AKAMAI CDN. It's really funny to see Linux servers serving M$ downloads, lol.

              Comment


              • #8
                Yay web server thread

                Me, I like monkey. Similar to a properly configured nginx, it scales to the number of cores automatically, while using an event-driven setup like lighty.

                With its embedded focus, it tends to match or outdo nginx in RAM use and static page serving. That focus also means it doesn't do caching, period, leaving that to the far-longer-developed linux FS cache.

                Nginx is a very good server, the only downsides of it to me are bad docs and bad defaults. Even once you configure it to launch N threads, it still doesn't scale, because they default to overzealous locking. Which is a hidden option you have to find out about on the second or third page of google. After disabling that, it finally scales properly to the N threads you set.

                If you have some heavy PHP setup, nginx is probably the best option. But if you can design a site top-to-bottom, you wouldn't use PHP anyway; you'd generate static html pages every time something changes, and have a setup that can withstand slashdotting.

                Comment


                • #9
                  That's interesting information. I am also considering setting up my own server eventually, and since my current website is running on Joomla, I'll want to keep it that way. Which means using Apache or nginx. And so far nginx does sound interesting.

                  Comment


                  • #10
                    Originally posted by curaga View Post
                    With its embedded focus, it tends to match or outdo nginx in RAM use and static page serving.
                    Btw, while nginx could run even on embedded device (I launched it on my phone for fun), it also scales well, so if your project goes big, you will be ready to go big. As it could do load balance to multiple backends, load balancer itself could scale to many CPUs, apply caching on dynamic pages to static versions and so on. So it could withstand impressive load on modern hardware, especially if admin is about to help it a bit. Probably that's why busy sites preferring nginx over anything else these days.

                    That focus also means it doesn't do caching, period, leaving that to the far-longer-developed linux FS cache.
                    Ha-ha, FAIL. Nginx can take backend's response generated by scripts (PHP, perl, .... whatever you use for dynamic page generation) and then cache response on disk as "just file" by using certain rules to select what to cache and how to expire it. Then it could serve it as static page from disk, avoiding costly script re-interpretation, DB calls and so on. And since it great at serving static, it will do great job serving that cached version as well. In some cases this allows to use much less hardware than it would be otherwise. Even if you cache page for just 10 seconds, re-running script in interpreter once per 10 seconts is much easier than running script 1000 times a second when you faced 1000 requests per second from clients. Often it's pointless to re-generate page 1000 times a second if result is known to be the same (or rarely changed). Example: you can usually cache wiki article to static version and do not launch script for each and every request to re-generate article via running script, doing dozen of calls to DB and so on. Since page haven't changed it's just waste of resources. Caveat here is that some users could face stale version of page after editing. So setting up cache could be a bit tricky. However if you manage to use it, you can serve half of planet on fairly weak hardware as long as your bandwidth allows it. You see, it haves nothing to do with Linux FS cache. It's application-level cache to avoid extra calls to dynamic page generation scripts and dynamic page generation is usually major resource hog on modern sites

                    Comment

                    Working...
                    X