Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › nginx or apache: which and reasons why?
New Posts  All Forums:Forum Nav:

nginx or apache: which and reasons why? - Page 3

post #21 of 24
Quote:
Originally Posted by randomizer View Post

Because you are playing to the strengths of two webservers instead of the strengths and "weaknesses" of one. There is obviously an overhead for cache misses compared to simply having Apache handle the request every time, but if 90% of your requests can be served from the cache then you have a large net gain in performance because you don't have to touch your DB. However, that's also why I said that if your pages change often that this is a bad idea. If you are nearly always needing to query your DB anyway then you're simply adding performance and maintenance overhead.

I worked on a site last year that desperately needed something like this (it was built poorly from the start so performance was bad). Unfortunately, while all assets were static (images, styles etc), all but the home page required queries to the DB to update displayed data, and that was what performed the worst (well, that and the bucket loads of JavaScript attached to the stupidest events).

If you do some Googling you wil find some people have received performance improvements of more than an order of magnitude with this setup, but you should always consider your specific situation (as you clearly are). I am not recommending it, I'm just throwing out another option to consider.

Apache itself doesn't touch the DB (that would be your PHP / etc framework), so you can still use Apache for cache and not call any databases. (in fact, that is exactly what we do on our web sites where I work)
post #22 of 24
Sorry, yes, I worded that pretty badly (time for bed methinks smile.gif). However, if you're hitting a DB then you're not serving static content, ergo you would not want to use Nginx but Apache. That was what I was implying, it just got lost in my ramblings.
    
CPUMotherboardGraphicsRAM
i7 920 D0 MSI X58 Pro-E GTX 560 Ti 448 3x2GB G.Skill DDR3-1333 9-9-9-24 
Hard DriveHard DriveOptical DriveOS
840 Pro Caviar Black LG BD-ROM Windows 8.1 Pro x64 
MonitorMonitorKeyboardPower
Dell U2713HM Dell U2311H Turbo-Trak (Google it :D) Corsair HX-520 
CaseMouseMouse PadAudio
CM690 Mionix Avior 7000 Everglide Titan AKG K 242 HD 
  hide details  
Reply
    
CPUMotherboardGraphicsRAM
i7 920 D0 MSI X58 Pro-E GTX 560 Ti 448 3x2GB G.Skill DDR3-1333 9-9-9-24 
Hard DriveHard DriveOptical DriveOS
840 Pro Caviar Black LG BD-ROM Windows 8.1 Pro x64 
MonitorMonitorKeyboardPower
Dell U2713HM Dell U2311H Turbo-Trak (Google it :D) Corsair HX-520 
CaseMouseMouse PadAudio
CM690 Mionix Avior 7000 Everglide Titan AKG K 242 HD 
  hide details  
Reply
post #23 of 24
Quote:
Originally Posted by Plan9 View Post

haha I was puzzled when I (mis)read your post. I literally asked myself how someone who spends their entire working day with web frameworks wasn't aware of caching laugher.gif Sorry about that mate. redface.gif

In answer to your question, I don't really know myself. I can't see the benefit of running both nginx and Apache on the same box either (bar some fringe cases like the server I'm currently building). In your case, it would make more sense to let Apache manage the entire httpd stack.

I think where people talk about nginx in that regard is one of two things:
  1. A free load balancer (not applicable in your case as you only have 1 node)
  2. A replacement for lighttpd for static content (not applicable in your case as you're going to run Apache anyway, so you'd be added to your systems footprint running two httpds)
I appreciate your diplomacy, but compiling and benchmarking Apache is something I do nearly every day for work (it's actually one of my main roles as the sys admin for a smallish datacenter). I've found that the benefits of compiling Apache yourself are minimal and vastly outweighed by the cons:
  • Apache is one of those bits of software where keeping up with patches is paramount. It's significantly easier to do that with the repos than it is if you compile your own build of Apache.
  • To expand a little more on the former point, doing so with next to zero down time is very difficult without a web farm and load balancer (And even then I end up having to install to non-standard directories and using symlinks to perform the switch over).
  • Apache has a number of dependencies, some of which you may end up having to manually compile in addition to Apache (over the years I've ran into issues with zlib and openssl - amongst others that I've since forgotten)
  • Apache has dozens of modules, some included by default, some of which are not. And you really need to know what you want before you start compiling if you want any kind of performance boost (yeah you can compile the modules as shared objects, but then you might as well just use the repos which do the same).
  • To further the above point, by compiling in the modules, you're making it massively harder to disable unused modules (theres a reason why even the Apache devs state that using shared objects is the preferred method for compiling Apache)
  • You're making it dead easy to miss security modules like user sandboxing, which are not compiled in by default.
  • You're responsible for your own testing (STABLE repo's will have tested your Zend / mod_perl / etc VMs against Apache - when I've compiled my own I've found bugs that lead to segfaults in Apache threads (which lead to pages not loading) and those had to be fixed my myself).


Then lets look at the way how Apache works:
  • All you're doing by compiling in your own modules is speeding up the thread creation time, but as threads can handle hundreds of simultaneous HTTP requests and can sit idle when there's no traffic, you're really not going to see any performance increase there unless your servers are hammered (and I mean > thousands of hits a minute) for hours on end. A personal website server would see zero performance increase.
  • Most of the heavy processing in Apache happens in the language interpreters / VMs (eg mod_perl, Zend (PHP), Tomcat (Java servlets), etc). Compiling Apache would have zero performance gains with those VMs.


People really interested in Apache's performance should really be looking at the following:
  • Most people configure their language VMs with sub optimal settings (eg enabling ENVs in mod_perl, not scanning through the php.ini for optimizations, etc) or even using the wrong handlers entirely (eg CGI instead of bespoke mod_perl handlers). These will have a significantly bigger performance impact than compiling your own build of Apache.
  • Also there's many different interpreters for a lot of different languages. eg for PHP there's Zend, which is the most popular PHP engine, but that isn't the fastest. HipHop (facebook's creation) is supposed to offer up to 50% performance increases.
  • But most of the time it's the web developers who have created those bottlenecks (needlessly heavy modularised code - as seen with many popular CMSs, inefficient SQL requests, etc)
  • Sometimes Apache itself hasn't been configured optimally (inefficient threading ratios for that servers hardware, etc). That's a lot harder to configure right though - and often is just trial and error with load testing to benchmark each tweak.
  • Then you have external configuration; (eg static pages held on slower storage mediums, database server not able to handle capacity or badly configured SQL connection pooling, etc). So many people overlook the obvious there. Sometimes even just storing cache on RAM disk can improve the responsiveness of sites.
  • And, if you're really obsessed with going low level, there's a lot that can be done to to streamline Linux's TCP/IP stack for web serving and you'd see bigger improvements than compiling Apache manually. If you're running iptables, I've read that there's a few tweaks that can be done there as well (though I haven't personally tested those tweaks as we have dedicated hardware firewalls).
  • Also, what version of the Linux kernel are you running? some of the newer versions have TCP/IP cookies that are designed to significantly reduce the footprint of TCP handshakes, very handy for web servers (sadly that specific patch requires the client support as well).
  • and lastly, are you even compressing the bloody data (mod_deflate, minified CSS and Javascript, etc)? So many developers and sys admins don't even bother with this step yet it's essentially a free pass for faster page load times.

So, with the greatest of respect, telling someone to compile their own instance of Apache is just terrible advice and overlooks the mass of performance gains that can be achieved without compiling yet introduces a number of new security, potential stability issues as well as diverts peoples valuable free time from focusing on the real bottlenecks within Apache.

Honestly, if we didn't run a bespoke set up in my current work place, even I wouldn't bother compiling Apache. smile.gif

[edit]
Sorry if there's spelling or grammar mistakes, or even if bits read really badly. It's a long post and I should be working (coincidentally, I'm writing a new Nagios plugin to monitor some Apache upgrades as the last few I ran created unexpected conflicts with some existing software) so shamefully I've not bothered to read this back.

I found your post very informative and appreciate the effort you went to in creating it +REP

I will confess that my knowledge of Linux does not stand up to yours, so people should probably trust in your opinion over mine.

I will further research the subject.

However, another advantage to compiling a basic Apache install from source rather than installing via a package manager is that many distros have repos that are severely out of date and I know of several people who would not think to check a thing like that, after all, "the OS thinks it's up to date so it must be"

I'll concede that this is not the most compelling reason though, the main reason I personally compile most of my stuff from source is for fun, though in many cases (not just web servers) there are performance and efficiency gains, especially for esoteric architectures (which I encounter from time to time).
Edited by dushan24 - 3/19/13 at 5:37am
    
CPUMotherboardGraphicsGraphics
Intel Core i7 860 Asus P7P55D-E Pro MSI GTX560 Ti TwinFrozr II MSI GTX560 Ti TwinFrozr II 
RAMHard DriveHard DriveHard Drive
Corsair 8GB DDR3 OCZ Vertex 3 Western Digital Caviar Black Western Digital Caviar Green 
Hard DriveOptical DriveCoolingOS
Samsung 840 Pro Lite-On 24x DVD-RW CoolerMaster V8 Windows 8.1 Professional 
OSMonitorMonitorMonitor
Debian 7.1 Samsung S22B350H Samsung S22B350H Samsung S22B350H 
KeyboardPowerCaseMouse
Ducky Shine II Corsair HX850 CoolerMaster Storm Enforcer Logitech M500 
Mouse PadAudio
Razer Goliathus Microsoft LifeChat LX 3000 
  hide details  
Reply
    
CPUMotherboardGraphicsGraphics
Intel Core i7 860 Asus P7P55D-E Pro MSI GTX560 Ti TwinFrozr II MSI GTX560 Ti TwinFrozr II 
RAMHard DriveHard DriveHard Drive
Corsair 8GB DDR3 OCZ Vertex 3 Western Digital Caviar Black Western Digital Caviar Green 
Hard DriveOptical DriveCoolingOS
Samsung 840 Pro Lite-On 24x DVD-RW CoolerMaster V8 Windows 8.1 Professional 
OSMonitorMonitorMonitor
Debian 7.1 Samsung S22B350H Samsung S22B350H Samsung S22B350H 
KeyboardPowerCaseMouse
Ducky Shine II Corsair HX850 CoolerMaster Storm Enforcer Logitech M500 
Mouse PadAudio
Razer Goliathus Microsoft LifeChat LX 3000 
  hide details  
Reply
post #24 of 24
Quote:
Originally Posted by dushan24 View Post

I found your post very informative and appreciate the effort you went to in creating it +REP

I will confess that my knowledge of Linux does not stand up to yours, so people should probably trust in your opinion over mine.

I will further research the subject.

However, another advantage to compiling a basic Apache install from source rather than installing via a package manager is that many distros have repos that are severely out of date and I know of several people who would not think to check a thing like that, after all, "the OS thinks it's up to date so it must be"

I'll concede that this is not the most compelling reason though, the main reason I personally compile most of my stuff from source is for fun, though in many cases (not just web servers) there are performance and efficiency gains, especially for esoteric architectures (which I encounter from time to time).

Thanks mate smile.gif

With regards to package versions, Apache is one of those packages that is up-to-date on pretty much every distro (it needs to be really). In fact Debian applied the 2.2.20* update before any other distro. So you don't even need to compile to get the latest versions - well, that is unless you want to run the test branch of Apache (odd numbered version numbers) or 2.4. But 2.4 isn't widely supported yet so best avoided (for now) and obviously test builds aren't suitable for production environments.

I do take your point about compiling your own builds for the latest features though - that argument does make sense in some instances, but thankfully Apache is well maintained on distros with even the slower of release cycles.


*the 2.2.20 update addressed a bug where packets of data could be multiplied up within Apache and form a DoS attack - so it was quite a serious security update.
Quote:
Originally Posted by randomizer View Post

Sorry, yes, I worded that pretty badly (time for bed methinks smile.gif). However, if you're hitting a DB then you're not serving static content, ergo you would not want to use Nginx but Apache. That was what I was implying, it just got lost in my ramblings.

Ahh I see what you meant. Sorry mate smile.gif
Edited by Plan9 - 3/19/13 at 5:25pm
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Linux, Unix
Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › nginx or apache: which and reasons why?