WordPress 개체 캐싱: Redis, Memcached 및 기본 API

게시 됨: 2017-11-04

마음대로 확장할 수 있는 엔터프라이즈급 워드프레스 사이트는 페이지와 이미지를 넘어 지속적인 캐싱 메커니즘, 즉 실제 PHP 개체를 캐시할 수 있는 메커니즘이 필요합니다. 워드프레스는 워드프레스 개체 캐시를 통해 개체 캐싱 메커니즘을 제공하지만 큰 활용도와 성능을 제공하는 다른 솔루션이 있습니다. 그러나 모든 것을 다루기 전에 먼저 객체 캐싱이 무엇인지, PHP에서 어떻게 작동하는지 알아야 합니다.

객체 캐싱이란 무엇입니까?

PHP는 객체 지향 언어입니다. 객체 패러다임을 사용하여 코드를 구성합니다. 결과적으로 WordPress 사이트는 (메모리 관리자에 의해) 지속적으로 생성, 인스턴스화 및 소멸되는 다양한 PHP 개체로 구성됩니다. 객체를 생성하고 파괴하는 것은 특히 객체가 많은 경우 비용 오버헤드가 있습니다. 그러나 이들 대부분은 핵심 기능을 나타내기 때문에 많이 재사용되는 경향이 있습니다. 즉, 애플리케이션에 다시 필요할 때마다 처음부터 인스턴스화해야 합니다.

자주 사용하는 인스턴스화된 개체를 캐시하여 항상 삭제하고 만들 필요가 없다면 어떨까요?

PHP의 serialise() 함수를 사용하여 객체 또는 프리미티브를 메모리 또는 나중에 액세스할 수 있도록 디스크에 저장할 수 있는 숫자 표현(바이트 덩어리)으로 변환할 수 있습니다. 그런 다음 hash() 함수를 사용하여 바이트 blob의 해시 번호를 계산하고 둘 다 저장합니다. 해시를 키로 사용하고 바이트 blob을 값으로 사용합니다. 이를 검색하기 위해 처음에 키로 저장된 바이트 블롭의 계산된 해시 번호를 사용합니다. 이 방법으로 무엇이든(String, Integer, Object, Boolean, Array 등) 값의 저장 가능한 표현으로 바꿀 수 있습니다.

예시:

$serialized = serialize( array ( 'test' ));

unserialize()를 사용하여 역 작업을 수행합니다.

$original = unserialize ( $serialized );

일반적으로 개체를 캐시할 수 있는 세 가지 방법이 있습니다. 기본 WordPress 개체 캐시, Transients API 또는 Redis 또는 Memcached와 같은 외부 키-값 저장소를 사용합니다.

워드프레스 개체 캐싱

WordPress는 기본 WordPress Object Cache와 Transients API의 두 가지 개체 캐싱 API를 제공합니다. 그것들은 동일하며 이것이 혼란을 일으킬 수 있지만 그 뒤에는 논리가 있습니다.

기본 WordPress 개체 캐시는 개체와 기본 요소를 캐시에 저장할 수 있지만 기본적으로 영구적인 방식은 아닙니다. 이것은 캐싱이 메모리에서 발생하고 캐싱된 개체가 요청의 수명 주기를 초과하지 않음을 의미합니다. 따라서 다른 페이지 로드 간에 캐시된 개체를 공유할 수 없습니다. WordPress 기능을 확장할 수 있는 "고급" 플러그인인 드롭인을 사용하여 자체 스토어 구현을 제공해야 합니다. 플러그인 목록의 WordPress 대시보드에서 볼 수 있습니다.

워드프레스 드롭인

반면 Transients API는 기본적으로 작동합니다. 만료 날짜와 연결된 변수, 배열, 개체를 데이터베이스에 직접 저장할 수 있으며 영구 개체 캐싱을 가질 수 있습니다. 그러나 문제는 캐시된 개체가 만료되면 공간을 차지하는 데이터베이스에 남아 있다는 것입니다. 이는 데이터베이스를 유지 관리하는 데 추가 오버헤드가 소모되고 만료된 개체를 가끔씩 정리한다는 것을 의미합니다.

WordPress는 자체 영구 개체 캐시를 구현했는지 감지하고 그러한 경우 Transients API에 대한 호출이 우회되어 WordPress 개체 캐시로 라우팅됩니다(따라서 동일한 이유).

개발자는 자체 개체 캐시를 구현하거나 WordPress 플러그인(나중에 자세히 설명)을 사용하거나 Pressidium 클라이언트인 경우 자체 구현을 사용할 수 있습니다. 잘못된 상황에서 사용하면 성능 저하가 발생할 수 있으므로 기본적으로 개체 캐시가 켜져 있지 않습니다. WordPress 사이트의 개체 캐싱과 관련하여 "모든 경우에 적용되는" 솔루션은 없습니다.

Redis와 Memcached

키-값 저장소는 테이블과 사전 정의된 데이터 유형을 사용하여 RDBMS와 같은 레코드에 정보를 저장하지 않습니다. 프로그래밍 언어에서 찾을 수 있는 사전 데이터 구조에서와 같이 키/값 쌍을 저장하고 검색하도록 설계되었습니다.

그러한 상점의 좋은 예는 Redis입니다. 사전 데이터 구조 외에도 범위 쿼리가 있는 정렬된 집합 및 반경 쿼리가 있는 지리 공간 인덱스와 같은 고급 데이터 구조를 포함하여 많은 다른 구조를 지원합니다. 영구 개체 캐싱 을 제공합니다.

레디스

Redis는 단순한 키-값 저장소 또는 캐시가 아닙니다. 클러스터 구성에서 데이터 복제, 스크립팅, 고가용성을 지원합니다. 원하는 디스크 지속성 수준을 미세 조정할 수도 있습니다. Redis의 좋은 점은 다시 시작해도 대부분의 캐시가 여전히 디스크에 있고 손실된 데이터는 극히 일부에 불과하다는 것입니다. 문제는 다시 시작할 때 서버가 캐시를 다시 작성해야 하고 대부분의 경우 로드가 증가한다는 것입니다. Redis에서는 이런 일이 발생하지 않습니다. 또한 만료된 개체는 데이터베이스에서 즉시 삭제됩니다. 관리 오버헤드 시간도 없습니다.

Redis Labs에는 기업의 Redis 사용 사례를 보여주는 훌륭한 페이지가 있습니다. 이러한 사례는 매우 큰 데이터 세트에서 전체 텍스트 검색, 실시간 시리즈, Spark 통합 등에 이르기까지 다양합니다.

이러한 모든 기능은 복잡성과 속도면에서 비용이 많이 들지만 Redis 드롭인 코드를 최적화하면 상당한 이점을 얻을 수 있습니다. Redis가 Persistent object-caching 을 수행한다는 사실을 잊지 마세요. Memcached가 하지 않는 일이지만 사용이 훨씬 더 간단합니다.

멤캐시드

Memcached는 동적 웹 응용 프로그램의 속도를 높이고 데이터베이스 부하를 완화하도록 특별히 설계된 공식 웹 사이트에 따른 메모리 내 고성능 개체 캐싱 시스템입니다. 또한 Redis보다 훨씬 간단하고 사용하기 쉽습니다.

웹 페이지에 대한 개체 캐싱을 수행하도록 특별히 설계되었으며 메모리 내 데이터베이스를 사용하기 때문에 가장 빠른 개체 캐싱 솔루션입니다. 그러나 앞에서 언급했듯이 서버가 다시 시작되면 캐시가 없어집니다. 그리고 재건될 때까지 아마도 부하가 증가할 것입니다. 그러나 제작자가 "웹 사이트의 단기 기억으로 생각하십시오"라고 말했듯이 처음에 무엇을 하고 싶은지에 달려 있습니다.

Memcached는 캐시를 유지하기 위해 인메모리 데이터베이스를 사용하기 때문에 SQL 쿼리, 함수 호출 출력 등을 캐싱하는 데 매우 효율적입니다.

워드프레스 플러그인

  • WP Redis, 공식 Redis WordPress 플러그인. WP-CLI, 클러스터링 및 복제를 지원합니다.
  • Redis Object Cache WordPress용 또 다른 백엔드 Redis 플러그인.
  • Memcached의 백엔드인 Memcached 개체 캐시.
  • 만료된 일시적인 항목 삭제, 이 플러그인은 데이터베이스에서 만료된 일시적인 개체를 삭제합니다. 멀티사이트도 지원합니다!

벤치마크 실행 방법

우리 기사의 요점은 개체 캐싱에 대해 흥미를 갖게 하고 스스로 땜질을 시작하는 것입니다. 다양한 영구 캐시 구현을 시도하고 애플리케이션이 얼마나 잘 작동하는지 확인할 수 있습니다. PHP의 microsecond() 함수를 사용하여 호출을 벤치마킹할 수 있습니다. 예: wp_cache_get() 호출 전후에 microsecond() 를 호출하고 값을 빼고 결과를 저장합니다. 다양한 캐시 구현에 대해 이 작업을 수행하고 어떤 경우에 성능이 향상되는지 확인합니다.

Pressidium에서는 기본적으로 개체 캐싱이 활성화되어 있지 않으며 이것이 요청할 수 있지만 일반적으로 처음부터 권장하지 않습니다. 우리는 테스트를 실행하고 귀하의 사이트가 이점을 얻을 수 있는지 확인합니다.

결론

페이지를 렌더링하기 위해 애플리케이션이 2,000개의 임시 개체를 읽어야 한다고 가정해 봅시다. 이는 데이터베이스에서 2,000번의 읽기를 의미합니다. 영구 개체 캐싱 시스템을 사용하면 이러한 2,000개의 읽기가 키-값 저장소로 오프로드됩니다. memcached를 사용하는 경우 갑자기 다시 시작할 때 모든 캐시를 잃을 위험이 있습니다. 일반적으로 Redis는 Memcached만큼 빠르지 않을 수 있지만 Enterprise 기능과 지속성은 장기적으로 이점을 제공합니다.

그러나 하나의 크기가 모든 사람에게 맞지는 않습니다! 예를 들어, 실제로 웹 사이트 속도를 늦추는 Redis 인스턴스를 보았고 다른 경우에는 웹 사이트 속도를 엄청나게 높였습니다. 이것은 애플리케이션이 사용하는 많은 객체와 관련이 있습니다. 일반적으로 애플리케이션이 몇 개(12개라고 가정해 봅시다)를 사용하는 경우 객체 캐싱에서 많은 이점을 얻지 못하고 최악의 경우 네트워크 오버헤드가 있습니다. 그러나 응용 프로그램이 수백 개라면 살펴보는 것이 좋습니다.