() translation by (you can also view the original English article)

Apache vs. Nginx: Mga Bentahe at Disbentahe Para sa Wordpress

Ang mga pangangailangan sa pagganap sa WordPress ay maaaring maiba depende sa mga proyekto, ngunit may isang nananatiling totoo sa lahat ng dako—kinakailangang mabilis ito.

Isa pang pangangailangang hindi na para ibanggit pa—matipid dapat ito, kaya hindi puwedeng magkaroon ng mga mapagkukunang matitinding solusyon. Mga solusyon ay marapat lang na matibay, epektibo at maaasahan, at upang magamit nang buong-buo ang kita sa site, ang paggagastos sa hosting ay dapat panatilihing mababa.

Kung inaasahan mong makatatanggap ka ng maraming trapiko, ang ginagamit mong web server configuration ay may direktang epekto sa pagganap ng iyong site, at apektado ang iyong oras sa pagloload at estabilidad.

Kapag pipili ng web server, marami kang magpagpipilian; Ang Apache, Nginx, IIS, Caddy at Lighttpd ay lahat ng mga tanyag na proyekto. Sasaklawin ang Apache at Nginx sa gabay na ito.

Kinalkula raw na ang buong internet na pinagsama-sama, ang magkasamang Apache at Nginx ang naghahatid ng 50% sa lahat ng trapiko sa web.

Kung ika’y baguhan sa paksang ito, marahil nalilito ka sa dalawang may magkamukhang layunin para sa software—ang maghatid ng mga sites ng web. Umaasa akong malilinaw ko sa ibaba pagkakaiba ng dalawa, at kung paano magamit ang mga bentaha ng bawat katangian ng mga ito.

Ang Apache at Nginx ay mga tunay na mga matatag na mga proyekto, at parehas itong may dahilan kung bakit sila natawag na matatag habang kinakamit lamang ay iisang layuning maghatid ng iyong site sa WordPress. Gayunpaman, kung ating titignan nang maigi ang kanilang mga disenyo, may napakalaking pagkakaiba sa kung paano pinangangasiwaan ang mga koneksyon ng bawat server.

Ang Pagkakaiba

Ang isang malaking pagkakaiba ay kung paano pinangangasiwaan ng dalawang ito ang mga koneksyon.

Para gawin itong mas simple, ang Apache ay gumagamit ng fork threaded na solusyon, o keep-alive, na papanatiling bukas ang koneksyon sa bawat user.

Sa kabilang banda, ang Nginx naman ay gumagamit ng non-blocking event loop, na nagbabakas ng mga koneksyong sabay-sabay gumagana sa pamamagitan ng mga work processes.

Dahil sa gantong arkitektura, ang resulta ay single-threading nginx na proseso at mga dagdag na proseso ay hindi umiikot para pangasiwaan ang bawat bagong koneksyon. Kaya kahit sa mga oras ng mataas na load, ang CPU at RAM ay hindi nabubugbog sa ganitong paraan.

Gayundin sa arkitektura, mayroon ding mga bahagyang pangkakaiba sa pagitan ng dalawa sa configuration, at daraanan natin ang mga ito nang mas detalyado maya-maya sa gabay na ito.

Una, tignan natin ang dalawang mga proyekto, at alamin ang malinaw pangkabuuang-ideya nito.

Apache

Sinimulan ni Robert McCool, isang alumnus sa University of Illinois, noong 1995 na patuloy na yumabong sa ilalim ng Apache Software Foundation magmula noong 1999.
Ang pinakamalawak na ginagamit sa Internet magmula 1996 (default sa maraming mga host gaya ng cPanel users).
Gumagamit ng pangmalawakan, extensible at dinamikang module loading system.
Gumagamit ng .htaccess na file para sa URL rewriting.
Gumagamit ng httpd.conf na file para sa Server Configuration kasama ang isang mala-XML syntax.

Maayos na gumagana ang Wordpress kasama ang Apache gaya ng sabi rito. Isang PHP module gaya ng mod_php ay kailangan, ngunit wala nang masyadong kailangan ito para gumana ito.

Ang Apache ay bumabagay sa iba’t ibang sitwasyon at may maraming module. Karaniwang ginagamit ang mod_rewrite upang makapagbigay ng URL rewriting sa pagbibigay-kahulugan sa mga URL magmula categories.php?id=4 hanggang /categories/4.

Nginx

Sinimulan ni Igor Sysoev, isang Rusong inhinyero ng mga software, bilang solusyon sa problemang C10k—isang pagsubok para sa mga web server na pangasiwaan ang 10,000 na magkakasabay na mga koneksyon.
Nilabas sa publiko noong 2004, kinamit ang layunin na maging makapagsasabay-sabay, non-blocking at event-riven na arkitektura.
Magaang pagpapatakbo sa minimal na hardware ay nakapagbibigay ng mahusay na statik na pangnilalamang pagganap.
Mabilis gumana kahit na mabigat pa ang load.
Gumagamit ng nginx.conf configuration na file kasama ang curly bracket na mala-JS na syntax.
Extensible kasama ang mga third-party na modyul.

Bilang kahalili sa Apache, ang Nginx ay may kapakinabangang alamin ang mga patibong, at sa maaaring mangyaring mga isyu ng pagsasabay-sabay sa pagganap nito, at inaani nito ang lahat ng puwedeng benepisyo gamit ang napakabilis at sabay-sabay na disenyo ng event loop.

Para sa statik na nilalaman, mabilis itong gumagana. Para naman sa dinamikong nilalaman, gaya ng PHP, hindi kaya ng Ningx na i-proseso ito gamit ang modyul gaya ng pagganap ng Apache. Ngunit hindi ito isang balakid sapagkat gumagamit ito ng Fast GCI upang makamit ito. Gumagana ito nang mahusay kapag kasama nito ang mga php fpm connection pool at memcache.

Mga Kailangan sa WordPress

PHP 7 >
MySQL 5.6 o Maria DB 10.0 >
mod_rewrite (kung gumagamit ng Apache)
SSL (kung ginagamit ito)

Ang Apache at Nginx ay magkaparehong sumusuporta sa php fpm. Ito ay ang FastCGI manager, isang forked process manager para sa PHP na magagamit din para makapagbigay ng napakabilis na pagtugon. Tumatakbo bilang isang demonyo sa server, natural na paiikutin nito ang mga kailangang proseso.

Pag-configure ng PHP FPM Gamit ang Apache

Maaaring i-install ng mga gumagamit ng Ubuntu at Debian ang mga kailangang mga paketeng may aptitude sa pamamagitan ng:

1	sudo apt-get -y install libapache2-mod-fastcgi php7.0-fpm php7.0

Paganihin ang modyul sa apache:

1	a2enmod actions fastcgi alias

Matapos nito, sa configuration na file /etc/apache2/conf-available/php7.0-fpm.conf, idagdag ang mga sumusunod:

<IfModule mod_fastcgi.c>
    AddHandler php7-fcgi .php
    Action php7-fcgi /php7-fcgi
    Alias /php7-fcgi /usr/lib/cgi-bin/php7-fcgi
    FastCgiExternalServer /usr/lib/cgi-bin/php7-fcgi -socket /var/run/php/php7.0-fpm.sock -pass-header Authorization
</IfModule>

At sa VirtualHost para sa WordPress (default path /etc/apache2/sites-available/000-default.conf), idagdag ang mga sumusunod:

<Directory /usr/lib/cgi-bin>
    Require all granted
</Directory>
<IfModule mod_fastcgi.c>
    SetHandler php7-fcgi .php
    Action php7-fcgi /php7-fcgi virtual
    Alias /php7-fcgi /usr/lib/cgi-bin/php7-fcgi
    FastCgiExternalServer /usr/lib/cgi-bin/php7-fcgi -socket /var/run/php/php7.0-fpm.sock -pass-header Authorization
</IfModule>

Ngayon, i-restart ang apache, at maaari ka nang tumungo

1	systemctl restart apache2.service

Gumawa ng <?php phpinfo(); ?> na file at tignan sa browser. Ngayon ay pangangasiwaan ng PHP ang FPM.

Ngayon ay tignan uli ang iyong blog sa WordPress. May napapansin ka bang kaibahan?

Ang Pag-configure ng PHP FPM Gamit ang Nginx

Maaaring i-install ng mga gumagamit ng Ubuntu at Debiang ang pakete kasama ang mga sumusunod:

1	apt-get -y install php7.0-fpm

Ngayon, sa loob ng configuration na file (default /etc/nginx/sites-available/default) sa server block, kailangan mong idagdag ang FastCGI configuration parang sa sumusunod:

server {
...
 location / {
    # use try files to try and serve the file
    try_files $uri $uri/ =404;
 }
 
 # PHP FPM Configuration
 location ~ \.php$ {
    include snippets/fastcgi-php.conf;

    # Connect via socket
    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
 }
 
 # deny apache .htaccess requests
 location ~ /\.ht {
  deny all;
 }
 ...
 }

Dito, gagamitin natin ang snippet mula sa Nginx para itakda ang mga cgi parameter at ipasa ang fastcgi sa koneksyon sa socket.

Susunod, siguraduhing tinakda ang cgi.fix_pathinfo=0 sa ini, dahil ang default setting ay sinisira ang configuration. I-edit ang /etc/php/7.0/fpm/php.ini at itakdang:

[...]
; cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI.  PHP's
; previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok
; what PATH_INFO is.  For more information on PATH_INFO, see the cgi specs.  Setting
; this to 1 will cause PHP CGI to fix its paths to conform to the spec.  A setting
; of zero causes PHP to behave as before.  Default is 1.  You should fix your scripts
; to use SCRIPT_FILENAME rather than PATH_TRANSLATED.
; https://php.net/cgi.fix-pathinfo
cgi.fix_pathinfo=0
[...]

Ngayon, puwede ka nang mag-save ng file at uliting i-load ang PHP FPM. Gawin ito sa pamamagitan ng:

1	service php7.0-fpm reload

Panghuli, maaari na nating tignan ang <? phpinfo(); ?> sa isang browser para siguraduhin kung ang server ay ginagamit ang PHP FPM kasama ng Nginx.

Paggawa ng mod_rewrite sa Nginx

Hindi gumagamit ang Nginx ng isang .htaccess na file, at para sa URL rewriting, mayroon itong mas simpleng paraan.

Para paganahin ang WordPress blog kasama ang Nginx, idagdag lang ang mga sumusunod sa bahagi ng try_files ng iyong Nginx confuguration:

1	location / {
2	index index.php index.html index.htm;
3	try_files $uri $uri/ /index.php?q=$uri&$args;
4	}

Kung ikaw ay gumagamit ng direktoryo para sa iyong WordPress blog, pakitakda ang mga sumusunod:

1	location /wordpress/ {
2	try_files $uri $uri/ /index.php?q=$uri&$args;
3	}

I-restart ang Nginx at gagana muli ang URL rewriting.

1	$ service nginx restart

Mga Mainam na Setup

Marami kang pagpipilian para i-optimize ang WordPress sa server gamit memcache, ayusin at pati na rin ang WordPress app level na may mga plugin na makapagpapadali para magamit mo ang mga ito.

Gayunpaman, ang binibigay ng Nginx sa iyo ay magandang solusyon sa pagserve ng statik na nilalaman ng website sa pamamagitang ng matatag at mabilis na statik na content cache.

Statik na Content Cache

Ang Nginx ay napakabilis kapag ginamit bilang isang statik na content cache, at dito makikita ang kahusayan nito sa WordPress at mga blog post na maraming mga larawan. Maaari mong pangasiwaan ang iyong CSS, JS at mga larawan sa pamamagitan lamang ng pagtakbo ng isang server ng Nginx para lang sa mga pangangailangang ito.

Pinakamagandang gawin ito sa may kaunting cookie na domain para tunay ma-cache ng browser ang nilalaman (bilang cookie na hindi cachable), kaya ang paggamit ng subdomin gaya ng images.myblog.com o static.myblog.com ay kakailanganin.

Isang location block para sa mga statik na subdomain configuration ay parang ganito:

    location ~* ^.+\.(?:css|cur|js|jpe?g|gif|htc|ico|png|html|xml|otf|ttf|eot|woff|svg)$ {
        access_log off;
        expires 30d;
        tcp_nodelay off;
        ## Set the OS file cache.
        open_file_cache max=3000 inactive=120s;
        open_file_cache_valid 45s;
        open_file_cache_min_uses 2;
        open_file_cache_errors off;
    }

Gamit ang open_file_cache, ipagana ang caching para sa ating statik na pangmediang mga file. Tutukuyin natin ang bilang ng pinakamaraming file na i-cacache at kung gaano katagal kasama ang open_file_cache max=3000 inactive=120s;

Kung gusto mong i-setup ang caching nang pangmalawakan, dagdagan lang ang mga sumusunod na apat na linya sa iyong mga nginx.conf configuration:

1	open_file_cache max=10000 inactive=5m;
2	open_file_cache_valid 2m;
3	open_file_cache_min_uses 1;
4	open_file_cache_errors on;

Mahalaga: Ang open_file_cache_errors ay i-cacache ang mga totoong 404 na error, kaya mas mabuti na kung patayin na lamang ito kung ikaw ay gumagamit ng load balancer para rito.

Mga PHP-FPM Connection Pool

Posibleng gamitin ang iba’t ibang mga pool para sa bawat magkakaibang WordPress, at malalaan mo na ang iyong mga rekurso nang tamang tama ang bawat site—kahit na gamit ang ibang mga user at grupo para sa bawat pool kung kinakailangan. Magaling ang configuration na ito sa kahit anong sitwasyon.

Maaari kang makapag-setup ng maraming configuration. Halimbawa:

1	/etc/php-fpm.d/family-site.conf
2	/etc/php-fpm.d/travel-blog.conf
3	/etc/php-fpm.d/cooking-recipes.conf

Sa mga sumusunod, puwede nating itakda ang bawat isa nito ng maraming mga configuration gaya nito:

[site]
listen = 127.0.0.1:9000
user = user
group = websites
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slowlog-site.log
listen.allowed_clients = 127.0.0.1
pm = dynamic
pm.max_children = 5
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200
listen.backlog = -1
pm.status_path = /status
request_terminate_timeout = 120s
rlimit_files = 131072
rlimit_core = unlimited
catch_workers_output = yes
env[HOSTNAME] = $HOSTNAME
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp

Gamit ito, matutukoy mo na ang mga mapagpipilian sa PHP-FPM configuration gaya ng pm.max_children, at puwede mo na ring tukuyin ang mga environmental variable at ayusin ang mga setting sa username at mga group dito.

Nginx Load Balancer

Kung makakatanggap ka ng maraming trapiko, kakailanganin mong maghanda ng isang load balancer na gagamitin kasama ang iyong php-fpm na setup.

Kakailanganin mong magsimula ng maraming mga back-end upstream server. Lahat ng mga ito ay sumasalamin sa iyong blog. Magkaroon ng isa pang server-running nginx sa harap nito na gumaganap bilang isang load balancer at ididirekta ang load sa pagitan ng mga upstream.

Ito ay nangangahulugang puwede kang gumamit ng maraming server para paganahin ang iyong blog agad-agad, at para gawin ang configuration ay madali naman.

Isang halimbawa ng configuration ay may ganitong itsura. Magsisimula tayo sa upstream modyul:

upstream backend  {
  server backend1.example.com;
  server backend2.example.com;
  server backend3.example.com;
}

Dito, bawat backend1.example.com ay may sariling Nginx configuration, isang salamin kung ano ito bago pa magkaroon ng load balancer. Pipili ngayon ang Nginx kung anong server ang gagamitin.

Kung ang bawat back end ay may mabilis na hard disk, parang SSD, or ay malapit sa main user base, maaari mong itakda ang weighting parang ganito:

upstream backend  {
  server backend1.example.com weight=1;
  server backend2.example.com weight=2;
  server backend3.example.com weight=4;
}

Kung sa tingin mo rin na maaaring bumaba and server o inaalala ang mga timeout nito, may mga pagpipilian pang configuration para rin dito:

1	upstream backend {
2	server backend1.example.com max_fails=3 fail_timeout=15s;
3	server backend2.example.com weight=2;
4	server backend3.example.com weight=4;

Ngayon, gamit itong configuration, matapos ang 3 pagkakabigo o 15 segundong timeout, ang server ay hindi na gagamitin bilang load balancer. Kung gugustuhin mong isa-isang markahan ang server na hindi aktibo, idagdag ang keyword na down. Halimbawa ay server backend3.example.com down;

Susunod, kailangan nating ipasa ito sa server sa pamamagitang ng isang proxy gamit ang backend upstream na tinukoy bago ito:

 server {
  location / {
    proxy_pass  http://backend;
  }
}

I-restart ang iyong server gamit ang service nginx restart, at napapatakbo mo na ang load-balanced na bersyon ng iyong site!

Panghuli para sa paksang ito, para sa iyong kaalaman, ito ay sang nginx na gabay sa serving static content at ang mga pinakamahuhusay na pagpipilian sa configuration. Alalahanin ang paggamit ng tcp_nopush at sendfile para sa Mp3 bilang halimbawa.

Paglipat ng Apache sa Nginx

Hindi lang sa pagbasa ng Nginx manual at pagbago nito nang sarili mo lang, maaari mo ring gamitin ang open-source tool apache2nginx upang isalin ang configuration mula Apache sa Nginx.

Sundin ang mga hakbang sa installation sa apache2nginx README, at kapag na-install na, kaya mo nang ilipat ang mga configuration na file sa pamamagitang ng pagtakbo ng:

1	$ apache2nginx -f /etc/httpd/conf/httpd.conf

Makikita mo na kung sapat ang configuration, at subukin ito sa installation ng Nginx. Marahil hindi perpekto ang pagsalin, ngunit may mababasehan ka na bilang iyong simula.

Kongklusyon

Para sa bilis at pagganap, halatang mas makabubuti ang Nginx kaysa sa Apache, ngunit hindi ibig sabihin nitong hindi kayang pangasiwaan ng Apache ang trapiko. Kung pinaplano mong pumunta sa pinakaharap na page ng Reddit, kakailanganin mong maghanap ng mas mahirap sa solusyon gamit ang Nginx at PHP-FPM.

Ang paglipat ng WordPress papuntang Nginx ay hindi masyadong mahirap, at ang configuration papuntang Nginx ay simple lang at madaling magamit kumpara sa Apache.

Kahit hindi magkapareho ang mga modyul nito sa Apache, at hindi ka pa sanay rito, mahahanap mo rin ang mga ipapampalit mo sa maraming sitwasyon. Kung hindi, bilang solusyon, puwede mo namang i-proxy ang luma mong server gamit ang Nginx para sa dahilang ito.

Maraming mga paraan upang ma-configure ang parehas na server, kaya ang pinakamabuting solusyon dito ay mahahanap mo kung ano ang mga sinabing pangangailangan nito. Sa ngayon, mukhang Apache ang default na opsyon sa pangmalawakang hosting software na cPanel, dahil ang EasyApache setup tool ay kasama rito.

Sa susunod, baka maraming mga host pa ang kumuha ng Nginx cPanel gaya ng Engintron na nagbibigay ng Nginx sa cPanel din.

Pero sa ngayon, kung gugustuhin mong gamitin ang WordPress na pinatibay ng Nginx, kailangan mong i-setup ang Linux VPN sa DigitalOcean, AWS o ibang hosting provider.