안녕하세요 여러분. 우리는 WordPress 사이트 속도를 높이는 주제를 계속합니다. CSS, HTML 및 Javascript를 축소하여 WordPress 속도를 높이는 방법 기사에서 파일에서 불필요한 항목을 제거했지만 전부는 아닙니다. 일반적으로 WordPress의 좋은 점은 다양한 요구 사항에 맞게 원하는 방식으로 코드를 변경할 수 있다는 것입니다. 물론 호스팅을 구매할 때 고려해야 할 사항은 다음과 같습니다.

다음 사항에 관심이 있을 수도 있습니다.

웹사이트용 파비콘을 만드는 방법

파비콘은 브라우저의 사이트 이름 옆에 모든 사람이 볼 수 있는 아름다운 아이콘입니다. Favicon을 사용하면 귀하의 사이트가 브라우저 북마크와 북마크 모두에서 눈에 띄게 표시됩니다.

사이트의 아름다운 버튼

모두에게 좋은 하루 되세요. 갑자기 웹사이트에 아름다운 버튼을 배치하고 싶은데 찾을 수 없는 사람들이 있습니다. 사실 검색엔진에 검색해봤는데..

예시 404 페이지

안녕하세요, 내 블로그 독자 여러분. 이 기사는 전혀 아무것도 아닙니다. 드디어 404페이지까지 읽었습니다.

제목 및 설명 태그가 작성되는 방법 및 위치

제목 및 설명 태그란 무엇입니까? 이러한 태그는 사이트를 최적화하는 데 필요합니다. 태그가 잘못 작성되면 검색 엔진이 기사를 색인화하지 않습니다. 많은...

더 나은 SEO 및 사용자 경험을 위해 전문가는 항상 최종 사용자에게 권장합니다. 이러한 맥락에서 사이트를 방문하는 사용자가 많으면 WordPress 대시보드의 응답이 느려질 수 있습니다.

온라인 속도 테스트 도구를 사용하여 WordPress 사이트의 속도를 테스트하는 동안 파일이 관리자-ajax.php느린 로딩 경험을 담당합니다. 이 기사에서는 이 파일에 대해 설명하고 admin-ajax.php에서 생성된 요청 수를 줄여 서버 응답 시간과 CPU 사용량을 줄이는 방법을 설명합니다.

WordPress의 admin-ajax.php는 무엇입니까?

2013년에 WordPress는 로그인 만료 시 자동 저장 기능, 다른 사용자가 WordPress에서 게시물을 작성하거나 편집하는 동안 금지 경고와 같은 몇 가지 중요한 기능을 제공하는 WordPress Heartbeat API를 도입했습니다.

Heartbeat API의 두 가지 매우 독특한 기능:

1. 자동 저장

게시물 초안을 저장하고 작업을 계속할 때마다 WordPress는 게시물 추가 사항을 자동으로 저장합니다. 프로젝트 자동 저장과 수동 저장 사이에는 분명한 차이가 있습니다. 두 가지 유형의 저장을 모두 보여주는 다음 스크린샷을 확인하세요.

2. 메시지 차단

다른 사용자가 작업 중인 게시물을 편집하려고 할 때마다 해당 상황에 대한 경고 팝업이 표시됩니다. 세 가지 작업을 수행할 수 있습니다.

위 기능은 해당 메시지와 응답에 대해 서버와 브라우저 간의 연결을 생성하는 WordPress Heartbeat API를 통해 가능합니다.

WordPress Heartbeat API는 서버와 통신하기 위한 요청을 생성하고 데이터 수신/응답을 위한 이벤트를 발생시킵니다. 이는 일반적으로 서버의 로드를 증가시키고 궁극적으로 WordPress 관리 패널의 속도를 저하시킵니다.

살아있는 예

WordPress 대시보드에 로그인하여 게시물 편집을 시작했습니다. 다음으로 탭을 몇 분 동안 열어두고 다른 탭을 탐색하기 시작했습니다. 계기판은 여전히 ​​시스템에 있으며 다음을 볼 수 있습니다. 관리자-아약스지속적으로 요청을 보냅니다.

위에서 언급한 티켓에 따르면 WordPress의 admin-ajax.php는 15초마다 요청을 생성합니다. 요청은 서버에 대한 모든 연결이 될 수 있습니다.

WordPress 관리자 패널 속도 향상

WordPress 백엔드 속도를 높이려면 Heartbeat API를 비활성화하거나 최소한 몇 초마다 서버에 대한 요청을 생성하지 않도록 더 긴 기간으로 설정하는 것이 가장 좋습니다.

하트비트 제어 플러그인 설치

WordPress 관리자에 로그인하고 다음으로 이동하세요. 플러그인 >> 새로 추가, 찾다 하트비트 제어, 설치하다그리고 활성화하다그의.

탭으로 이동 설정 >> 하트비트 설정 제어. 거기에는 플러그인을 구성하기 위한 세 가지 드롭다운 메뉴가 있습니다.

Heartbeat API가 작동할 영역을 선택할 수 있습니다. 선택할 수 있는 옵션은 세 가지가 있습니다.

• WordPress 대시보드: 그러면 WordPress 패널에서 Heartbeat API가 활성화됩니다.
• 프런트엔드: 웹 인터페이스에서 API가 활성화됩니다.
• 메시지 편집기: Heartbeat API에서 자동 저장 및 메일 차단 기능을 활성화하려면 이 확인란을 선택하세요.

특정 위치에서 WordPress Heartbeat API를 비활성화하려면 이 옵션을 선택하십시오. 다른 플러그인도 WordPress Heartbeat API를 사용할 수 있으므로 위치를 선택할 때 주의하세요. 귀하가 WordPress 백엔드의 유일한 사용자라면 모든 곳에서 이를 비활성화한 다음 웹사이트가 손상되는지 확인하는 것이 좋습니다. 그러나 사이트에 정기적으로 기여하는 사용자가 두 명 이상인 경우 게시물 편집 페이지에서만 Heartbeat API를 활성화하는 것이 좋습니다.

이 드롭다운 메뉴를 사용하면 관리 Ajax 요청을 실행하는 시간 간격을 0 - 300초 범위로 설정할 수 있습니다. 에 설치하면 120초, 그러면 요청이 120초마다 생성됩니다. 이렇게 하면 서버의 부하가 크게 줄어듭니다. 귀하의 필요에 맞게 사용자 정의하십시오.

여러 규칙 만들기

요구 사항에 따라 여러 규칙을 만들 수 있습니다. 예를 들어, WordPress가 120초마다 실행되지만 편집 후에는 60초 동안 실행되도록 하려고 합니다. 이렇게 하려면 두 가지 규칙을 만들어야 합니다. 하나는 WordPress 대시보드용이고 다른 하나는 게시물 편집기용이며 빈도를 각각 120과 60으로 설정합니다.

이제 모든 설정이 완료되었으므로 admin-ajax.php 파일을 사용하여 어떤 플러그인이 웹사이트 속도를 늦추는지 확인할 차례입니다.

GTmetrix로 이동하여 사이트 URL을 입력하세요. 사이트를 분석하는 데 몇 분 정도 걸립니다. 그런 다음 폭포 탭으로 이동하면 파일이 연결 및 응답하는 데 걸리는 시간을 확인할 수 있습니다. 조금 아래로 스크롤하여 항목이 있는지 확인하세요. POST 관리자-ajax.php. 그렇다면 확장하고 게시물 탭으로 이동하세요. 여기에서 범인을 식별할 수 있습니다. 우리의 경우 "데스크톱 스위치" 플러그인은 admin-ajax.php 파일을 사용하고 지속적으로 서버에 요청을 보냅니다. 이제 다른 플러그인으로 교체할지 아니면 제거할지 결정을 내려야 할 때입니다.

마지막 말

기능 세트를 고려할 때 Heartbeat API는 WordPress 사이트에서 매우 유용합니다. 그러나 올바르게 사용하지 않으면 WordPress 백엔드와 사이트 자체의 로딩 시간이 늘어나 WordPress에 요청을 주고받을 수 있습니다.

이 문제에 대한 해결책은 두 가지뿐입니다. 또는 Heartbeat API를 비활성화하거나 일부 위치에서만 활성화하십시오.

W3TC와 같은 캐싱 플러그인을 사용하는 경우 개체 캐시를 비활성화해야 합니다. 또한 WordPress 대시보드 속도도 향상됩니다.

제안이나 요청 사항이 있으시면 아래에 언제든지 의견을 남겨주세요.

WordPress 작업 시 일반적인 시나리오는 admin-ajax.php의 사용량 증가를 진단하는 것입니다. 한동안 WordPress를 사용했다면 타사 속도 테스트를 실행하거나 서버 액세스 로그를 확인할 때 이 문제가 발생했을 가능성이 높습니다. 일반적으로 admin-ajax.php의 사용 증가는 타사 플러그인 사용 또는 Heartbeat API를 기반으로 하는 관리자 패널의 캐시할 수 없는 요청(예: 자동 저장 초안)과 관련이 있습니다. admin-ajax.php에 대한 조회수가 이렇게 급증하면 사이트를 사용할 수 없게 될 수 있으므로 즉시 식별하는 것이 매우 중요합니다. WordPress의 admin-ajax.php 문제를 해결하려면 아래 권장 사항을 확인하세요.

admin-ajax.php 파일은 무엇입니까?

admin-ajax.php 파일 자체는 올바르게 사용하면 나쁘지 않습니다. 코어의 일부 역할을 합니다. 이 파일은 WordPress 개발 팀이 릴리스 3.6에 추가했습니다. admin-ajax.php의 목적은 AJAX를 사용하여 브라우저와 서버 간의 연결을 생성하는 것입니다. 이를 통해 여러 작성자가 게시물을 편집할 때 향상된 자동 저장, 버전 추적, 로그인 시간 초과, 세션 관리 및 게시물 잠금 알림을 포함한 고급 기능을 사용할 수 있습니다. 이러한 모든 기능은 특히 여러 작성자와 관리자가 있는 사이트를 지원하는 사용자에게 유용합니다.

“15초마다 서버에 XHR 요청을 보내고 데이터가 수신되면 이벤트(또는 콜백)를 실행하는 비교적 간단한 API를 구현하는 것이 아이디어입니다. 다른 구성 요소도 다른 사용자의 활동에 대한 알림을 "연결"하거나 받을 수 있습니다. 이는 위젯이나 메뉴의 동시 편집 또는 서버에서 정기적인 업데이트가 필요한 기타 작업을 차단하는 데 사용할 수 있습니다."

기술적으로 능숙한 사용자가 아닌 한, admin-ajax.php의 맥락에서 당신에게 중요할 유일한 상황은 이 파일이 테스트(예: Pingdom)에서 속도가 느려지는 이유를 이해하려고 노력하는 것입니다. 또는 호스팅 액세스 로그에서 이 파일에 대한 여러 요청을 볼 수도 있습니다.

속도 테스트 및 액세스 로그에 admin-ajax.php가 나타나는 것은 일반적으로 프런트엔드와 백엔드라는 두 가지 시나리오의 결과입니다. 이에 대해서는 나중에 이야기하겠습니다.

플러그인으로 인해 admin-ajax.php 속도가 느려질 수 있음

admin-ajax.php 환경에서 사용자가 직면하는 가장 일반적인 문제는 타사 플러그인으로 인해 발생합니다. 이는 일반적으로 프런트 엔드에서 볼 수 있으며 속도 테스트에서도 나타납니다. 개발자는 이 파일이나 AJAX를 사용하여 플러그인에 기능을 추가합니다. admin-ajax.php에 대한 요청이 표시된다고 해서 반드시 사이트 속도가 느려지는 것은 아닙니다. AJAX는 페이지가 표시된 후 로드되며 일부 요청은 비동기적으로 로드될 수 있습니다. 하지만 이것이 항상 개발자가 다운로드를 올바르게 수행하고 성능 측면에서 효율적인 코드를 작성했다는 의미는 아닙니다.

다음은 admin-ajax.php의 속도 저하를 신속하게 진단한 방법의 예입니다. 우리는 개별 게시물과 응답 데이터를 검사할 수 있기 때문에 GTmetrix를 사용했습니다. 안타깝게도 Pingdom에서는 양식의 데이터 요청을 볼 수 없습니다. Google Chrome Devtools 또는 WebPageTest를 사용할 수도 있습니다.

Visual Composer 플러그인을 사용할 때 admin-ajax.php의 로드가 높음

다음은 admin-ajax.php를 사용할 때 매우 높은 대기 시간을 경험했던 WordPress 사이트입니다. GTmetrix에서 볼 수 있듯이 admin-ajax.php에 대한 요청 대기 시간은 8초가 넘습니다. 나머지 "폭포"는 괜찮아 보이지만 이 지연은 사이트 소유자가 해결해야 합니다.

POST admin-ajax.php 요청을 클릭하면 Headers, Post 및 Response의 세 가지 탭이 표시됩니다. 우리가 보고 있는 문제를 진단할 때 게시 및 응답 탭에만 관심이 있습니다. 힌트는 응답 탭에서 볼 수 있습니다. 요청의 일부가 vc_shortcodes-custom-css 스크립트와 연결되어 있음을 알 수 있습니다.

Google에 빠르게 복사하여 붙여넣으면 문제가 Visual Composer 플러그인으로 인해 발생했음을 알 수 있습니다.

사용자의 다음 단계는 Visual Composer 플러그인이 완전히 최신 상태인지 확인하는 것입니다. 그렇다면 플러그인 개발자에게 연락하여 admin-ajax.php의 문제에 대해 알려야 합니다. 이는 실제로 스택 오버플로의 게시물로 판단하면 상당히 일반적인 문제입니다. 개발자가 플러그인에서 문제를 해결할 수 없는 경우 거의 동일한 작업을 수행하는 여러 대체 플러그인이 항상 존재합니다. 이것이 바로 WP의 힘입니다. 예를 들어 페이지 빌더가 필요한 경우 Beaver Builder 또는 Elementor를 사용해 볼 수 있습니다.

알림 표시줄 플러그인으로 인해 admin-ajax.php의 대기 시간이 길어짐

우리가 직면한 두 번째 예는 타사 플러그인을 설치한 후에 발생했습니다. admin-ajax.php에 대한 요청이 급격히 증가한 것을 확인했습니다.

다시 한번 admin-ajax.php POST 요청을 클릭하면 모든 내용을 자세히 탐색할 수 있습니다. 데이터에 "action=mtsnb_add_impression&bar_id=88&ab_variation=none" 문자열이 포함되어 있는 것을 볼 수 있습니다.

정확하게 말하면 게시 작업의 첫 번째 부분은 일반적으로 플러그인의 CSS 클래스를 참조합니다. 우리는 "mtsnb"에 대한 빠른 Google 검색을 수행하고 이 클래스가 우리 사이트에서 실행 중인 알림 표시줄 플러그인에서 사용된다는 것을 발견했습니다.

개발자라면 어떤 플러그인이 POST 응답을 생성하는지 추적하는 다른 방법이 있지만 이 문서에 설명된 방법이 매우 효과적이라고 생각합니다.

admin-ajax.php 요청의 소스를 결정하는 구식 방법

위에서 우리는 admin-ajax.php에서 이 문제를 일으킬 수 있는 WordPress 사이트에서 플러그인을 찾는 몇 가지 간단한 방법을 제공했습니다. 우리의 경험에 따르면 이러한 방법은 99%의 경우에 효과가 있습니다. 그러나 POST 데이터나 작업이 명확하지 않을 수도 있으므로 입증된 기존 방식을 따라야 합니다. WordPress 사이트에서 모든 플러그인을 비활성화하기만 하면 됩니다. 속도 테스트를 실행합니다. admin-ajax.php가 어디에도 없으면 각 플러그인을 차례로 활성화하고 속도 테스트를 수행하십시오. 이렇게 하면 문제가 있는 플러그인을 빠르게 식별할 수 있습니다.

백엔드의 admin-ajax.php 관련 CPU 문제

두 번째 주요 문제는 WordPress Heartbeat API가 admin-ajax.php를 사용하여 웹 브라우저에서 AJAX 호출을 트리거하므로 CPU 사용량이 높아질 수 있다는 것입니다. 또한 각 AJAX 요청은 모든 형태의 캐싱을 우회하여 전체 WordPress 백엔드를 로드합니다. 일반적으로 속도 테스트에서는 이 현상이 표시되지 않습니다. 저렴한 공유 호스팅을 사용하는 사람들은 CPU에 관해서는 흔들릴 여지가 많지 않기 때문에 이 사실을 아는 것이 특히 중요합니다. 이 문제는 이전에 HostGator 호스팅에서 나타났습니다.

매우 주의해야 할 시나리오 중 하나는 WordPress에 자동 저장되고 탭이 열려 있는 것입니다. 예를 들어, 웹사이트에서 새 프로젝트를 시작하고 탭을 열어 두었습니다. Heartbeat API는 기본적으로 15초마다 admin-ajax.php 파일을 폴링하여 자동 저장을 수행합니다. 이는 액세스 로그에서 확인할 수 있습니다. 탭을 하루 동안 열어두면 게시물 하나가 하루에 5,760개의 요청을 생성할 수 있습니다.

한 사람에 대한 백엔드 요청이 너무 많습니다. 귀하의 사이트에 여러 명의 편집자가 있다면 어떤 일이 일어날지 상상해 보십시오. 이러한 요청은 기하급수적으로 증가할 것입니다. 우리는 Shark Tank에 대한 WooCommerce 사이트 확장을 도왔던 DARTDrones를 연구하는 동안 이 문제를 접했습니다. 하루에 admin-ajax.php에 대한 호출이 4100건이 넘는 반면 방문자는 2000명에 불과했습니다. 이는 방문 대비 요청 비율이 가장 좋지 않습니다. 우리 연구에 따르면 대부분의 요청이 콘솔에서 발생하는 것으로 나타났습니다. 이러한 요청은 관리자가 사이트를 업데이트하고 표시할 준비를 하고 있기 때문에 생성되었습니다.

자동 저장, 개정, 기록 잠금 등과 관련하여 백엔드에서 admin-ajax.php 호출과 관련된 일부 문제를 감지하는 방법이 있습니다. 이렇게 하려면 Heartbeat Control 플러그인을 설치해야 합니다.

Heartbeat Control 플러그인은 현재 50,000개가 넘는 사이트에 설치되어 있으며 평점은 5점 만점에 5점입니다. 업데이트된 지 2년이 지났지만 Heartbeat API도 업데이트되지 않았기 때문에 여전히 동일하게 작동합니다.

플러그인을 사용하면 몇 번의 클릭만으로 WordPress Heartbeat API 호출 빈도를 제어할 수 있습니다. 첫 번째 옵션을 사용하면 하트비트의 위치를 ​​제어할 수 있습니다. 예를 들어 하트비트를 모든 곳에서 비활성화하거나 편집 후 페이지에서만 허용할 수 있습니다. 플러그인을 완전히 비활성화하면 Heartbeat API에 의존하는 일부 플러그인의 작동이 중지될 수 있으므로 후자 옵션을 사용하는 것이 좋습니다.

두 번째 옵션을 사용하면 폴링 빈도를 설정할 수 있습니다. 15초에서 60초로 변경하면 요청 횟수와 서버 리소스를 크게 절약할 수 있습니다(CPU 부하 감소).

perfmatters와 같은 프리미엄 플러그인을 사용하여 하트비트를 끄고, 폴링 빈도를 변경하고, 자동 저장 간격을 수정할 수도 있습니다.

결론

보시다시피 admin-ajax.php의 문제를 진단하고 수정하기 위한 빠르고 쉬운 옵션이 몇 가지 있습니다. 일반적으로 서로 충돌할 수 있거나 코드베이스가 좋지 않은 타사 플러그인으로 인해 나타납니다.

귀하의 웹사이트에서 이 문제가 발생했습니까? 그렇다면, 당신의 이야기를 공유해주세요.

세계에서 가장 인기 있는 무료 CMS 사용자를 위한 유용한 조언의 흐름은 끝나지 않을 것입니다. 바로 인기가 있고 기억해야 할 중요한 기능이 있기 때문입니다. 이전에 우리는 다음 방법에 대해 이야기했습니다.

오늘 우리는 두 번째 테마를 조금 확장하고 리소스 집약적이며 모든 사람이 WordPress 메커니즘을 필요로 하는 것은 아닙니다. 하트비트 API.

하트비트 API— 다음과 같은 기능을 제공하는 WordPress 기능

• 자동 저장;
• 한 사람이 게시물이나 페이지를 편집하는 동안 다른 사이트 편집자를 위해 게시물이나 페이지를 잠그는 행위
• 사용자가 아직 관리 부분(콘솔)에 있다는 정보를 업데이트합니다.

이는 귀하의 브라우저(사이트를 편집하는 곳)와 서버(사이트가 저장된 곳) 사이의 연결을 유지함으로써 이루어집니다.

실제로 이는 관리 패널의 거의 모든 페이지에서 하나의 특정 파일 admin-ajax.php에 대해 15-30초 간격(설치된 버전에 따라 다름)으로 지속적인 요청으로 표현됩니다. 한 번에 여러 콘솔 탭을 열어 두려는 경우 상황은 더욱 악화됩니다. 요청은 각 탭에서 자동으로 전송됩니다. 사실은, HeartBeat API는 모든 표준 WordPress 메커니즘 중에서 가장 리소스 집약적입니다..

오늘 이 기능을 비활성화하겠습니다. 다음과 같은 경우 WordPress 사이트에 대해 HeartBeat API를 비활성화하는 것이 좋습니다.

• 일반적으로 귀하의 사이트에는 귀하의 계정에 충분한 리소스가 있습니다. 초과는 콘솔에서 작업하는 동안에만 발생합니다.;
• 사이트는 귀하에 의해서만 편집됩니다.(즉, 사이트에는 여러 명이 아닌 1명의 편집자가 있습니다).

주목!이 솔루션은 모든 사이트에 적합하지 않습니다. 이는 사이트에 설치된 테마, 플러그인 및 개별 사이트 설정에 따라 다릅니다. 시도해 볼 수 있으며 사이트의 어떤 요소와도 호환되지 않거나 중요한 사이트 기능에 영향을 미치는 것으로 판명되면 언제든지 이전 설정을 반환하여 HeartBeat API를 활성화할 수 있습니다.

HeartBeat API를 비활성화하는 방법

이렇게 하려면 파일을 변경해야 합니다. 함수.php사이트의 현재 활성 테마(템플릿)가 있는 폴더 내부. 이는 파일 관리자나 FTP를 통해 수행할 수 있습니다.

function.php 파일의 경로는 다음과 같습니다: /path_to_site_root/wp-content/themes/theme_name/functions.php.

태그 뒤 파일 맨 앞에 추가

Add_action("init", "stop_heartbeat", 1); 함수 stop_heartbeat() ( wp_deregister_script("heartbeat"); )

이 줄은 전체 사이트에 대해 HeartBeat를 비활성화합니다.

하트비트 제어 플러그인

HeartBeat API를 완전히 비활성화하는 것보다 덜 급진적인 솔루션도 있습니다. 특별한 플러그인으로 제공됩니다 하트비트 제어. 설치하고 활성화한 후 설정(도구 -> 하트비트 제어)으로 이동하세요. 설정에서 다음 옵션을 선택할 수 있습니다.

1. 전체 사이트에 대해 HeartBeat를 비활성화할지 아니면 관리 패널에서 게시물을 편집하고 게시하는 페이지와 같이 사이트의 특정 섹션에서만 HeartBeat 사용을 허용할지 여부.

2. admin-ajax.php 파일에 대한 요청 빈도. 기본적으로 15초일 수 있습니다. 예를 들어 이 값을 60초로 변경하면 이러한 쿼리에 대한 리소스 소비를 최대 75%까지 줄입니다.!

기억해야 할 중요한 것

• HeartBeat API를 비활성화하여 자동 저장 기능을 비활성화했습니다. 편집된 페이지와 게시물을 주기적으로(필요에 따라) 저장하세요.

• 사이트의 테마(템플릿) 수준에서는 HeartBeat API가 비활성화되어 있으므로, 테마(템플릿)를 변경하는 순간부터 HeartBeat API가 다시 작동됩니다. 사이트에서 사용하기 시작하는 새로운 테마마다 비활성화 절차를 반복해야 합니다.

• 현재 테마 업데이트에도 동일하게 적용됩니다. 업데이트 후에는 종료 절차를 반복해야 합니다.

즐거운 일 되시길 바랍니다!

내 사이트를 점점 더 집요하게 두드리기 시작한 문제로 인해 이 게시물을 작성하지 않을 수 없었습니다. 문제는 사이트 페이지를 열고 관리자 패널에서 작업하는 것입니다. 너무 강렬하고 빈번해져서 작은 메시지조차 작성하기가 어려워졌습니다. 서버 연결이 계속 끊어졌습니다. 소위 소프트 한도(Soft Limit)를 초과하는 것을 의미하는 CPU의 높은 부하가 지속적으로 발생했습니다. 저는 Metrica와 Jetpack 플러그인으로부터 작업을 하지 않는 시간에도 사이트를 사용할 수 없는 경우가 많다는 이메일 메시지를 자주 받기 시작했습니다. 요컨대 사이트 속도 문제로 인해 끔찍한 공포가 다시 나를 덮쳤습니다. 그리고 제가 호스팅하는 'Gino'의 지원 서비스에 다시 연락했습니다.

바로 답변이 왔고, 간단한 설명과 추가 대화를 통해 문제의 본질을 이해하고 해결할 수 있었습니다.

호스팅 지원은 무엇보다도 요청이 많다는 점에 주목했습니다. /wp-admin/admin-ajax.php.“사이트의 관리 패널에서 작업 생성을 요청합니다. 이 동작은 플러그인 중 하나가 올바르게 작동하지 않는 경우 일반적입니다. 사이트 플러그인을 하나씩 비활성화하고 작동을 모니터링하세요. 문제가 있는 플러그인을 발견하면 업데이트를 시도하거나 안정적인 버전을 설치하거나 문제를 일으키지 않는 아날로그로 교체해 보세요.”

내 사이트에는 꽤 많은 플러그인이 설치되어 있으며 각 플러그인을 개별적으로 확인하는 것은 매우 문제가 됩니다. 따라서 기술 지원팀이 플러그인에 대해 남겨둔 링크에 주의를 기울였습니다. 하트비트 제어. 그것을 설치하고 다른 설정으로 인해 문제가 해결되었습니다!

기술 지원 서비스에서는 또 다른 문제를 지적하고 wp-cron.php 파일의 코드를 수정하기 위한 몇 가지 조치를 제안했습니다. 하지만 메시지 끝에 이 문제에 대해 설명되어 있습니다.

자, 이제 위의 본질로 넘어 갑시다.

WordPress의 Heartbeat API는 무엇이며 이를 제한하는 방법

"Heartbeat"라는 단어는 "Heartbeat"로 번역되며 API에서 그렇게 부르는 데에는 이유가 있습니다. 서버에 특정 빈도의 요청을 제공합니다. 기본적으로 관리자 패널 페이지에 따라 이는 레코드를 편집할 때 - 15초마다, 콘솔에서 작업할 때 - 1분 등 다양한 간격으로 발생합니다. WordPress Heartbeat API는 다음을 제공하는 기능입니다.

• 메시지 작성 시 자동 저장;
• 한 사람이 게시물이나 페이지를 편집하는 동안 다른 사이트 편집자의 게시물이나 페이지를 차단하는 행위
• 사용자가 아직 관리 부분(콘솔 또는 게시물 편집 페이지)에 있다는 정보를 업데이트합니다.

WordPres 엔진에 작성된 이 기능은 매우 중요합니다. 특히 여러 명의 작성자가 사이트에서 작업할 수 있고 관리가 집단적인 경우에는 더욱 그렇습니다. 그러나 이로 인해 사이트 속도가 느려지고 서버 부하가 크게 증가할 수도 있습니다.

귀하가 사이트의 유일한 작성자인 경우 Heartbeat API 기능을 완전히 비활성화하거나 귀하에게 편리한 모드로 구성하여 서버의 로드를 조절할 수 있습니다.

Heartbeat API를 완전히 비활성화

내가 원하지 않았던 이 어려운 시나리오는 현재 사이트에 설치된 테마의 function.php 파일에서 일부 작업을 수행해야 한다는 것입니다.

Add_action("init", "stop_heartbeat", 1); 함수 stop_heartbeat() ( wp_deregister_script("heartbeat"); )

물론, 이 테마를 업데이트하거나 다른 테마로 교체할 때 이 작업을 다시 수행해야 합니다.

Heartbeat Control 플러그인 및 해당 설정

설정은 두 가지뿐이며, 플러그인이 영어로 되어 있음에도 불구하고 이 언어를 모르는 사람들도 이해하기 어렵지 않을 것입니다. 플러그인을 설정하는 방법을 알려드리겠습니다. 기본값 사용이는 어떤 페이지에서도 Heartbeat API가 비활성화되지 않았으며 서버에 대한 요청 간격이 15초임을 의미합니다.즉, 모든 것이 이 플러그인이 귀하의 사이트에 없는 것처럼 보입니다.

4. 관리자 패널 페이지 설정 사용

명확성을 위해 다음을 명확히 하겠습니다.

1. 기본값 사용 - 기본적으로 Heartbeat API를 사용합니다.
2. 모든 곳에서 비활성화 — 모든 곳에서 Heartbeat API를 비활성화합니다.
3. 대시보드 페이지에서 비활성화 — 대시보드 페이지(콘솔)에서 Heartbeat API를 비활성화합니다.
4. 사후 편집 페이지에서만 허용 - 페이지 편집 시에만 Heartbeat API를 사용합니다.

2. 서버에 대한 요청 빈도 조정

여기에서는 모든 것이 매우 간단합니다. 북쪽으로의 적절한 요청 간격을 선택하기만 하면 됩니다. "펄스"가 드물어질수록(요청이 드물어짐) 서버에 가해지는 부하가 줄어듭니다.

설정을 마친 후 변경 사항을 저장하십시오.

편집 중 녹음 자동 저장은 여전히 ​​바람직한 기능이므로(나중에 특수 플러그인으로 정리하여 불필요한 편집 내용을 삭제할 수 있음), 기술적인 이유로 거의 완료된 녹음을 잃는 것은 불쾌합니다(인터넷 끊김 또는 서버 연결 끊김 등). )은 매우 바람직하지 않습니다. 따라서 필드의 첫 번째 블록에 대한 설정을 "기본값 사용" 모드로 설정할 수 있지만 요청 빈도 타이머를 admin-ajax.php 파일에 설정하므로 두 번째 블록에 설정해도 충분합니다. . V 60초 이러한 요청에 대한 리소스 소비를 최대 75%까지 줄입니다.!

물론 웹사이트 속도가 느려지는 데는 여러 가지 이유가 있습니다. 적절한 지식과 함께 작업하지 않으면 우리는 매우 바람직하지 않은 프로세스의 원인이 무엇인지 알 수 없습니다. 기술 지원 호스팅을 포함하여 전문가에게 더 자주 연락해야 할 것입니다.

기사 시작 부분에서 지원 담당자가 내 사이트 운영에 어려움을 겪는 또 다른 이유를 지적했다고 언급했습니다. 이유 -

wp-cron.php 파일의 원치 않는 프로세스

기술 지원팀은 내 사이트의 운영을 조사한 결과 "wp-cron.php 프로세스가 관찰됩니다"라는 사실을 발견했습니다. 그들은 다음과 같이 권장했습니다. "이 파일을 실행하면 서버에 비정상적인 로드가 발생하는 경우 이 작업을 비활성화할 수 있습니다."

1. WordPress 구성 파일에서 이를 수행하려면 wp-config.php다음 줄을 추가하세요.
   정의('DISABLE_WP_CRON', '참');
   언어를 설치한 후 어딘가에 추가할 수 있습니다. 라인 뒤에
   정의('WPLANG', 'ru_RU');
2. 또 다른 해결책은 파일 자체에 있습니다 wp-cron.php다음 줄을 주석 처리하세요: wp-cron.phpignore_user_abort(true); 이렇게 하려면 앞에 이중 슬래시를 붙여야 합니다. 다음과 같이 나타납니다. //ignore_user_abort(true);이 줄은 파일의 12행에 있습니다.

그게 다야, 친구들.

(304회 방문, 오늘 1회 방문)