WordPress 성능 향상을 위한 9가지 팁
WordPress 는 전 세계에서 웹사이트 제작 및 웹 애플리케이션 전송을 위한 가장 큰 플랫폼 중 하나입니다. 현재 전체 사이트의 약 4분의 1이 Open Source WordPress 소프트웨어로 구축되었으며, 여기에는 eBay, Mozilla, RackSpace, TechCrunch, CNN, MTV, New York Times, Wall Street Journal 등의 사이트가 포함됩니다.
사용자 제작 블로그로 가장 인기 있는 사이트인 WordPress.com은 WordPress Open Source 소프트웨어에서 실행됩니다. NGINX는 WordPress.com을 구동합니다. WordPress 고객 중 많은 사이트가 WordPress.com에서 시작한 다음 호스팅되는 WordPress Open Source 소프트웨어로 전환하며, 이러한 사이트 중 점점 더 많은 사이트가 NGINX 소프트웨어를 이용하고 있습니다.
WordPress의 매력은 최종 사용자와 구현 모두에 있어 간편하다는 점입니다. 하지만 WordPress 사이트의 아키텍처는 사용량이 증가할 때 문제가 발생하는데, 캐싱과 WordPress와 NGINX의 결합을 포함한 몇 가지 단계를 통해 이러한 문제를 해결할 수 있습니다.
이번 포스트에서는 일반적인 WordPress 성능 문제를 극복하는 데 도움이 되는 9가지 성능 팁을 제공합니다.
목차
1. LAMP 사이트에서의 WordPress 성능
2. 팁 1 – WordPress 정적 리소스 캐시
3. 팁 2 – 동적 파일 캐시
4. 팁 3 – NGINX로 전환
5. 팁 4 – NGINX에 Permalink 지원 추가하기
6. 팁 5 – FastCGI용 NGINX 구성
7. 팁 6 – W3 Total 캐시에 대한 NGINX 구성
8. 팁 7 – WP Super 캐시용 NGINX 구성
9. 팁 8 – NGINX 구성에 보안 예방 조치 추가
10. 팁 9 – WordPress 멀티사이트에 NGINX 사용
11. NGINX 성능 향상 결론
1. LAMP 사이트에서의 WordPress 성능
대부분의 WordPress 사이트는 전통적인 LAMP 소프트웨어 스택에서 실행됩니다: 운영체제로는 리눅스, 웹 서버로는 Apache HTTP 서버, 데이터베이스 소프트웨어로는 MySQL(종종 별도의 데이터베이스 서버에 있습니다), 프로그래밍 언어로는 PHP가 사용됩니다. 이들 각각은 매우 잘 알려져 있고 널리 사용되는 Open Source 도구입니다. WordPress 세계에서는 대부분의 사람들이 LAMP를 사용하기 때문에 도움과 지원을 쉽게 받을 수 있습니다.
사용자가 WordPress 사이트를 방문하면 Linux/Apache 조합을 실행하는 브라우저는 사용자당 6~8개의 연결을 생성합니다. 사용자가 사이트를 이동하면 PHP가 각 페이지를 즉석에서 조립하여 MySQL 데이터베이스에서 리소스를 가져와 요청에 응답합니다.
LAMP 스택은 몇 명에서 수백 명에 이르는 사용자가 동시에 접속하는 경우에도 잘 작동합니다. 그러나 트래픽이 갑자기 증가하는 것은 온라인에서 흔한 일이며 일반적으로는 좋은 현상입니다.
그러나 동시 사용자 수가 수백 또는 수천 명으로 증가하여 LAMP 스택 사이트가 바빠지면 심각한 병목 현상이 발생할 수 있습니다. 병목 현상의 주요 원인은 크게 두 가지입니다.
- Apache 웹 서버 – Apache는 모든 연결마다 상당한 리소스를 소비합니다. Apache가 너무 많은 동시 연결을 허용하면 메모리가 고갈되고 데이터를 디스크로 페이징해야 하므로 성능이 느려질 수 있습니다. 응답 시간을 보호하기 위해 연결을 제한하면 새 연결이 대기해야 하므로 사용자 경험도 저하됩니다.
- PHP/MySQL 상호 작용 – PHP를 실행하는 애플리케이션 서버와 MySQL 데이터베이스 서버를 함께 사용하면 초당 최대 요청 수를 처리할 수 있습니다. 요청 수가 최대치를 초과하면 사용자는 대기해야 합니다. 최대치를 비교적 적은 양만 초과해도 모든 사용자의 응답 속도가 크게 느려질 수 있습니다. 최대치를 두 배 이상 초과하면 심각한 성능 문제가 발생할 수 있습니다.
LAMP 사이트의 성능 병목 현상은 특히 더 많은 CPU, 더 많은 디스크 공간 등 더 강력한 하드웨어로 업그레이드하는 일반적인 본능적 대응에 저항합니다. 하드웨어 성능의 점진적인 증가는 Apache와 PHP/MySQL 조합이 과부하될 때 생성되는 시스템 리소스에 대한 기하급수적인 수요 증가를 따라잡을 수 없습니다.
LAMP 스택을 대체할 수 있는 대표적인 스택은 다음과 같습니다(Linux, NGINX, MySQL 및 PHP). (LEMP 약어에서 E는 “engine-x”의 시작 부분의 소리를 나타냅니다.) LEMP 스택에 대해서는 팁 3에서 설명합니다.
2. 팁 1 – WordPress 정적 리소스 캐시
정적 리소스는 CSS 파일, JavaScript 파일, 이미지 파일과 같이 변경되지 않는 파일입니다. 이러한 파일은 웹 페이지에서 데이터의 절반 이상을 차지하는 경우가 많습니다. 페이지의 나머지 부분은 커뮤니티의 댓글, 실적 대시보드 또는 개인화된 콘텐츠(예: Amazon.com 제품 추천)와 같이 동적으로 생성되는 콘텐츠입니다.
정적 리소스를 캐싱하면 두 가지 큰 이점이 있습니다.
사용자에게 더 빠른 전송 – 사용자는 브라우저 캐시 또는 인터넷에서 가까운 캐싱 서버에서 정적 파일을 가져옵니다. 이러한 파일은 대용량 파일인 경우가 많으므로 이러한 파일에 대한 지연 시간을 줄이면 많은 도움이 됩니다.
애플리케이션 서버의 부하 감소 – 캐시에서 검색되는 모든 파일은 웹 서버가 처리해야 하는 요청이 하나 줄어드는 것입니다. 캐시를 많이 캐싱할수록 리소스가 부족해서 발생하는 스래싱을 방지할 수 있습니다.
브라우저 캐싱을 지원하려면 정적 파일에 올바른 HTTP 헤더를 설정하세요. HTTP Cache-Control 헤더, 특히 max-age 설정, Expires 헤더, Entity 태그를 살펴보세요. KeyCDN 블로그에서 좋은 소개를 찾아볼 수 있습니다.
로컬 캐싱이 활성화되어 있고 사용자가 이전에 액세스한 파일을 요청하면 브라우저는 먼저 해당 파일이 캐시에 있는지 확인합니다. 그리고 파일이 캐시에 있다면 웹 서버에 파일 변경 여부를 묻습니다. 파일이 변경되지 않은 경우 웹 서버는 코드 200 확인을 반환한 다음 변경된 파일을 검색하여 전달하는 대신 파일이 변경되지 않았다는 의미의 코드 304( Not Modified)로 즉시 응답할 수 있습니다.
브라우저 이외의 캐싱을 지원하려면 아래 팁을 참조하고 콘텐츠 전송 네트워크(CDN)를 고려하세요. CDN은 캐싱을 위한 인기 있고 강력한 도구이지만 여기서는 자세히 설명하지 않습니다. 여기에 언급된 다른 기술을 구현한 후에 CDN을 고려하세요. 또한 사이트를 HTTP/1.x에서 새로운 HTTP/2 표준으로 전환할 때 CDN의 유용성이 떨어질 수 있으므로 필요에 따라 조사하고 테스트하여 사이트에 적합한 해답을 찾아야 합니다.
팁 3에서 제안한 대로 소프트웨어 스택의 일부로 NGINX Plus 또는 NGINX Open Source로 이동하는 경우, 정적 리소스를 캐시하도록 NGINX를 구성하세요. 다음 구성이 좋은 시작점이며, www.example.com 을 웹 서버의 URL로 바꾸고 다른 경로명으로 적절히 수정하세요.
server {
# substitute your web server's URL for www.example.com
server_name www.example.com;
root /var/www/example.com/htdocs;
index index.php;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri =404;
include fastcgi_params;
# substitute the socket, or address and port, of your WordPress server
fastcgi_pass unix:/var/run/php5-fpm.sock;
#fastcgi_pass 127.0.0.1:9000;
}
location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg
|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid
|midi|wav|bmp|rtf)$ {
expires max;
log_not_found off;
access_log off;
}
}3. 팁 2 – 동적 파일 캐시
WordPress는 동적으로 웹 페이지를 생성하므로 요청이 있을 때마다(결과가 이전과 동일하더라도) 지정된 웹 페이지를 생성합니다. 따라서 사용자는 항상 가장 최신의 콘텐츠를 볼 수 있습니다.
포스트 하단에 댓글이 활성화된 블로그 포스트를 이용하는 사용자를 생각해 보세요. 사용자가 방금 전에 들어온 댓글을 포함하여 모든 댓글을 볼 수 있기를 원할 것입니다. 각 요청에 대해 콘텐츠를 동적으로 재생성하면 이를 실현할 수 있습니다.
하지만 이제 블로그 포스트에 초당 10~20건의 요청이 들어온다고 가정해 봅시다. 애플리케이션 서버는 페이지를 자주 재생성해야 한다는 압박감에 시달리기 시작하여 큰 지연이 발생할 수 있습니다. 신규 방문자에게 최신 콘텐츠를 제공한다는 목표는 이론적으로만 의미가 있을 뿐, 방문자가 처음에 페이지를 보기 위해 너무 오래 기다려야 하기 때문입니다.
로드 증가로 인해 페이지 전송 속도가 느려지는 것을 방지하려면 동적 파일을 캐시합니다. 이렇게 하면 파일은 덜 동적이지만 전체 시스템의 응답성이 향상됩니다.
WordPress에서 캐싱을 사용하려면 아래에 설명된 몇 가지 인기 플러그인 중 하나를 사용하세요. WordPress 캐싱 플러그인은 새 페이지를 요청한 다음 몇 초 정도의 짧은 시간 동안 페이지를 캐시에 저장합니다. 따라서 사이트에서 초당 여러 요청을 받는 경우 대부분의 사용자는 캐시에서 페이지 사본을 가져옵니다. 이는 모든 사용자의 검색 시간을 단축하는 데 도움이 됩니다:
- 대부분의 사용자는 페이지의 캐시된 사본을 얻습니다. 애플리케이션 서버는 전혀 작동하지 않습니다.
- 새 사본을 받는 사용자는 빠르게 받아볼 수 있습니다. 애플리케이션 서버는 가끔씩만 새 페이지를 생성하면 됩니다. 서버가 새 페이지를 생성할 때(캐시된 페이지가 만료된 후 처음 오는 사용자를 위해) 요청으로 과부하가 걸리지 않기 때문에 훨씬 더 빠르게 생성됩니다.
LAMP 스택 또는 LEMP 스택에서 실행되는 WordPress용 동적 파일을 캐싱할 수 있습니다(팁 3에 설명되어 있음). WordPress에서 사용할 수 있는 캐싱 플러그인은 여러 가지가 있습니다. 다음은 가장 간단한 것부터 가장 강력한 것까지 가장 많이 사용되는 캐싱 플러그인과 캐싱 기술을 나열한 것입니다.
- Hyper-Cache – 각 WordPress 페이지 또는 글에 대해 단일 PHP 파일을 생성합니다. 이 옵션은 WordPress 핵심 처리와 데이터베이스 연결을 우회하면서 일부 동적 기능을 지원하므로 사용자 환경이 더 빨라집니다. 모든 PHP 처리를 우회하는 것은 아니므로 다음 옵션과 같은 성능 향상을 제공하지는 않습니다. 반면에 NGINX 구성을 변경할 필요가 없다는 장점도 있습니다.
- WP Super Cache – WordPress에서 가장 인기 있는 캐싱 플러그인입니다. 아래 그림과 같이 사용하기 쉬운 인터페이스를 통해 제공되는 다양한 설정이 있습니다. 팁 7에서 샘플 NGINX 구성을 보여드리겠습니다.
- W3 Total Cache – WordPress에서 두 번째로 인기 있는 캐시 플러그인입니다. WP Super Cache보다 훨씬 더 많은 옵션 설정이 있어 강력하지만 다소 복잡한 옵션입니다. NGINX 구성 샘플은 팁 6을 참조하세요.
- FastCGI – CGI는 인터넷에서 파일을 요청하고 수신하는 언어 중립적인 방법인 Common Gateway Interface의 약자입니다. FastCGI는 플러그인이 아니라 캐시와 상호 작용하는 방법입니다. FastCGI는 Apache뿐만 아니라 가장 널리 사용되는 동적 캐싱 접근 방식인 NGINX에서도 사용할 수 있으며, 이를 사용하도록 NGINX를 구성하는 방법은 팁 5에서 설명합니다.
이러한 플러그인 및 기술에 대한 설명서는 일반적인 LAMP 스택에서 이를 구성하는 방법을 설명합니다. 구성 옵션에는 데이터베이스 및 객체 캐싱, HTML, CSS 및 JavaScript 파일 축소, 인기 있는 CDN에 대한 통합 옵션이 포함됩니다. NGINX 구성에 대해서는 목록에 참조된 팁을 참조하세요.
Note: WordPress에 로그인한 사용자에게는 캐시가 작동하지 않습니다. WordPress 페이지 보기가 개인화되어 있기 때문입니다. (대부분의 사이트에서 로그인한 사용자는 극소수에 불과합니다.) 또한 최근에 댓글을 남긴 사용자는 페이지를 새로 고칠 때 자신의 댓글이 표시되기를 원하기 때문에 대부분의 캐시에서는 캐시된 페이지를 표시하지 않습니다. 페이지의 개인화되지 않은 콘텐츠를 캐싱하려면 전체 성능에 중요한 경우 fragment caching이라는 기술을 사용할 수 있습니다.
4. 팁 3 – NGINX로 전환
위에서 언급했듯이 Apache는 동시 사용자 수가 특정 지점(예: 수백 명의 동시 사용자) 이상으로 증가하면 성능 문제를 일으킬 수 있습니다. Apache는 각 연결에 상당한 리소스를 할당하므로 메모리가 부족해지는 경향이 있습니다. 메모리가 고갈되지 않도록 연결을 제한하도록 Apache를 구성할 수 있지만, 제한을 초과하면 새로운 연결 요청이 대기해야 합니다.
또한 Apache는 정적 파일(이미지, CSS, JavaScript 등)만 제공하는 경우에도 모든 연결에 대해 mod_php 모듈의 또 다른 복사본을 메모리에 로드합니다. 이렇게 하면 각 연결마다 더 많은 리소스가 소모되고 서버의 용량이 더욱 제한됩니다.
이러한 문제를 해결하려면 LAMP 스택에서 LEMP 스택으로 이동하여 Apache를 (e)NGINX로 교체하세요. NGINX는 고정된 메모리 공간에서 수천 개의 동시 연결을 처리하므로 스래싱을 경험하거나 동시 연결을 적은 수로 제한할 필요가 없습니다.
또한 NGINX는 쉽게 조정할 수 있는 내장 캐싱 컨트롤을 통해 정적 파일을 더 잘 처리합니다. 애플리케이션 서버의 부하가 줄어들고 사이트가 훨씬 더 많은 트래픽을 처리하여 사용자에게 더 빠르고 즐거운 경험을 제공할 수 있습니다.
배포의 모든 웹 서버에서 NGINX를 사용할 수도 있고, Reverse Proxy로 Apache의 앞에 NGINX 서버를 배치할 수도 있습니다. NGINX 서버는 클라이언트 요청을 수신하고, 정적 파일을 제공하며, PHP 요청을 Apache로 전송하여 이를 처리합니다.
동적으로 생성된 페이지의 경우 – WordPress 경험의 핵심 사용 사례인 팁 2에 설명된 대로 캐싱 도구를 선택하세요. 아래 팁에서 FastCGI, W3 Total Cache 및 WP Super Cache에 대한 NGINX 구성 제안을 확인할 수 있습니다. (Hyper-Cache는 NGINX 구성을 변경할 필요가 없습니다.)
Tip. 캐시는 일반적으로 디스크에 저장되지만 tmpfs를 사용하여 메모리에 캐시를 저장하고 성능을 향상시킬 수 있습니다.
WordPress용 NGINX 설정은 간단합니다. 다음 네 단계를 따르기만 하면 됩니다.
- Permalink 지원 추가 – Permalink 지원을 NGINX에 추가합니다. 이렇게 하면 Apache 전용인
.htaccess구성 파일에 대한 의존성을 제거할 수 있습니다. 팁 4를 참조하세요. - 캐싱 구성 – 캐싱 도구를 선택하고 구현합니다. 선택할 수 있는 캐싱 도구로는 FastCGI Cache, W3 Total Cache, WP Super Cache, Hyper Cache 등이 있습니다. 팁 5, 6, 7을 참조하세요.
- 보안 예방 조치 구현 – NGINX에서 WordPress 보안 모범 사례를 채택하세요. 팁 8을 참조하세요.
- WordPress 멀티사이트 구성 – WordPress 멀티사이트를 사용하는 경우 하위 디렉터리, 하위 도메인 또는 다중 도메인 아키텍처에 맞게 NGINX를 구성하세요. 팁 9를 참조하세요.
5. 팁 4 – NGINX에 Permalink 지원 추가하기
많은 WordPress 사이트는 Permalink 지원, 플러그인, 파일 캐싱 등 여러 WordPress 기능에 필요한 .htaccess 파일에 의존합니다. NGINX는 .htaccess 파일을 지원하지 않습니다. 다행히도 NGINX의 간단하면서도 포괄적인 구성 언어를 사용하여 대부분의 동일한 기능을 구현할 수 있습니다.
메인 server 블록에 다음 location 블록을 포함하면 WordPress에서 Permalink를 활성화할 수 있습니다. (이 location 블록은 아래의 다른 코드 샘플에도 포함되어 있습니다.)
try_files 지시문은 요청된 URL이 문서 root인 /var/www/example.com/htdocs에 파일($uri) 또는 디렉터리($uri/)로 존재하는지를 NGINX에 확인하도록 요청합니다. 그렇지 않은 경우 NGINX는 Query 문자열 인수를 매개변수로 전달하여 /index.php로 리다이렉트합니다.
server {
server_name example.com www.example.com;
root /var/www/example.com/htdocs;
index index.php;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
location / {
try_files $uri $uri/ /index.php?$args;
}
}6. 팁 5 – FastCGI용 NGINX 구성
NGINX는 PHP와 같은 FastCGI 애플리케이션의 응답을 캐시할 수 있습니다. 이 방법은 최고의 성능을 제공합니다.
NGINX Open Source의 경우 캐시 Purge 기능을 제공하는 타사 모듈 ngx_cache_purge를 컴파일하고 아래 구성 코드를 사용합니다. NGINX Plus에는 이 코드의 자체 구현이 내장되어 있습니다.
FastCGI를 사용할 때는 WordPress의 NGINX Helper 플러그인을 설치하고 아래와 같은 구성을 사용하는 것이 좋습니다(fastcgi_cache_key 및 fastcgi_cache_purge를 포함한 location 블록이 특히 관련성이 높습니다). 플러그인은 페이지 또는 글이 게시 또는 수정되거나 새 댓글이 게시되거나 WordPress 관리자 대시보드에서 캐시를 수동으로 비워야 할 때 자동으로 캐시를 비웁니다.
NGINX Helper 플러그인은 페이지 하단에 짧은 HTML Snippet을 추가하여 캐시가 작동 중인지 확인하고 몇 가지 통계를 표시할 수도 있습니다. ($upstream_cache_status 변수를 사용하여 캐시가 제대로 작동하는지 확인할 수도 있습니다.)
fastcgi_cache_path /var/run/nginx-cache levels=1:2
keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
server {
server_name example.com www.example.com;
root /var/www/example.com/htdocs;
index index.php;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
set $skip_cache 0;
# POST requests and URLs with a query string should always go to PHP
if ($request_method = POST) {
set $skip_cache 1;
}
if ($query_string != "") {
set $skip_cache 1;
}
# Don't cache URIs containing the following segments
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php
|sitemap(_index)?.xml") {
set $skip_cache 1;
}
# Don't use the cache for logged-in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass
|wordpress_no_cache|wordpress_logged_in") {
set $skip_cache 1;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri /index.php;
include fastcgi_params;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 60m;
}
location ~ /purge(/.*) {
fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
}
location ~* ^.+.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg
|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi
|wav|bmp|rtf)$ {
access_log off;
log_not_found off;
expires max;
}
location = /robots.txt {
access_log off;
log_not_found off;
}
location ~ /. {
deny all;
access_log off;
log_not_found off;
}
}7. 팁 6 – W3 Total 캐시에 대한 NGINX 구성
W3-Edge의 Frederick Townes가 만든 W3 Total Cache는 NGINX를 지원하는 WordPress 캐싱 프레임워크입니다. FastCGI 캐시의 대안으로 다양한 옵션 설정이 가능합니다.
캐싱 플러그인은 다양한 캐싱 구성을 제공하며 데이터베이스 및 객체 캐싱, HTML, CSS, JavaScript 축소, 인기 있는 CDN과 통합하는 옵션도 포함합니다.
플러그인은 도메인의 root 디렉터리에 있는 NGINX 구성 파일에 쓰는 방식으로 NGINX 구성을 처리합니다.
server {
server_name example.com www.example.com;
root /var/www/example.com/htdocs;
index index.php;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
include /path/to/wordpress/installation/nginx.conf;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
}8. 팁 7 – WP Super 캐시용 NGINX 구성
Automattic의 WordPress 개발자 Donncha O Caoimh가 만든 WP Super Cache는 동적 WordPress 페이지를 NGINX가 매우 빠르게 제공할 수 있는 정적 HTML 파일로 변환하는 WordPress 캐싱 엔진입니다. 이 플러그인은 최초의 WordPress용 캐싱 플러그인 중 하나이며 다른 플러그인보다 더 작고 집중된 옵션 범위를 제공합니다.
NGINX 구성은 사용자의 선호도에 따라 달라질 수 있습니다. 한 가지 가능한 구성은 다음과 같습니다.
아래 구성에서 첫 번째 location 블록(try_files 지시문의 첫 번째 매개변수에 supercache 요소가 있는 부분)은 WP Super Cache와 관련된 부분으로, 구성이 작동하는 데 필요합니다. 나머지 코드는 WordPress에 로그인한 사용자를 캐싱하지 않고, POST 요청을 캐싱하지 않으며, 정적 자산의 만료 헤더를 설정하는 WordPress 규칙과 표준 PHP 구현으로 구성되어 있으며, 이러한 부분은 필요에 맞게 사용자 정의할 수 있습니다.
server {
server_name example.com www.example.com;
root /var/www/example.com/htdocs;
index index.php;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log debug;
set $cache_uri $request_uri;
# POST requests and URLs with a query string should always go to PHP
if ($request_method = POST) {
set $cache_uri 'null cache';
}
if ($query_string != "") {
set $cache_uri 'null cache';
}
# Don't cache URIs containing the following segments
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php
|wp-.*.php|/feed/|index.php|wp-comments-popup.php
|wp-links-opml.php|wp-locations.php |sitemap(_index)?.xml
|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
set $cache_uri 'null cache';
}
# Don't use the cache for logged-in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+
|wp-postpass|wordpress_logged_in") {
set $cache_uri 'null cache';
}
# Use cached or actual file if it exists, otherwise pass request to WordPress
location / {
try_files /wp-content/cache/supercache/$http_host/$cache_uri/index.html
$uri $uri/ /index.php;
}
location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
log_not_found off;
access_log off;
}
location ~ .php$ {
try_files $uri /index.php;
include fastcgi_params;
fastcgi_pass unix:/var/run/php5-fpm.sock;
#fastcgi_pass 127.0.0.1:9000;
}
# Cache static files for as long as possible
location ~*.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg
|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid
|midi|wav|bmp|rtf)$ {
expires max;
log_not_found off;
access_log off;
}
}9. 팁 8 – NGINX 구성에 보안 예방 조치 추가
공격으로부터 보호하기 위해 주요 리소스에 대한 액세스를 제어하고 로그인 유틸리티에 과부하가 걸리는 Bot의 기능을 제한할 수 있습니다.
특정 IP 주소만 WordPress 대시보드에 액세스할 수 있도록 허용합니다.
# Restrict access to WordPress dashboard
location /wp-admin {
deny 192.192.9.9;
allow 192.192.1.0/24;
allow 10.1.1.0/16;
deny all;
}특정 유형의 파일만 업로드 허용 가능하도록 설정하여 악의적인 의도를 가진 프로그램이 업로드 및 실행되는 것을 방지합니다.
# Deny access to uploads that aren’t images, videos, music, etc.
location ~* ^/wp-content/uploads/.*.(html|htm|shtml|php|js|swf)$ {
deny all;
}WordPress 구성 파일인 wp-config.php에 대한 액세스를 거부합니다. 액세스를 거부하는 또 다른 방법은 파일을 도메인 root보다 한 디렉터리 수준 위로 이동하는 것입니다.
# Deny public access to wp-config.php
location ~* wp-config.php {
deny all;
}무차별 대입 공격을 차단하기 위해 wp-login.php에 대한 액세스를 제한합니다.
# Deny access to wp-login.php
location = /wp-login.php {
limit_req zone=one burst=1 nodelay;
fastcgi_pass unix:/var/run/php5-fpm.sock;
#fastcgi_pass 127.0.0.1:9000;
}10. 팁 9 – WordPress 멀티사이트에 NGINX 사용
WordPress 멀티사이트는 이름에서 알 수 있듯이 하나의 WordPress 인스턴스에서 두 개 이상의 사이트를 관리할 수 있는 WordPress 소프트웨어 버전입니다. 수천 개의 사용자 블로그를 호스팅하는 WordPress.com 서비스는 WordPress 멀티사이트에서 실행됩니다.
단일 도메인의 하위 디렉터리 또는 별도의 하위 도메인에서 별도의 사이트를 실행할 수 있습니다.
이 코드 블록을 사용하여 하위 디렉터리 구조에 대한 지원을 추가합니다.
# Add support for subdirectory structure in WordPress Multisite
if (!-e $request_filename) {
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
rewrite ^(/[^/]+)?(/wp-.*) $2 last;
rewrite ^(/[^/]+)?(/.*.php) $2 last;
}또는 앞의 코드 블록 대신 다음 코드 블록을 사용하여 하위 디렉터리 구조에 대한 지원을 추가하고 고유한 하위 디렉터리 이름으로 대체할 수 있습니다.
# Add support for subdomains
server_name example.com *.example.com;이전 버전의 WordPress 멀티사이트(3.4 이하)는 정적 콘텐츠를 제공하기 위해 readfile()을 사용합니다. 하지만 readfile()은 PHP 코드이므로 실행 시 성능에 상당한 타격을 줍니다. NGINX를 사용하면 이 불필요한 PHP 처리를 우회할 수 있습니다. 아래 코드 Snippet은 등호로 구분되어 있습니다(==============).
# Avoid PHP readfile() for /blogs.dir/structure in the subdirectory path.
location ^~ /blogs.dir {
internal;
alias /var/www/example.com/htdocs/wp-content/blogs.dir;
access_log off;
log_not_found off;
expires max;
}
============================================================
# Avoid PHP readfile() for /files/structure in the subdirectory path
location ~ ^(/[^/]+/)?files/(?.+) {
try_files /wp-content/blogs.dir/$blogid/files/$rt_file /wp-includes/ms-files.php?file=$rt_file;
access_log off;
log_not_found off;
expires max;
}
============================================================
# WPMU files structure for the subdomain path
location ~ ^/files/(.*)$ {
try_files /wp-includes/ms-files.php?file=$1 =404;
access_log off;
log_not_found off;
expires max;
}
============================================================
# Map blog ID to specific directory
map $http_host $blogid {
default 0;
example.com 1;
site1.example.com 2;
site1.com 2;
}11. WordPress 성능 향상 결론
확장성은 점점 더 많은 사이트 개발자가 WordPress 사이트를 성공적으로 운영하면서 직면하는 과제입니다. (그리고 WordPress 성능 문제를 처음부터 해결하고 싶은 신규 사이트도 마찬가지입니다.) WordPress 캐싱을 추가하고 WordPress와 NGINX를 결합하는 것이 확실한 해답입니다.
NGINX는 WordPress 사이트에만 유용하지 않습니다. NGINX는 세계에서 가장 바쁜 1,000개, 10,000개, 100,000개, 100만 개의 웹사이트를 운영하는 선도적인 웹 서버입니다.
