it-swarm-ko.tech

WordPress를 서버로드에 맞게 최적화하는 단계는 무엇입니까?

W3 Total Cache 또는 다른 캐싱 플러그인을 설치하는 것 외에도 가능한 한 빨리 내 테마와 사이트가 실행되는지 확인하기 위해 어떤 단계를 거쳐야하는지.

80
Paul Sheldrake

Nginx에 WordPress를 설치할 수 있습니다. 도움이되는 여러 가지 리소스가 있습니다.

마지막 링크의 일부 성능 정보 (다른 링크보다 약간 다른 설정 인 것 같습니다) :

그래서 나는 가능한 한 많은 정적 캐시에 wordpress 앞에 프록시를두기로 결정했다. 모든 인증되지 않은 트래픽은 nginx 파일 캐시에서 직접 제공되며 RSS 피드 생성과 같은 일부 요청 (6 페이지/초에서 7000+ 페이지/초)을 취합니다. 돈. Nginx는 또한 로깅과 gzipping을 처리하고, 무거운 백엔드 apache가 최선을 다하도록합니다. 필요할 때만 동적 워드 프레스 페이지를 제공하십시오.

...

Nginx에서 - 너무 효율적이어서 무서워. 나는 우리의 부하가 가장 큰 상태에서도 10 ~ 15 meg의 RAM과 CPU를 사용하는 것을 본 적이 없다. Ganglia 그래프는 거짓말하지 않습니다. 우리는 메모리 요구량을 절반으로 줄이고 나가는 네트워크 처리량을 두 배로 늘려 부하를 완전히 줄였습니다. 우리는 기본적으로 아무 문제가 없었습니다.

31
Travis Northcutt

Css, images, JavaScript 등의 페이지 뷰마다 다시 다운로드 할 필요가없는 클라이언트 측 만료를 설정하십시오. 이것은 지금까지 사이트 로딩 시간과 가장 큰 차이를 보였습니다. 가장 빠른 다운로드는 결코 발생하지 않은 다운로드입니다 ...

# BEGIN Expire headers
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 7200 seconds"
  ExpiresByType image/x-icon "access plus 2592000 seconds"
  ExpiresByType image/jpeg "access plus 2592000 seconds"
  ExpiresByType image/png "access plus 2592000 seconds"
  ExpiresByType image/gif "access plus 2592000 seconds"
  ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
  ExpiresByType text/css "access plus 2592000 seconds"
  ExpiresByType text/javascript "access plus 2592000 seconds"
  ExpiresByType application/x-javascript "access plus 2592000 seconds"
  ExpiresByType text/html "access plus 7200 seconds"
  ExpiresByType application/xhtml+xml "access plus 7200 seconds"
</IfModule>
# END Expire headers

# BEGIN Cache-Control Headers
<IfModule mod_headers.c>
  <FilesMatch "\\.(ico|jpe?g|png|gif|swf|gz)$">
    Header set Cache-Control "max-age=2592000, public"
  </FilesMatch>
  <FilesMatch "\\.(css)$">
    Header set Cache-Control "max-age=2592000, public"
  </FilesMatch>
  <FilesMatch "\\.(js)$">
    Header set Cache-Control "max-age=2592000, private"
  </FilesMatch>
<filesMatch "\\.(html|htm)$">
Header set Cache-Control "max-age=7200, public"
</filesMatch>
# Disable caching for scripts and other dynamic files
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
</IfModule>
# END Cache-Control Headers

합리적으로 할 수있는 모든 것을 미리 gzip 할 수 있습니다 (7-Zip은 좋은 도구입니다). 방금 gzipped 한 파일과 같은 위치에 업로드하십시오. .htaccess를 변경하여 미리 압축 해제 된 파일을 제공하십시오. 여기에주의해야 할 점은 업데이트 할 때/다시 gzip을 기억해야한다는 것입니다. 이렇게하면 .htaccess를 구문 분석하는 것 외에 CPU 오버 헤드가 제거됩니다.

RewriteEngine on
#Check to see if browser can accept gzip files. If so and we have it - serve it!
ReWriteCond %{HTTP:accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Safari
#make sure there's no trailing .gz on the url
ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$
#check to see if a .gz version of the file exists.
RewriteCond %{REQUEST_FILENAME}.gz -f
#All conditions met so add .gz to URL filename (invisibly)
RewriteRule ^(.+) $1.gz [QSA,L]

이것은 단지 원시 응답입니다. 이 주제에는 많은 변형이 있습니다. 나는 이것에 관해 블로그를 작성했고 http://icanhazdot.net/2010/03/23/some-wordpress-stuff/ 에서 더 자세한 기사에 대한 많은 참고 자료를 추가했다. 더 중요한 것은 필자가 지적한 참고 자료입니다. 훌륭한 자료입니다.

자주 문제가 발생하면 사용자는 캐시를 새로 고침해야합니다.

내가 찾은 플러그인은 wp-minify 입니다. 이 하나와 함께 볼 일은 페이지 별 항목 (연락처 양식, 앞 페이지 슬라이더 등)을 제외시켜야하므로 각 페이지마다 CSS, JS 등의 전체 세트를 다시 다운로드하지 않는 것입니다. 베이스 라인 CSS, JS 등을 축소, 결합 및 압축하는 좋은 방법입니다. HTTP 요청을 많이 줄입니다. Wp-minify는 supercache 및 위에서 자세히 설명한 만료 헤더와도 잘 작동합니다.

파이어 폭스 (Firebug) 나 그와 비슷한 Yslow를 사용하여 http 요청과 압축 여부를 모니터하십시오. 만료 헤더도 거기에서보십시오. 곧 개선 할 수있는 것을 보게 될 것입니다.

26
CAD bloke

실행할 플러그인의 수를 최소화하십시오. 특히 코드가 페이지에서 사용되지 않는 경우에도 모든 페이지로드시 자바 스크립트 및 CSS 코드를 추가하는 플러그인을 알아 두십시오.

자신 만의 테마를 처음부터 만드는 경우에는 CSS를 중단하여 특정 페이지 템플릿이나보기 유형 (단일 게시물, 아카이브, 범주 등)에 필요한 기능 만 필요할 때만로드 할 수 있습니다.

CDN (Amazon CloudFront 또는 W3TC가 지원하는 기타)을 사용하도록 W3TC를 구성합니다.

Minify 옵션이 효과가 있는지 확인하십시오 (일부 플러그인은 축소되지 않는 js/css를 생성하므로 축소 기능을 활성화 한 후 사이트를 테스트하십시오).

MySQL 서버를 완벽하게 제어 할 수 있다면 query_cache가 켜져 있는지 확인하십시오. MySQL 튜닝 스크립트 를 사용하여 데이터베이스 구성을 최적화하는 다른 방법을 찾으십시오.

어떤 이유로 CDN을 사용하는데 문제가 있다면, 아파치 설정에서 mod_expires를 설정하십시오. 이미지, CSS, 자바 스크립트, 비디오, 오디오 등과 같은 정적 유형에 적합한 만료 시간을 설정하십시오.

21
Dougal Campbell

memcached 를 실행하고 object cache 를 사용하여 데이터베이스 쿼리 수를 줄입니다. 이렇게하면 페이지가 아닌 데이터베이스의 데이터가 캐시됩니다. w3-total-cache가 이미 이것을 수행하는지 확실하지 않습니다.

APC 와 같은 opcode 캐시를 실행하고 있는지 확인하십시오. (몇 가지 더 사용할 수 있습니다.)

14
Annika Backstrom

Wp-cache와 같은 디스크 캐싱 플러그인을 사용하는 것 외에 "noatime"속성이 설정된 호스트 볼륨에 블로그를 올려 놓으십시오. 그렇지 않으면 SSH를 호스트에 넣고 (웹 호스트가 제공하는 경우) 며칠에 한 번 파일에 대해이 명령을 정기적으로 실행하십시오.

chattr -R +A ~/*

~/*는 "내 홈 디렉토리 아래에있는 내 파일"을 의미합니다. 해당 경로는 원하는대로 변경할 수 있습니다. 웹 호스트가 제공하는 경우 cpanel의 cron 작업에서이 값을 설정할 수도 있습니다.

Atime 속성에 대한 자세한 내용은 this 를 참조하십시오. Linux 디스크 읽기 성능을 크게 향상시킵니다.

때때로 귀하의 사이트가 거미에 의해 망치질되고 있습니다. SpyderSpanker 또는 Chennai Central과 같은 도구를 사용하여 사이트에 더 많은 페이지 순위를 올리고 속도를 느리게하는 데 도움이되지 않는 거미를 걸러 내고 (Google, Bing 등과 같은) 좋은 거미를 무작위로 보내서 차단할 수 있습니다 HTTP 304 Not Modified 메시지.

내가 보는 또 다른 것은 단지 잘못 작성된 플러그인 일뿐입니다. 플러그인을 작성하는 방법을 배우면 일부 플러그인이 비효율적으로 코딩되는 방식을 보거나 수신 데이터가 채워지거나 채워지지 않고 절대로 제거되지 않는 데이터베이스 테이블과 같은 시한 폭탄을 발견하기 시작합니다.

다른 모든 솔루션 외에도 블로그가 하나의 단일 데이터베이스에 다시 연결되는 여러 웹 노드 PC에 호스팅하여 블로그의 WordPress 웹 팜을 만들 수도 있고 파일에 대해 하나의 단일 디스크 볼륨 (예 : NFS를 통해 마운트 된 볼륨 ). 울트라 원숭이 그 모든 걸 얻는 방법에 대해 알아보십시오.

8
Volomike

내 머리 꼭대기에서 몇 가지 대답 :

1) 가능한/실제 환경에서 JavaScript와 CSS를 연결하여 브라우저가 호스트에해야하는 HTTP 요청 수를 최소화하십시오.

2) 특히 공유 호스팅을 사용하는 경우 가능한 한 많은 수의 이미지/미디어를 타사 CDN에 제공하십시오.

3) 전체 렌더링 시간을 줄이기 위해 첫 페이지에 표시 할 글의 수를 줄이십시오.

3a) 프론트 페이지의 일부 특집 게시물과 다른 모든 오래된 게시물을 발췌문으로 제시하는 테마를 사용해보십시오.

7
ZaMoose

워드 프레스 메뉴를 캐싱하면 성능이 향상됩니다. 특히 페이지 나 커다란 메뉴 구조가 많은 경우이를 고려해야합니다.

2 단계로 쉽게 수행하십시오. 먼저 wp_nav_menu를 직접 호출하는 대신 메뉴를 가져 오거나 만드는 함수를 만듭니다.

function get_cached_menu( $menuargs ) {

    if ( !isset( $menuargs['menu'] ) ) {

        $theme_locations = get_nav_menu_locations();
        $nav_menu_selected_id = $theme_locations[$menuargs['theme_location']];
        $termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );
        $transient = 'menu_' . $termslug->slug . '_transient';

    } else {

        $transient = 'menu_' . $menuargs['menu'] . '_transient';

    }


    if ( !get_transient( $transient ) ) { // check if the menu is already cached

        $menuargs['echo'] = '0'; // set the output to return
        $this_menu = wp_nav_menu( $menuargs ); // build the menu with the given $menuargs
        echo $this_menu; // output the menu for this run
        set_transient( $transient, $this_menu ); // set the transient, where the build HTML is saved

    } else {

        echo get_transient( $transient ); // just output the cached version

    }

}

귀하의 테마에서 wp_nav_menuget_cached_menu로 대체하십시오. 이제는 메뉴가 호출 될 때마다 전체 Menubuilding 대신 하나의 Databasequery가 있습니다.

메뉴는 자주 변경되지 않지만 이전 일시적 요소를 삭제하려면 wp_update_nav_menu 작업에 연결해야합니다.

다음과 같이하십시오.

add_action('wp_update_nav_menu', 'my_delete_menu_transients');

function my_delete_menu_transients($nav_menu_selected_id) {

    $termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );

    $transient = 'menu_' . $termslug->slug . '_transient';

    delete_transient( $transient ); 

}

메뉴는 다음에 페이지를 호출 할 때 생성되며 다른 사용자가 메뉴를 다시 업데이트 할 때까지 캐시 된 버전을 사용합니다.

업데이트 된 버전

굼벵이와 신분증 사이에 실수를 지적 해 주신 것에 대해 @helgatheviking 해줘서 고맙습니다. 함수를 업데이트하여 theme_positionmenu (메뉴 직접 호출)에서 모두 작동합니다.

메뉴는 항상 테마의 위치가 아니라 메뉴의 이름으로 저장됩니다.

7
fischi

최적화를 위해 손질 된 데이터베이스 클래스를 사용하십시오. 우리는 메모리 사용 및 데이터베이스 액세스 속도를 줄이기 위해 자체 코드로 좋은 경험을했습니다. 그 다음으로, 데이터베이스 구조 자체를 최적화 할 수 있습니다.

데이터베이스 클래스 코드의 일부는 wordpress trac에서 찾을 수 있습니다. 핵심 ( Ticket # 11799 및 관련 )으로 만들지 않았습니다.

5
hakre

트래픽이 많은 사이트의 경우 현재 존재하는 콘텐츠에 대한 모든 MySQL 버퍼를 조정해야합니다. WordPress의 버전에 관계없이 MySQL 레이어는 구성을 계산할 수 있음 .

실제로 innodb_file_per_table을 활성화하지 않고 InnoDB 데이터가있는 경우 각 테이블을 자체 물리적 테이블 스페이스로 세그먼트 화하여 InnoDB를 정리해야합니다 . 괜찮은 MySQL 튜닝을 할 수 있습니다 하드웨어가 제한되어 있어도 . 이러한 InnoDB 최적화를 수행하기위한 많은 시나리오 가 있습니다.

IMHO, 구성 할 데이터의 양을 모르면 my.cnf에 적합한 설정을 계획 할 수 없습니다. 프로덕션에서 스테이징 환경으로 현재 데이터 세트를 주기적으로로드하고 최적화를 수행하며 프로덕션 서버의 my.cnf에서 구성 할 숫자를 제거해야합니다.

4
RolandoMySQLDBA

나는 최근에 WordCamp Houston 에서이 주제에 관해서 이야기했습니다. 위의 모든 권장 사항은 훌륭하며 중요한 점은 모든 프런트 엔드 항목이 완전히 최적화되었는지 확인한 다음 캐싱 및 서버 성능 문제를 해결할 수 있다는 것입니다.

프로그레시브 렌더링을 사용하면 페이지 내용이 완전히로드되기 전에 사용자가 볼 수 있기 때문에 페이지가 더 빨리 표시됩니다. 이렇게하려면 차단 js 페이지의 맨 아래에 있고 CSS 상단에 있는지 확인하십시오.

또한 소셜 미디어 버튼을 많이 사용하는 경우 페이지가 완전히로드 된 후 iframe에로드되도록 스크립트를 사용자 정의 할 수 있습니다. TweetMeMe re Tweet 버튼 (트위터가 자신의 리트 윗 버튼을 릴리스 한 이후 현재는 사용되지 않음)을 사용하여 수행하는 방법에 대한 자습서를 작성했지만 다른 공유 버튼에도 적용 할 수 있습니다.

서버 성능을 위해 Nginx를 정적 컨텐츠의 프런트 엔드 프록시로 간주합니다. Apache는 무거운 PHP 및 MySQL 리프팅을 처리합니다.

3
Chris_O

당신은 global output compression 을 가능하게 할 수 있습니다. 브라우저가 지원하면 자동으로 나가는 모든 작업을 gzip으로 처리합니다. 이렇게하면 전송 된 파일의 크기가 크게 줄어들지 만 CPU로드가 증가합니다.

3
Scott M.

아직 아무도 언급하지 않았기 때문에 LAMP 설정과 함께 서버 성능을 향상시키는 가장 중요한 단계 중 하나는 Apache 작업자 스레드 및 mod_fcgid로 전환하는 것입니다.

이렇게하면 가상 사설 서버에서 500MB의 메모리를 확보 할 수 있습니다.

2
nottinhill

플러그인 점검 속도 가이드

Page Load Time 이라는 아름답게 간단한 플러그인이 있습니다.이 플러그인은 페이지 바닥 글에 타이머를 추가합니다. 실제로 코드는 4 줄 밖에 없습니다.

<?php
function ur_pageload_footer() {
    printf(__('Page in %s seconds', 'pageload'), timer_stop());
}
add_action('wp_footer', 'ur_pageload_footer')

그때:

  1. 스프레드 시트 만들기
  2. 모든 활성 플러그인을 나열하고 거기에 넣으십시오.
  3. 페이지를 새로 고침 할 때마다 페이지로드 시간을 세 번 표시합니다.
  4. 플러그인을 하나씩 비활성화하여 비활성화하십시오.
  5. 3 단계를 반복하십시오.
  6. 플러그인을 비활성화 한 순서에 유의하십시오.

스프레드 시트는 다음과 유사해야합니다.

+-------+-------+-------+-------+--------+
| Run 1 | Run 2 | Run 3 | Order | Plugin |

따라서 플러그인을 비활성화 한 후 페이지 응답 시간이 유의하게 증가하면 해당 플러그인을 피할 수 있는지 확인할 수 있습니다.

'중요한'느린 mqtranslate 와 (다소 오래되었지만 좋은) 다중 레벨 탐색 플러그인 을 유발 한 두 개의 플러그인을 발견했습니다.

1
icc97