최신 WordPress 서버 스택 살펴보기

게시 됨: 2022-03-10
요약 요약 ↬ 편집자 주 : 오늘은 WordPress에 특별한 날입니다. 많은 웹사이트(예, Smashing Magazine이 그 중 하나임)를 지원하는 이 웹사이트는 오늘 13번째 생일을 맞았습니다. 생일 축하합니다, 친애하는 WordPress! 여기에 더 많은 것이 있습니다! Apache 서버와 PHP만으로 "빠른" WordPress 웹사이트를 실행할 수 있었던 때를 기억하십니까? 그래, 그 시절이었어! 그때는 상황이 훨씬 덜 복잡했습니다. 이제 모든 것이 번개처럼 빠르게 로드되어야 합니다! 방문자는 로딩 시간에 대해 예전과 같은 기대를 하지 않습니다. 느린 웹 사이트는 귀하 또는 귀하의 고객에게 심각한 영향을 미칠 수 있습니다.

Apache 서버와 PHP만으로 "빠른" WordPress 웹사이트를 실행할 수 있었던 때를 기억하십니까? 그래, 그 시절이었어! 그때는 상황이 훨씬 덜 복잡했습니다.

이제 모든 것이 번개처럼 빠르게 로드되어야 합니다! 방문자는 로딩 시간에 대해 예전과 같은 기대를 하지 않습니다. 느린 웹 사이트는 귀하 또는 귀하의 고객에게 심각한 영향을 미칠 수 있습니다.

SmashingMag에 대한 추가 정보:

  • 적절한 WordPress 파일 시스템 권한 및 소유권
  • 번거 로움없이 WordPress 웹 사이트 이동
  • MAMP를 사용하여 로컬에서 WordPress를 개발하는 방법
  • WordPress를 사용한 DIY 캐싱 방법

결과적으로 WordPress 서버 스택은 이러한 속도 요구 사항을 따라잡기 위해 수년에 걸쳐 진화 해야 했습니다. 이러한 진화의 일환으로 엔진에 몇 개의 기어를 추가해야 했습니다. 일부 구형 기어도 변경해야 했습니다.

점프 후 더! 아래에서 계속 읽기 ↓

그 결과 오늘날 WordPress 서버 스택이 몇 년 전과 상당히 다르게 보입니다. 더 잘 이해하기 위해 이 새로운 스택을 자세히 살펴보겠습니다. WordPress 웹 사이트를 빠르게 만들기 위해 다양한 조각이 어떻게 결합되는지 확인할 수 있습니다.

개요

자세히 알아보기 전에 축소하여 큰 그림을 살펴보겠습니다. 이 새로운 WordPress 서버 스택은 어떻게 생겼습니까? 답은 다음과 같습니다.

워드프레스 스택 다이어그램

위의 다이어그램은 최신 WordPress 서버 스택이 어떻게 생겼는지에 대한 좋은 개요를 제공합니다. 높은 수준에서 진행 상황을 세 가지 영역으로 나눌 수 있습니다.

  • 브라우저와 WordPress 간의 요청-응답 주기
  • WordPress(PHP 런타임이 실행하는 스크립트)
  • WordPress와 MySQL 데이터베이스 간의 쿼리-결과 주기.

최신 WordPress 서버 스택의 역할은 이 세 가지 영역을 최적화하는 것입니다. 이러한 최적화를 통해 모든 것이 더 빠르게 로드됩니다. 그리고 가장 좋은 점은 여러 가지 방법이 있다는 것입니다. (야!)

대부분의 경우 이러한 최적화에는 서버에 새 서비스 설치가 포함됩니다. 때때로 이러한 서비스는 WordPress와 상호 작용하기 위해 플러그인의 도움이 필요합니다. 플러그인을 설치하는 것만으로 벗어날 수 있는 경우도 있습니다. 이 기사 전체에서 다양한 옵션을 볼 수 있습니다.

요청-응답 주기

모든 것은 브라우저에서 시작됩니다. modern.wordpress-stack.org 의 홈 페이지를 보고 싶다고 가정해 봅시다. 브라우저는 HTTP 요청을 호스팅하는 웹 서버에 보내는 것으로 시작됩니다. 다른 쪽 끝에서 웹 서버는 요청을 받아 HTTP 응답으로 바꿉니다.

이 첫 번째 응답은 항상 modern.wordpress-stack.org 홈 페이지의 HTML 콘텐츠여야 합니다(오류가 없는 경우 제외). 그러나 브라우저의 작업은 완료되지 않았습니다. 아니요, 해당 홈 페이지에는 여전히 더 많은 파일이 필요하며 가장 일반적인 파일은 CSS, JavaScript 및 이미지 파일입니다.

따라서 브라우저는 해당 파일에 대한 요청을 보냅니다. 웹 서버는 요청된 파일로 응답합니다(다시, 오류가 없는 한). 이 주기는 브라우저에 홈 페이지를 렌더링하기에 충분한 정보가 있을 때까지 계속됩니다. 이 주기가 빠를수록 웹사이트가 더 빨리 로드되는 것처럼 보입니다.

이제 이것은 명백한 단순화이지만 대부분의 WordPress 웹 사이트에서 작동하는 방식입니다.

요청-응답 주기 최적화

좋습니다. 이것은 웹 서버가 이 주기를 더 빠르게 수행하도록 하려면 어떻게 하면 분명한 질문을 하게 됩니다. 이것은 훌륭한 질문이며 현대 WordPress 서버 스택이 존재하는 이유의 일부입니다.

웹 서버를 더 빠르게 만들 수 없기 때문에 스택이 존재합니다. 웹 서버는 또한 디스패처입니다. 요청을 수신하고 다른 서비스로 전달할 수 있습니다.

이러한 다른 서비스는 종종 이 요청-응답 주기의 병목 현상입니다. WordPress의 경우 이 병목 현상이 PHP이므로 요청-응답 주기 최적화가 두 가지로 귀결됩니다. 우리는 웹 서버가 다음을 수행하기를 원합니다.

  • 가능한 한 적은 수의 요청을 받고,
  • 가능한 한 적은 수의 요청을 PHP로 전달하십시오.

최신 WordPress 서버 스택은 이 마지막 항목에 중점을 둡니다. 가능한 한 적은 수의 요청을 PHP로 전달하려고 합니다. 이것이 스택 최적화의 주요 목표가 될 것입니다.

스택은 첫 번째 목표에 대해 많은 것을 할 수 없기 때문에 두 번째 목표에 집중합니다. 직접적인 영향은 없습니다. 두 번째 문제는 웹 서버의 구성이나 최신 개발 기술로 해결됩니다.

요청-응답 주기를 위한 스택 요소

그렇다면 PHP로 전달되는 요청을 줄이는 데 도움이 되는 스택 요소는 무엇입니까? 특히 두 가지 스택 요소는 웹 서버와 HTTP 캐시라는 목표를 달성하는 데 도움이 됩니다.

웹 서버

우리는 이미 웹 서버에 대해 꽤 많이 이야기했습니다. 웹 서버 영역에는 세 가지 주요 플레이어가 있습니다.

  • 아파치
  • 인터넷 정보 서비스(IIS)
  • nginx

이들은 모두 인터넷에서 웹 서버 시장 점유율의 90% 이상을 차지합니다. 우리는 Apache와 nginx에 집중할 것입니다. IIS를 사용하여 WordPress를 실행할 수 있지만 Windows에서만 사용할 수 있고 대부분의 WordPress 서버는 Linux를 사용하기 때문에 일반적이지 않습니다.

이것은 우리에게 Apache와 nginx를 남깁니다. WordPress의 평생 동안 Apache는 권장되는 웹 서버였습니다. 컴퓨터와 서버 모두에서 WordPress를 실행하는 LAMP 스택(Linux, Apache, MySQL 및 PHP)이 있었습니다.

그러나 무대 뒤에서 상황이 바뀌고 있었습니다. 마을에 새로운 플레이어가 있었고 그 이름은 nginx였습니다. Automattic과 WordPress.com은 2008년부터 이를 사용하고 있습니다. 트래픽이 많은 웹사이트(대부분 WordPress가 실행됨)를 가장 많이 실행하는 웹 서버입니다. 그렇기 때문에 많은 고급 호스팅 회사와 최고의 WordPress 대행사에서 웹 서버로 사용합니다.

Apache가 나쁜 웹 서버라는 것은 아닙니다. 많은 트래픽에서 잘 실행되도록 할 수 있는 Apache 전문가가 있습니다. 기본적으로 또는 표준 WordPress 구성에서는 잘 작동하지 않습니다.

한편, nginx의 유일한 목적은 많은 트래픽을 처리하는 것입니다. 이것이 Igor Sysoev가 Rambler에서 일할 때 프로젝트를 시작한 이유입니다.

nginx가 더 많은 트래픽을 더 잘 처리하는 이유 중 하나는 PHP와 통신하기 위해 FastCGI를 사용하기 때문입니다. FastCGI는 무엇입니까? PHP가 웹 서버와 별개의 서비스로 실행되도록 하는 프로토콜입니다.

Apache는 기본적으로 이 작업을 수행하지 않습니다. 웹 서버는 요청을 받을 때마다 PHP 런타임 프로세스를 시작해야 합니다. 이미지, JavaScript 및 CSS에 대해서도 마찬가지입니다. 이렇게 하면 서버가 처리할 수 있는 요청 수와 처리 속도가 줄어듭니다.

이것은 우리가 앞에서 본 최신 WordPress 서버 스택의 목표 중 하나에 위배됩니다. 스택은 요청-응답 주기 시간을 가능한 한 낮게 유지해야 합니다. 필요하지 않더라도 모든 요청에 ​​대해 PHP를 로드하는 것은 이 목표에 어긋납니다. 따라서 Apache를 사용하는 경우 FastCGI를 살펴보십시오.

HTTP/2 는 알아야 할 또 다른 중요한 웹 서버 기능입니다. 이것은 우리의 전체 요청-응답 주기를 구동하는 프로토콜인 HTTP의 다음 버전입니다.

HTTP/2가 도래하기 전에 브라우저는 웹 서버에 대해 6개의 연결만 가질 수 있었습니다. 그리고 각 연결은 한 번에 하나의 요청만 처리할 수 있습니다. 따라서 실제로 요청-응답 주기는 주기당 6개의 요청으로 제한되었습니다.

정말 문제입니다. 대부분의 웹 사이트에는 주기에 수십 개의 요청이 있습니다. 개발자와 시스템 관리자는 이 제한을 피할 수 있는 영리한 방법을 찾았습니다.

더 잘 알려진 해결 방법 중 하나는 CSS와 JavaScript 파일을 결합하는 방법입니다. 이상적인 시나리오에서 이렇게 하면 CSS 및 JavaScript 파일에 대한 총 요청 수가 JavaScript용과 CSS용으로 각각 2개로 줄어듭니다.

HTTP/2에서는 필요하지 않습니다. HTTP/2는 연결당 무제한의 요청을 허용합니다. 이렇게 하면 초기 HTML 응답 이후의 모든 추가 요청이 동시에 발생할 수 있습니다.

이는 성능에 큰 영향을 미칩니다. 서버 스택을 최적화하는 많은 작업은 요청-응답 주기에 중점을 둡니다. 주기 수를 소수로 줄임으로써 HTTP/2는 우리를 위해 엄청난 양의 작업을 수행했습니다.

HTTP 캐시

최신 WordPress 서버 스택의 가장 중요한 부분은 HTTP 캐시입니다. WordPress 세계에서는 이 페이지 캐싱이라고도 합니다. HTTP 캐시의 목적은 요청에 대한 응답을 캐시하는 것입니다. 이것은 무엇을 의미 하는가?

글쎄, 우리의 이전 예제로 돌아가 보자. 브라우저는 modern.wordpress-stack.org 의 홈 페이지에 대한 요청을 보내고 웹 서버는 해당 요청을 받아 PHP로 전달합니다.

이 시나리오의 문제는 웹 서버가 멍청하다는 것입니다. 대부분의 요청이 동일한 응답을 생성하는지 여부에 관계없이 항상 수신하는 모든 요청을 PHP로 전달합니다.

이것은 방문자가 로그인하지 않았을 때 발생하는 일입니다. 웹 서버에서는 모두 다른 요청이지만 상관하지 않습니다. PHP로 모두 전달하면 모든 항목에 대해 동일한 응답이 생성됩니다.

끔찍해! 앞에서 보았듯이 PHP는 요청-응답 주기의 실제 병목 현상입니다. 브라우저는 초기 홈 페이지 응답을 받을 때까지 후속 요청을 보낼 수 없습니다. 기본적으로 웹 서버가 모든 것을 PHP로 전달하도록 할 수는 없습니다.

이것이 HTTP 캐시가 들어오는 곳입니다. 웹 서버와 PHP 사이에 있습니다. 그 작업은 웹 서버가 수신하는 모든 요청을 확인하고 캐시된 응답을 찾는 것입니다. 존재하지 않는 경우 요청을 PHP로 전달한 다음 PHP가 생성하는 응답을 캐시합니다.

이렇게 하면 요청-응답 주기 시간이 크게 줄어들어 웹사이트 로드 속도가 빨라집니다. 또한 웹 서버가 폭주하지 않고 더 많은 동시 요청을 처리할 수 있습니다.

HTTP 캐시의 다양한 맛

이 시점에서 "이 아기를 어떻게 빨리 내 서버에 올릴 수 있습니까?!" 좋은 소식은 WordPress 서버에 HTTP 캐시를 설치하는 것이 매우 쉽다는 것입니다. 선택의 폭이 가장 넓은 부품입니다.

페이지 캐싱 플러그인 설치

가장 쉬운 방법은 페이지 캐싱 플러그인을 설치하는 것입니다. 선택할 수 있는 몇 가지 옵션이 있습니다.

  • 배트캐시
  • 하이퍼 캐시
  • 캐시 인에이블러
  • WP 로켓
  • WP 슈퍼 캐시
  • W3 총 캐시

WP Rocket을 제외한 모든 것은 WordPress 디렉토리에서 무료 플러그인으로 사용할 수 있습니다. 따라서 하나를 설치하고 즉시 테스트할 수 있습니다. 즉, 네 가지 플러그인 중 가장 좋은 것은 WP Rocket입니다. 유료 플러그인이지만 HTTP 캐시를 만드는 것 이상을 수행합니다. 이러한 다른 이점은 HTTP 캐시가 수행하는 작업을 확대합니다.

페이지 캐싱 플러그인은 어떻게 작동합니까?

이러한 모든 플러그인은 WordPress가 캐싱에 사용할 수 있도록 만든 드롭인을 활용합니다. 이 캐싱 드롭인을 사용하면 플러그인이 WordPress 내부에 HTTP 캐시 시스템을 만들 수 있습니다. 캐싱 드롭인이 작동하려면 두 가지 작업이 필요합니다.

먼저 advanced-cache.php 드롭인 파일이 wp-content 폴더에 있어야 합니다. 그것이 실제 파일입니다. 그러나 대부분의 WordPress 드롭인과 달리 이것은 기본적으로 시작되지 않습니다. WordPress는 또한 드롭인을 로드하기 위해 WP_CACHE 상수가 true 여야 합니다. 대부분의 경우 wp-config.php 에서 설정합니다.

플러그인 HTTP 캐시(로드 중)

위의 다이어그램은 캐싱 플러그인으로 드롭인을 활성화할 때 어떤 일이 발생하는지 보여줍니다. WordPress는 로드 프로세스 중에 wp-settings.php 에 드롭인을 로드합니다. 이것은 WordPress가 아직 시간이 많이 걸리는 작업을 수행하지 않은 프로세스의 초기 단계입니다.

그런 다음 캐싱 플러그인은 요청에 대한 응답을 이미 캐시했는지 여부를 확인합니다. 있는 경우 캐시된 응답을 반환합니다. 그렇지 않은 경우 PHP 출력 버퍼링이 켜지고 WordPress가 계속 로드됩니다.

이제 출력 버퍼링은 흥미로운 시스템입니다. 이것이 하는 일은 다음 두 가지 중 하나가 발생할 때까지 PHP 스크립트의 모든 출력을 문자열 변수에 캡처하는 것입니다.

  • 내장 함수 중 하나를 사용하여 출력 버퍼링을 중지하도록 PHP에 지시합니다.
  • PHP 스크립트가 완료되고 브라우저에 응답을 반환해야 합니다.

캐싱 플러그인은 후자의 시나리오를 고려하고 있습니다. WordPress가 작업을 수행한 다음 PHP가 브라우저로 다시 보내기 전에 전체 출력을 캐시하기를 원합니다. 아래 다이어그램에서 프로세스를 볼 수 있습니다.

플러그인 HTTP 캐시(종료)

웹 서버에서 수행

다음 옵션은 웹 서버 수준에서 HTTP 캐시를 추가하는 것입니다. 작동 방식은 웹 서버가 PHP로 전달되는 요청에 대한 모든 응답을 캐시한다는 것입니다. 이 솔루션은 PHP를 전혀 건드릴 필요가 없기 때문에 캐싱 플러그인보다 낫습니다.

웹 서버 HTTP 캐시

위의 다이어그램은 웹 서버에서 진행되는 작업에 대한 개요를 제공합니다. 웹 서버는 요청을 수신하고 HTTP 캐시를 확인합니다. 응답이 이미 캐시된 경우 HTTP 캐시가 해당 응답을 다시 보냅니다.

그렇지 않으면 요청을 PHP 모듈(보통 FastCGI)로 전달합니다. 응답을 생성할 수 있도록 요청을 WordPress에 전달합니다. 그런 다음 HTTP 캐시 모듈은 돌아오는 길에 해당 응답을 캐시합니다.

Apache와 nginx는 모두 HTTP 캐시 시스템을 추가할 수 있습니다. nginx는 내장되어 있습니다. Apache는 Apache 설치에 추가해야 하는 별도의 모듈입니다.

PHP 또는 WordPress와 함께 Apache 모듈을 사용하는 방법에 대한 정보가 많지 않습니다. Apache 군중에게 인기가 없기 때문이거나 몇 가지 문제가 있기 때문일 수 있습니다. 아직 해결되지 않은 오래된 문제가 하나 이상 있습니다.

한편, nginx HTTP 캐시 시스템은 강력하고 문서화되어 있습니다. 일반 HTTP 캐시로 사용하거나 작지만 효과적인 마이크로 캐시로 사용할 수 있습니다. nginx가 오늘날 선호되는 웹 서버인 이유 중 하나일 뿐입니다.

스택에 바니시 추가

바니시 란 무엇입니까? 이것은 전용 HTTP 캐시 서버입니다(또는 개발자들이 좋아하는 HTTP 가속기). 대부분의 트래픽이 많은 웹 사이트 및 프리미엄 호스팅 회사는 이를 HTTP 캐시 솔루션으로 사용합니다.

강력하고 가장 유연하기 때문에 사용합니다. Varnish에는 VCL이라는 자체 구성 언어가 있습니다. 캐싱 프로세스의 모든 요소를 ​​제어할 수 있습니다. Varnish에는 캐시가 수행하는 작업과 성능을 분석하기 위한 많은 도구도 함께 제공됩니다.

이것들을 사용하는 것과 내장 웹 서버 HTTP 캐시를 사용하는 것의 주요 차이점입니다. 내장 웹 서버 HTTP 캐시는 성능이 뛰어나지만 매우 기본적입니다. 몇 가지 구성 옵션 외에는 많은 제어 권한이 없습니다.

그럼에도 불구하고 이러한 능력과 유연성에는 대가가 따릅니다. Varnish는 또한 가장 복잡한 HTTP 캐시 옵션입니다. HTTP 응답을 캐시하는 것 외에는 아무것도 하지 않습니다. 대부분의 WordPress 개발자가 원하거나 원해야 하는 SSL 종료를 처리하지 않습니다. 이것은 우리가 사용할 때 최신 WordPress 서버 스택이 더 복잡해질 것임을 의미합니다.

HTTP 캐시 바니시

위의 다이어그램은 이러한 추가 복잡성을 보여줍니다. 이제 WordPress 서버 스택에 Varnish와 리버스 프록시라는 두 가지 구성 요소가 더 있습니다.

역 프록시는 Varnish가 SSL과 함께 갖는 한계를 극복하기 위해 존재합니다. Varnish 앞에 위치하며 서버가 수신하는 요청을 해독합니다. 이 유형의 역방향 프록시 SSL 종료 프록시를 호출할 수도 있습니다. 그런 다음 프록시는 이러한 해독된 요청을 Varnish로 보내 처리합니다.

요청이 Varnish에 도달하면 VCL 구성 파일이 시작됩니다. 이 파일은 Varnish의 두뇌입니다. 예를 들어 다음과 같은 방법을 알려줍니다.

  • 들어오는 요청을 분석, 정리 및 수정합니다.
  • 캐시된 응답을 찾습니다.
  • WordPress에서 반환되는 응답을 분석, 정리 및 수정합니다.
  • 이러한 반환 응답을 캐시합니다.
  • 캐시에서 하나 이상의 응답을 제거하라는 요청을 처리합니다.

이 마지막 것이 특히 중요합니다. Varnish는 WordPress가 캐시에서 페이지를 제거하려고 할 때 알 수 있는 방법이 없습니다. 따라서 기본적으로 게시물을 변경하고 업데이트하면 방문자는 캐시된 동일한 페이지를 계속 보게 됩니다. 다행히도 Varnish 캐시에서 페이지를 제거하는 플러그인이 있습니다.

워드프레스

좋습니다. modern.wordpress-stack.org 의 홈페이지 요청이 워드프레스에 도달했습니다. 그것은 우리가 방금 다룬 요청-응답 주기를 거쳤습니다. HTTP 캐시는 다시 보낼 HTTP 응답을 찾기 위해 할 수 있는 모든 일을 했습니다.

그러나 브라우저로 다시 보낼 캐시된 HTTP 응답이 없습니다. 그 시점에서 HTTP 캐시에는 다른 선택이 없었습니다. HTTP 요청을 WordPress로 전달해야 했습니다.

이제 모든 것이 WordPress의 손에 있습니다. WordPress는 HTTP 요청을 HTTP 응답으로 변환하고 HTTP 캐시로 다시 보내야 합니다. 앞에서 보았듯이 이것이 전체 최신 WordPress 서버 스택의 주요 병목 현상입니다.

이 병목 현상의 원인은 두 가지입니다. WordPress에는 실행할 PHP 코드가 많이 있습니다. 이것은 시간이 많이 걸리며 PHP가 수행하는 속도가 느릴수록 더 오래 걸립니다.

다른 병목 현상은 WordPress가 수행해야 하는 데이터베이스 쿼리입니다. 데이터베이스 쿼리는 비용이 많이 드는 작업입니다. 더 많을수록 WordPress가 느려집니다. 이것은 쿼리-결과 주기에 대한 마지막 섹션의 초점이 될 것입니다.

PHP 런타임 최적화

PHP로 돌아가자. 현재 WordPress에는 PHP 5.2의 최소 요구 사항이 있습니다. 이 버전의 PHP는 거의 10년이 되었습니다! (PHP 팀은 2011년에 지원을 중단했습니다.)

PHP 팀은 그 동안 유휴 상태로 있지 않았습니다. 특히 지난 몇 년 동안 많은 성능 개선이 이루어졌습니다. 요즘에는 최적화하기 위해 무엇을 할 수 있는지 살펴보겠습니다.

최신 버전의 PHP 사용

가장 쉬운 방법은 PHP 버전을 업그레이드하는 것입니다. 버전 5.4, 5.5 및 5.6은 모두 성능이 향상되었습니다. 가장 큰 개선 사항은 5.3에서 5.4로였습니다. 그것으로 전환하면 WordPress의 성능이 상당히 향상되었습니다.

Opcode 캐싱 설치

Opcode 캐싱은 PHP 속도를 높이는 또 다른 방법입니다. 서버 측 스크립팅 언어인 PHP에는 큰 결함이 있습니다. PHP는 실행할 때마다 PHP 스크립트를 컴파일해야 합니다.

이 문제에 대한 해결책은 컴파일된 PHP 코드를 캐시하는 것입니다. 그렇게 하면 PHP가 실행할 때마다 컴파일할 필요가 없습니다. 이것은 opcode 캐시의 작업입니다.

PHP 5.5 이전에는 PHP가 opcode 캐시와 함께 번들로 제공되지 않았습니다. 서버에 직접 설치해야 했습니다. 이것은 최신 버전의 PHP를 사용하는 것이 더 나은 또 다른 이유입니다.

차세대 컴파일러로 전환

마지막으로 할 수 있는 일은 두 가지 차세대 컴파일러(Facebook의 HHVM 또는 PHP 최신 버전인 PHP 7) 중 하나로 전환하는 것입니다. (왜 PHP 7입니까? 긴 이야기입니다.)

Facebook과 PHP 팀은 처음부터 이 두 가지 컴파일러를 구축했습니다. 그들은 보다 현대적인 컴파일 전략을 활용하기를 원했습니다. HHVM은 Just-In-Time 컴파일을 사용하는 반면 PHP 7은 Ahead-of-Time 컴파일을 사용합니다. 둘 다 좋은 PHP 5에 비해 놀라운 성능 향상을 제공합니다.

HHVM은 몇 년 전에 처음으로 현장에 도착했습니다. 많은 최상위 호스트가 이를 사용하여 많은 성공을 거두었으며 기본 PHP 컴파일러로 제공합니다.

HHVM이 공식 PHP 컴파일러가 아니라는 점을 강조할 가치가 있습니다. PHP와 100% 호환되지는 않습니다. 그 이유는 HHVM이 단지 PHP를 지원하도록 설계되지 않았기 때문입니다. 또한 Facebook의 Hack 프로그래밍 언어용 컴파일러입니다.

PHP 7은 공식 PHP 컴파일러입니다. 그것은 오랫동안 주변에 없었다. PHP 팀은 2015년 12월에 이를 릴리스했습니다. 이것은 일부 WordPress 호스팅 회사에서 이미 지원하는 것을 막지 못했습니다.

좋은 소식은 WordPress 자체가 두 컴파일러와 100% 호환된다는 것입니다! 나쁜 소식은 WordPress의 최소 PHP 버전이 여전히 5.2이기 때문에 모든 플러그인과 테마가 그런 것은 아니라는 것입니다.

작성자가 플러그인이나 테마를 이러한 컴파일러와 함께 작동하도록 강제하는 것은 없습니다. 그래서, 당신은 그들 중 하나에 모두 들어갈 수 없습니다. 스택은 항상 PHP 5로 대체되어야 합니다.

쿼리 결과 주기

이 시점에서 PHP 런타임은 모든 WordPress PHP 파일을 살펴보고 실행합니다. 그러나 이러한 WordPress PHP 파일에는 데이터가 포함되어 있지 않습니다. 여기에는 WordPress 코드만 포함되어 있습니다.

문제는 WordPress가 모든 데이터를 MySQL 데이터베이스에 저장한다는 것입니다. 따라서 PHP 런타임은 해당 데이터베이스를 쿼리해야 합니다. MySQL 서버는 해당 쿼리의 결과를 반환하고 PHP 런타임은 계속해서 WordPress PHP 파일을 실행합니다. 즉, 데이터가 다시 필요할 때까지입니다.

이 앞뒤로 수십 번에서 수백 번 발생할 수 있습니다. (후자의 경우 개발자와 이야기하고 싶을 수도 있습니다!) 이것이 주요 병목 현상인 이유입니다.

쿼리-결과 주기 최적화

여기서 최적화 목표는 PHP로 WordPress 파일의 실행 시간을 단축하는 것입니다. 여기서 데이터베이스 쿼리가 문제가 됩니다. 그것들은 일반 PHP 코드를 실행하는 것보다 더 많은 시간이 소요되는 경향이 있습니다(코드가 터무니없는 일을 하지 않는 한).

이 문제를 해결하는 확실한 방법은 WordPress가 수행해야 하는 쿼리 수를 줄이는 것입니다. 그리고 그것은 항상 가치가 있습니다! 그러나 그것은 현대 WordPress 서버 스택이 도울 수 있는 것이 아닙니다.

WordPress가 만드는 쿼리 수를 줄일 수는 없지만 옵션이 없는 것은 아닙니다. 스택이 쿼리-결과 주기를 최적화하는 데 도움이 되는 두 가지 방법이 있습니다. 처음부터 데이터베이스에 대한 쿼리 수를 줄일 수 있습니다. 그리고 데이터베이스에 도달하는 쿼리의 경우 쿼리를 실행하는 데 걸리는 시간을 줄일 수 있습니다.

이 두 가지 옵션은 모두 동일한 작업을 수행하기 위한 것입니다. PHP가 데이터베이스의 결과를 가능한 한 적게 기다리게 하여 WordPress 자체를 더 빠르게 만듭니다.

쿼리-결과 주기에 대한 스택 요소

쿼리-결과 주기와 관련된 다양한 스택 요소를 살펴보겠습니다. 스택의 이 부분은 덜 복잡합니다. 그러나 여기에는 여전히 하나 이상의 구성 요소, 즉 MySQL 데이터베이스 서버와 개체 캐시가 포함됩니다.

MySQL 데이터베이스 서버

몇 년 전만 해도 MySQL 데이터베이스 서버는 모든 사람에게 같은 의미였습니다. MySQL 서버가 설치된 서버였습니다. 그러나 최근 몇 년 동안 상황이 많이 바뀌었습니다.

다양한 그룹은 Oracle이 MySQL 프로젝트를 관리하는 방식에 만족하지 않았습니다. 따라서 각 그룹은 이를 분기하고 대신 "들어갈" 수 있는 자체 버전을 만들었습니다. 결과는 이제 여러 MySQL 데이터베이스 서버가 있다는 것입니다.

새로운 "공식" MySQL 서버는 MariaDB 서버입니다. 커뮤니티에서 개발한 MySQL 서버 버전입니다. 커뮤니티는 MySQL 서버 프로젝트와 완전한 호환성을 유지할 계획입니다.

MySQL에 대한 또 다른 인기 있는 대안은 Percona 서버입니다. MariaDB와 달리 Percona는 MySQL의 분기에 가깝습니다. 개발자들은 MySQL 프로젝트 자체에 반대하지 않습니다. 그들은 단지 MySQL의 성능 향상에 집중하기를 원합니다. MariaDB 팀은 나중에 이러한 성능 개선 사항 중 일부를 MariaDB 프로젝트에 병합했습니다.

하루가 끝나면 원하는 것을 선택할 수 있습니다. Percona 서버와 MariaDB 서버 사이에는 성능 차이가 없습니다(어쨌든 대부분의 경우). 둘 다 MySQL보다 성능이 좋습니다. 그러나 Percona는 Oracle 프로젝트와 더 긴밀한 호환성을 유지합니다.

성능에 영향을 미치는 것은 WordPress 데이터베이스가 사용하는 스토리지 엔진 입니다. 스토리지 엔진은 데이터베이스 서버가 저장하는 데이터를 관리하는 방법을 제어합니다. 데이터베이스 테이블마다 다른 스토리지 엔진을 설정할 수도 있습니다. 전체 데이터베이스에 대해 동일한 것을 사용할 필요는 없습니다.

데이터베이스 서버에는 여러 스토리지 엔진이 있습니다. 우리는 그들 모두를 보지 않을 것입니다. InnoDB와 MyISAM의 두 가지만 관심이 있습니다.

기본적으로 WordPress는 기본 MySQL 데이터베이스 엔진을 사용합니다. MySQL 5.5 이전에는 해당 엔진이 MyISAM이었습니다. 작은 WordPress 웹 사이트를 실행하는 경우 MyISAM이 좋습니다. MyISAM은 웹사이트의 크기가 커지면 성능 문제가 발생합니다. 그 시점에서 InnoDB는 데이터베이스 엔진을 위한 유일한 선택입니다.

InnoDB의 유일한 문제는 최상의 성능을 발휘하기 위해 약간의 조정이 필요하다는 것입니다. 대규모 데이터베이스 서버를 실행하는 경우 조정해야 할 수 있습니다. 다행히도 이를 도와줄 도구가 있습니다.

MySQLTuner는 데이터베이스 서버를 분석하는 작은 스크립트입니다. 보고서를 생성하고 튜닝 권장 사항을 제공합니다.

개체 캐시

쿼리-결과 주기를 최적화하는 작업의 정면은 개체 캐시에 있습니다. 개체 캐시의 작업은 가져오거나 생성하는 데 시간이 많이 걸리는 데이터를 저장하는 것입니다. 짐작할 수 있듯이 데이터베이스 쿼리는 완벽한 후보입니다.

워드프레스는 객체 캐시를 많이 사용합니다. 데이터베이스에서 옵션을 가져오기 위해 get_option 을 사용한다고 가정해 보겠습니다. WordPress는 해당 옵션에 대해 데이터베이스를 한 번만 쿼리합니다. 다음에 누군가가 필요할 때 다시 쿼리하지 않습니다.

대신 WordPress는 개체 캐시에서 쿼리 결과를 가져옵니다. 이것은 WordPress가 수행해야 하는 데이터베이스 쿼리 수를 줄이기 위해 취하는 사전 조치입니다. 하지만 완벽한 솔루션은 아닙니다.

WordPress는 개체 캐시를 활용하기 위해 최선을 다하지만 플러그인이나 테마는 그럴 필요가 없습니다. 플러그인이나 테마가 많은 데이터베이스 쿼리를 만들고 결과를 캐시하지 않으면 스택은 이에 대해 아무 것도 할 수 없습니다.

이러한 경우 대부분의 데이터베이스 쿼리는 WordPress 자체에서 발생합니다. 따라서 WordPress의 기본 제공 개체 캐시 사용을 통해 많은 이점을 얻을 수 있습니다. 이것이 현대 WordPress 서버 스택의 중요한 요소인 이유입니다.

이제 개체 캐시의 문제는 기본적으로 저장하는 데이터를 유지하지 않는다는 것입니다. PHP가 모든 WordPress 파일을 실행하는 동안 데이터를 메모리에 저장합니다. 그러나 PHP 프로세스가 종료되면 메모리에 저장된 모든 데이터가 지워집니다.

이것은 전혀 이상적이지 않습니다. 개체 캐시는 오랫동안 유효할 수 있으므로 단일 요청으로 제한하고 싶지 않습니다. 해결책은 영구 개체 캐시를 사용하는 것 입니다.

영구 개체 캐시는 종종 플러그인 형태로 제공됩니다. 해당 플러그인은 작업을 수행하기 위해 object-cache.php 드롭인을 사용합니다. 이 드롭인을 사용하면 플러그인 작성자가 개체 캐시의 기본 동작을 변경할 수 있습니다.

그런 다음 플러그인은 개체 캐시를 영구 데이터 저장소에 연결합니다. 그들은 기본 개체 캐시의 가져오기 및 저장 기능을 대체하여 이를 수행합니다. 데이터를 메모리에 저장하고 가져오는 대신 개체 캐시가 해당 저장소에서 데이터를 수행합니다.

영구 개체 캐시 플러그인

요즘에는 영구 개체 캐싱을 위한 두 가지 인기 있는 데이터 저장소 옵션이 있습니다.

  • Memcached(플러그인)
  • 레디스(플러그인)

이 두 데이터 저장소는 모두 RAM을 저장용으로 사용하므로 번개처럼 빠릅니다. 실제로 성능은 기본 개체 캐시의 성능과 비슷합니다.

유일한 문제는 서버에 사전 설치되어 제공되지 않는다는 것입니다. 또한 PHP 확장(Redis에서는 선택 사항임)도 마찬가지입니다. 해당 WordPress 플러그인을 사용하려면 먼저 설치해야 합니다.

어느 것을 설치해야 합니까? 실제로 개체 캐싱의 경우 둘 사이에는 큰 차이가 없습니다. 과거에 인기 있는 옵션은 Memcached였습니다. 이것은 지난 몇 년 동안 변경되었습니다. Redis는 객체 캐싱을 위한 필수 옵션이 되도록 많은 기능을 추가했습니다.

나만의 최신 WordPress 서버 얻기

그렇다면 어떻게 자체 서버를 확보할 수 있을까요? 확실한 방법은 최상위 WordPress 호스팅 회사에서 얻는 것입니다. 이 회사는 최신 혁신과 기술을 채택하도록 동기를 부여하는 WordPress 호스팅 비즈니스의 최전선에 있기를 원합니다.

하지만 큰 돈을 들이지 않고 하나를 원한다면 어떻게 될까요? 스스로 하고 호스팅 비용을 적게 들이고자 하는 사람이라면 누구나 사용할 수 있는 몇 가지 도구가 있습니다. 그들을 살펴보자.

WordPress용 DebOps

DebOps for WordPress는 누구나 최신 WordPress 서버를 구축하는 데 도움이 되도록 만든 도구입니다. 그 임무는 커뮤니티의 모든 사람이 최신 WordPress 서버 스택을 사용할 수 있도록 하는 것입니다. 그렇기 때문에 최대한 쉽게 사용하려고 노력하고 있습니다. 그것을 사용하기 위해 시스템 관리 지식이 필요하지 않습니다.

WordPress용 DebOps는 다음을 사용하여 서버를 구성합니다.

  • HHVM(PHP 7이 공식 Linux 저장소로 만들어질 때까지)
  • 마리아DB
  • nginx
  • 레디스
  • 광택

이 도구는 최신 기술로 서버를 구성하는 것 이상을 수행합니다. 또한 서버 보안을 관리합니다. 이것은 사람들이 자신의 서버를 관리할 때 종종 간과하는 것입니다.

EasyEngine

EasyEngine은 서버에서 WordPress 웹 사이트를 설정하는 데 도움이 되도록 설계된 명령줄 도구입니다. EasyEngine의 가장 큰 장점은 유연성입니다. 지금까지 살펴본 서버 기술의 거의 모든 조합을 설정할 수 있습니다.

예를 들어 HHVM 또는 PHP 7로 서버를 설정할 수 있습니다. 영구 데이터 저장소에 대해 Memcached와 Redis 중에서 선택할 수 있습니다. 그리고 phpMyAdmin과 같은 관리자 도구를 설치할 수 있습니다.

또한 WordPress 웹 사이트를 만들 때 많은 옵션을 제공합니다. 플러그인이나 nginx를 사용하여 HTTP 캐시로 웹사이트를 설정하도록 지시할 수 있습니다. 이 모든 유연성 덕분에 EasyEngine이 인기 있는 도구입니다.

격자

Trellis는 Roots에서 개발한 도구입니다. DebOps와 마찬가지로 특정 서버 기술 세트로 서버를 구성합니다.

  • 마리아DB
  • 멤캐시드
  • nginx
  • nginx HTTP 캐시(선택 사항)
  • PHP 7

Trellis에 대해 알아야 할 한 가지는 Roots가 만든 또 다른 도구인 Bedrock과의 관계입니다. Bedrock은 "Twelve-Factor App" 원칙을 중심으로 WordPress 웹사이트를 구성하기 위한 상용구입니다.

Roots 팀은 사람들이 Bedrock 구조의 WordPress 웹사이트를 사용하는 서버를 구성할 수 있도록 Trellis를 만들었습니다. 일반 워드프레스 설치에서는 사용할 수 없으므로 염두에 두십시오.

시대가 바뀌었다

보시다시피, WordPress 서버에는 오늘날 훨씬 더 많은 움직이는 부분이 있습니다! 그러나 이것이 절망의 원인이 될 필요는 없습니다. 항상 모든 부품을 사용할 필요가 없기 때문에 보기보다 나쁘지 않습니다.

그렇기 때문에 이 기사의 많은 부분에서 이러한 부분이 함께 작동하는 방식에 대해 설명합니다. 요점은 스스로 결정할 수 있도록 권한을 부여하는 것입니다. 이 지식을 사용하여 언제 사용해야 하는 부품을 결정하십시오. 이런 식으로, 당신도 빠른 WordPress 웹 사이트를 갖게 될 것입니다.