effort aimed at creaEng a robust, commercial-‐grade, featureful, and freely-‐ available source code implementaEon of an HTTP (Web) server In 2009 it became the first web server to power over 100 million sites First released in 1995, Apache is based on public domain HTTP daemon developed by Rob McCool at the NaEonal Center for SupercompuEng ApplicaEons, University of Illinois About Apache
as well as a mail proxy server nginx is the 3nd most popular web server (2nd is IIS) and powers sites such as ne[lix and wordpress.com Released in 2004 by Igor Sysoev, nginx provides a unique combinaEon of web server, caching proxy and load balancing soluEons to any web site that just wants to be consistently efficient. About Nginx
Can be a bit of a memory hog on high traffic sites loss of .htaccess. Making Nginx not a good ideal soluEon for shared hosEng, there is no alternaEve at the Eme of this presentaEon Has 6 million opEons but you only need 5 Complete hands off approach to all dynamic scripEng languages ie: PHP, Ruby. (This an also be considered a benefit) Has difficulty handling large concurrent connecEons as well as nginx Doesn’t have as many features of Apache Will always load mod_php into memory even if its only for an image request Very li5le 3rd party modules
DocumentRoot /www/example1 ServerName www.example.com </VirtualHost> <VirtualHost *:80> DocumentRoot /www/example2 ServerName www.example.org </VirtualHost> Full list of direcEves can be found at h5p://h5pd.apache.org/docs/2.2/mod/direcEves.html Apache is configured by placing direcEves in plain text configuraEon files. The main configuraEon file is usually called h5pd.conf.
events { worker_connecEons 1024; } h5p { server { listen 80; server_name www.domain.com; index index.html; root /home/domain.com; } } FantasEc list of nginx configuraEons and user submi5ed example configuraEons can be found at h5p://wiki.nginx.org/ConfiguraEon List of all direcEves can be found at h5p://wiki.nginx.org/DirecEveIndex
./configure –with-‐apxs2=/usr/local/apache2/bin/apxs -‐-‐with-‐mysql make make install For obvious reasons we need php, it is strongly recommended you have a plan, ie installing php with nginx or apache, especially if installing php from source as you will need to recompile php if you missed something ie –enable-‐fpm if using nginx or –with-‐apxs2 for apache
“libapache2-‐mod-‐php5” is needed to run PHP scripts or we can compile the mod_php module from source but only if shared modules is enabled on apache Apache apt-‐get install libapache2-‐mod-‐php5 // Apache ./configure -‐-‐enable-‐so make make install //PHP ./configure –with-‐apxs2=/usr/local/apache2/bin/apxs -‐-‐with-‐mysql make make install
is embedded, PHP needs to run as a separate process, thankfully with php-‐fpm (available aFer 5.3.3) we can do this Nginx locaEon ~ \.php$ { fastcgi_pass unix:/usr/local/var/run/php-‐fpm.socket; // or fastcgi_pass 127.0.0.1:9000 } apt-‐get install php5-‐fpm Or ./configure –enable-‐fpm make make install
tell each worker which CPU core to use, they’ll then use only that CPU core. But your OS cpu is far be5er at handling load balancing than you so best pracEce is to not touch it tcp_nodelay and tcp_nopush These two direcEves are probably some of the most difficult to understand as they affect Nginx on a very low networking level. The very short and superficial explanaEon is that these direcEves determine how the OS handles the network buffers and when to flush them to the end user. I can only recommend that if you do not know about these already then you shouldn’t mess with them. They won’t significantly improve or change anything so best to just leave them at their default values.
logs can be useful for staEsEcs, error checking etc, it can be quite IO intensive so try not to access logs to images or resources in general, just make It log page requests. tcp_nodelay and tcp_nopush These two direcEves are probably some of the most difficult to understand as they affect Nginx on a very low networking level. The very short and superficial explanaEon is that these direcEves determine how the OS handles the network buffers and when to flush them to the end user. I can only recommend that if you do not know about these already then you shouldn’t mess with them. They won’t significantly improve or change anything so best to just leave them at their default values.
you need to tweak is the buffer sizes you allow Nginx to use. If the buffer sizes are set too low Nginx will have to store the responses from upstreams in a temporary file which causes both write and read IO, the more traffic you get the more of a problem this becomes. client_body_buffer_size is the direcEve which handles the client request buffer size, meaning the incoming request body. This is used to handle POST data, meaning form submissions, file uploads etc. You’ll want to make sure that the buffer is large enough if you handle a lot of large POST data submissions. fastcgi_buffers and proxy_buffers are the direcEves which deal with the response from your upstream, meaning PHP, Apache or whatever you use. The concept is exactly the same as above, if the buffers aren’t large enough the data will be saved to disk before being served to the user. NoEce that there is an upper limit for what Nginx will buffer, even on disk, before it transfer it synchronously to the client. This limit is governed by fastcgi_max_temp_file_size as well as proxy_max_temp_file_size. In addiEon you can also turn it off enErely for proxy connecEons with proxy_buffering set to off. (Usually not a good idea!)
colby
kamina_zzz
ohnoeight
4su_para
nobutomurata
oracle4engineer
yoshidashingo
tohutohu
iotengineer22
wa6sn
kazuhitotakahashi
minorun365
aki_iinuma
bermonpainter
danielanewman
garrettdimon
paigeccino
brad_frost
bkeepers
keithpitt
trallard
chriscoyier
destraynor
jacobian
