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...

    http://www.phoronix.com/vr.php?view=MTM4MDI

  • #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:

    http://arstechnica.com/security/2013...-lighttpd-too/

    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; 05-29-2013, 12:48 AM.

        Comment


        • #5
          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.

          Comment


          • #6
            Originally posted by SevenOfMine View Post
            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; 05-29-2013, 02:13 AM.

            Comment


            • #7
              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


              • #8
                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


                • #9
                  Originally posted by 0xBADCODE View Post
                  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.
                  Hehe f*k it, I'll go ahead and try it in my next installation.

                  I have to concur with Lighty's development being a tad slow when everything around it has evolved. Performance is still on par with the other top players, but considering the future, maybe it'll be worth checking out Nginx rather earlier than later.

                  Comment


                  • #10
                    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


                    • #11
                      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


                      • #12
                        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


                        • #13
                          What you're describing is an awkward workaround to improper site design. For the proper way to do that (generate static pages in the first place), see my previous post.

                          The web server has no knowledge of when things need to be refreshed. If your site is properly designed, you can trigger the refresh properly, instead of some timeout that's bound to be always wrong/non-optimal.

                          Comment


                          • #14
                            Originally posted by curaga View Post
                            What you're describing is an awkward workaround to improper site design. For the proper way to do that (generate static pages in the first place), see my previous post.
                            Reminds me of this:

                            "There are only two hard problems in Computer Science:cache invalidation and naming things." -- Phil Karlton

                            Have you ever tried your above-mentioned strategy? I once shared your view, but there are a couple of reasons why it may not be practical in many situations:

                            - you need to model dependencies accurately, if you fuck up, you're in trouble

                            - if you need to customize pages based on the visitors, this is easy to do in the JIT model, you just bypass the cache, but harder to do in a statically-compiled model

                            - if you have a sidebar with aggregated info on all pages, you can't assemble the finished pages, else you'll have to regenerate all pages everytime the aggregated info changes; this adds complexity

                            - integrating POSTs and form handling can end up being awkward, unless you mix the two approaches; this also adds complexity

                            I'm not saying static compilation is stupid or impossible, it just has its own set of constraints and in many situations it's probably not worth it compared to just slapping a simple cache in front. If you do that and have < 100 pages, you can cache them for 10 seconds and get at most 10 req/s to the backend. Even a small VPS should be able to handle 10 req/s.

                            Comment


                            • #15
                              Originally posted by curaga View Post
                              What you're describing is an awkward workaround to improper site design.
                              This is debatable IMO. You see, fast state machine written in C which does caching could show very impressive speeds, much higher than any script language could ever dream to have. The only option I see is that some script backend could bother self to handle caching and dependencies, but then either it still have to interact with fast C frontend to serve it or it will be much slower. Not to mention this approach only works for things written from scratch where programmer is explicitly aware of this requirement. This implies that this approach is only going to work for few custom-designed high-load projects when you have a lot of bucks to pay for such very custom software implemtation, made for you and your requirements exclusively. This is a way too expensive and time consuming option in many cases.

                              For the proper way to do that (generate static pages in the first place), see my previous post.
                              Bah, this world is not ideal. We're living in some real world and have to deal with it. As it is. With all shortcomings. Sure, in ideal world you can just go on and rewrite thing like MediaWiki. In real world it would take a way too much time/$$$/efforts to do something comparable in terms of features, etc. That's why I like nginx. It does not learns me to live properly in abstract ideal world. It allows me to achieve my goals in real world with reasonable efforts. Maybe sometimes it's a bit hackish or something. But at the end of day it's achieved goal and not "proper design" what counts. And I don't have to rewrite everything from scratch. Which saves me a really decent amount of time and bucks.

                              The web server has no knowledge of when things need to be refreshed. If your site is properly designed, you can trigger the refresh properly, instead of some timeout that's bound to be always wrong/non-optimal.
                              This is correct statement and taking this effect into account could be some challenge. System administrator must be explicitly aware of this shortcoming when using this feature. However, it still works for many types of already existing web software and does it quite well. Sure, you will have trouble caching, say, user's shopping cart page this way and it would cause numerous troubles. But, say, it would work like a charm for wiki article. And if caching is short enough, nobody would even notice that there is caching is in effect. Yet it will handle "hot spots" and server could easily handle "slashdot effect" on modest hardware. So unlike your solution for ideal world, Nginx would work in real world, here and now. With already existing software. That's what makes it especially valuable ally on my side.
                              Last edited by 0xBADCODE; 05-29-2013, 06:33 PM.

                              Comment

                              Working...
                              X