The
Apache
HTTP
Server
Project
is
a
collaboraEve
soFware
development
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
Nginx
(engine
x)
is
a
HTTP
and
reverse
proxy
server,
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
Problems
of
Apache
and
Nginx
Apache
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
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.
Configuring
Nginx
user
www-‐data
www-‐data;
worker_proccesses
5;
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
PHP
is
not
available
by
default,
instead
an
apache
library
“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
Again,php
not
available
by
default
and
unlike
apache
where
php
is
embedded,
PHP
needs
to
run
as
a
separate
process,
thankfully
with
php-‐fpm
(available
aFer
5.3.3)
we
can
do
this
Nginx
Sewng
CPU
affinity
basically
means
you
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.
Though
access
and
error
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.
One
of
the
most
important
things
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
mitsuaki96
tsutaj
kumamatsu
victorrentea
kadogen_0527
nenonaninu
shin_higuchi
yayoi_dd
sinsoku
goyoki
yoshikikomoriya
ryomaru0825
brianwarren
philnash
malarkey
reverentgeek
mclloyd
zenorocha
rmw
productmarketing
notwaldorf
jacobian
eileencodes
lauravandoore