답변:
Nginx에 WordPress를 설치할 수 있습니다. 도움이되는 많은 자료가 있습니다 :
마지막 링크의 성능 정보 (다른 설정과 약간 다른 설정으로 표시됨) :
그래서 나는 워드 프레스 앞에 프록시를 가능한 한 정적 캐시에두기로 결정했다. 인증되지 않은 모든 트래픽은 nginx 파일 캐시에서 직접 제공되며, 일부 요청 (예 : RSS 피드 생성)을 6 페이지 / 초에서 7000+ 페이지 / 초로 가져옵니다. 돈. Nginx는 또한 로깅 및 gzipping을 처리하여 더 많은 백엔드 아파치 (backend)가 최선을 다하도록합니다. 필요할 때만 동적 워드 프레스 페이지를 제공합니다.
...
nginx에서 – 매우 효율적입니다. 나는 우리의 가장 무거운 부하에서도 10에서 15 메가 이상의 RAM과 한 번의 CPU를 사용하는 것을 본 적이 없습니다. 우리의 신경절 그래프는 거짓말을하지 않습니다 : 우리는 메모리 요구량을 절반으로 줄이고 나가는 네트워크 처리량을 두 배로 늘리고로드를 완전히 수 평화했습니다. 우리는 이것을 설정 한 이후 기본적으로 아무런 문제가 없었습니다.
CSS, 이미지, 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
합리적으로 할 수있는 모든 것을 미리 압축하고 (7-zip이 좋은 도구 임) 방금 압축 한 파일과 같은 위치에 업로드 할 수 있습니다. 아래와 같이 미리 압축 된 파일을 제공하도록 .htaccess를 변경하십시오. 여기서주의해야 할 점은 업데이트 할 때 다시 압축해야한다는 것입니다. 이것은 .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는 슈퍼 캐시와 위에서 설명한 만료 헤더와도 잘 작동합니다.
Firebug (Firefox) 등에서 Yslow를 사용하여 http 요청과 압축 및 압축되지 않은 내용을 모니터링하십시오. 만료 헤더도 살펴보십시오. 곧 개선 할 수있는 것을 보게 될 것입니다.
실제로 필요한만큼만 실행하는 플러그인 수를 최소화하십시오. 특히 페이지에서 해당 코드를 사용하지 않는 경우에도 모든 페이지로드에 자바 스크립트 및 CSS 코드를 추가하는 플러그인에주의하십시오.
자신 만의 테마를 처음부터 작성하는 경우 특정 페이지 템플리트 또는보기 유형 (단일 게시물, 아카이브, 카테고리 등)에만 필요한 기능이 필요할 때만로드되도록 CSS를 분류하십시오.
CDN (Amazon CloudFront 또는 W3TC가 지원하는 다른 것)을 사용하도록 W3TC를 구성하십시오.
축소 옵션이 제대로 작동하는지 확인하십시오 (일부 플러그인은 멋지게 축소되지 않는 js / css를 생성하므로 축소 기능을 활성화 한 후 사이트를 테스트하십시오).
MySQL 서버를 완전히 제어 할 수있는 경우 query_cache가 설정되어 있는지 확인하십시오. MySQL 조정 스크립트 를 사용 하여 데이터베이스 구성을 최적화하는 다른 방법을 찾으십시오.
어떤 이유로 CDN 사용에 문제가 있으면 아파치 설정에서 mod_expires를 구성하십시오. 이미지, CSS, 자바 스크립트, 비디오, 오디오 등과 같은 정적 유형에 적합한 만료 시간을 설정하십시오.
memcached를 실행 하고 오브젝트 캐시 를 사용하여 데이터베이스 쿼리 수를 줄이십시오. 페이지가 아닌 데이터베이스의 데이터를 캐시합니다. w3total-cache가 이미이 작업을 수행하는지 확실하지 않습니다.
APC 와 같은 opcode 캐시를 실행 중인지 확인하십시오 . (사용 가능한 몇 가지가 더 있습니다.)
wp-cache와 같은 디스크 캐싱 플러그인을 사용하는 것 외에도 블로그에 "noatime"속성이 설정된 호스트 볼륨에 블로그를 배치하십시오. 그렇지 않으면, 호스트에 SSH (웹 호스트가 제공하는 경우)하고 며칠마다 파일에서이 명령을 정기적으로 실행하십시오.
chattr -R +A ~/*~ / *는 "내 홈 디렉토리에있는 파일"을 의미합니다. 적합하다고 생각되는 경로를 변경할 수 있습니다. 웹 호스트가 제공하는 경우 cpanel의 cron 작업에서이를 설정할 수도 있습니다.
atime 속성에 대한 자세한 내용은 this를 참조 하십시오 . Linux 디스크 읽기 성능이 크게 향상됩니다.
때로는 사이트가 거미에 의해 망치고 있습니다. SpyderSpanker 또는 Chennai Central과 같은 도구를 사용하여 귀하의 사이트에 더 많은 페이지 순위를 가져 오는 데 도움이되지 않고 단순히 속도를 늦추는 데 도움이되지 않는 스파이더를 필터링 한 다음, Google, Bing 등과 같은 좋은 스파이더를 무작위로 보내 스로틀 링 할 수 있습니다. HTTP 304 Not Modified 메시지.
내가 보는 또 다른 것은 잘못 작성된 플러그인입니다. 플러그인을 만드는 방법을 배우면 일부 플러그인이 비효율적으로 코딩되는 방법을 보거나 채우기 및 채우지 않고 정리되지 않는 데이터베이스 테이블과 같은 시한 폭탄을 찾아서 들어오는 연결 데이터와 같은 것을 저장합니다.
여기에있는 다른 모든 솔루션 외에도 블로그의 WordPress 웹 팜을 하나의 단일 데이터베이스에 다시 연결하고 파일의 단일 디스크 볼륨 (예 : NFS를 통해 마운트 된 볼륨)에 연결하는 여러 웹 노드 PC에 호스팅하여 블로그의 WordPress 웹 팜을 만들 수도 있습니다. ). 모든 것을 얻는 방법은 Ultra Monkey 를 확인하십시오 .
내 머리 꼭대기에서 몇 가지 답변 :
1) 가능한 경우 / 실제로 JavaScript와 CSS를 연결하여 브라우저가 호스트에 수행해야하는 HTTP 요청 수를 최소화하십시오.
2) 특히 공유 호스팅을 사용하는 경우 가능한 많은 이미지 / 미디어를 타사 CDN에 제공하십시오.
3) 전체 렌더링 시간을 줄이기 위해 첫 페이지에 표시되는 게시물 수를 줄이십시오.
3a) 첫 페이지에 몇 개의 추천 게시물을 모두 표시하는 주제와 다른 모든 오래된 게시물을 발췌로 사용해보십시오.
워드 프레스 메뉴를 캐싱하면 성능이 향상됩니다. 특히 페이지가 많거나 메뉴 구조가 크면이를 고려해야합니다.
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_menus를로 바꿉니다 get_cached_menu. 이제 메뉴가 호출 될 때마다 전체 메뉴 작성 대신 하나의 데이터베이스 쿼리가 있습니다.
메뉴는 자주 바뀌지 않지만 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 );
}
다음에 페이지를 호출 할 때 메뉴가 생성되며 누군가 메뉴를 다시 업데이트 할 때까지 캐시 된 버전을 사용하십시오.
업데이트 된 버전
슬러그와 ID 사이의 실수를 지적한 @helgatheviking에게 감사드립니다. 그것으로 모두 작동, 그래서 나는 기능을 업데이트 theme_position하고 menu(메뉴의 직접 호출).
메뉴는 항상 테마의 위치가 아니라 메뉴 이름으로 저장됩니다.
$nav_menu_selected_idis는 숫자 인 반면, get_cached_menu()the를 호출 할 때는 menu_id매개 변수가 <ul>요소 의 CSS ID가되기 때문에 the 는 문자열 변수 입니다.
최적화를 위해 정리 된 데이터베이스 클래스를 사용하십시오. 우리는 메모리 사용과 데이터베이스 액세스 속도를 줄이기 위해 자체 코드로 좋은 경험을했습니다. 그 외에도 많은 부분을 약간 변경하여 데이터베이스 구조 자체를 최적화 할 수 있습니다.
데이터베이스 클래스 코드의 일부는 wordpress trac에서 찾을 수 있지만 코어로 만들지 않았습니다 ( Ticket # 11799 및 related ).
트래픽이 많은 사이트의 경우 현재 존재하는 콘텐츠에 대한 모든 MySQL 버퍼를 조정해야합니다. WordPress의 버전에 관계없이 MySQL 계층은 구성을 계산할 수 있습니다 .
실제로 innodb_file_per_table을 활성화하지 않고 InnoDB 데이터가있는 경우 각 테이블을 자체 물리적 테이블 스페이스로 분할하여 InnoDB를 정리해야합니다 . 하드웨어가 제한되어 있어도 괜찮은 MySQL 튜닝이 가능합니다 . 이러한 InnoDB 최적화를 수행하기위한 많은 시나리오 가 있습니다 .
IMHO, 구성 할 데이터의 양을 모르면 my.cnf에 적합한 설정을 계획 할 수 없습니다. 프로덕션에서 스테이징 환경으로 현재 데이터 세트를 주기적으로로드하고 최적화를 수행하며 프로덕션 서버의 my.cnf에서 구성 할 숫자를 제거해야합니다.
전역 출력 압축을 활성화 할 수 있습니다 . 브라우저가 지원하면 모든 것이 자동으로 꺼집니다. 이렇게하면 전송되는 파일의 크기가 크게 줄어들지 만 CPU로드는 증가합니다.
최근에 WordCamp Houston 에서이 주제에 대해 이야기했습니다 . 위의 모든 권장 사항이 훌륭하고 중요한 것은 모든 프런트 엔드 항목을 완전히 최적화 한 다음 캐싱 및 서버 성능 문제에 대한 작업을 시작할 수 있다는 것입니다.
프로그레시브 렌더링을 사용하면 페이지 내용이 완전히로드되기 전에 페이지 내용을 볼 수 있으므로 페이지 느낌이 더 빨라집니다. 이렇게하려면 차단 js가 페이지 맨 아래에 있고 CSS가 맨 위에 오도록하십시오.
또한 많은 소셜 미디어 버튼을 사용하는 경우 페이지가 완전히로드 된 후 스크립트가 iframe에로드되도록 스크립트를 사용자 정의 할 수 있습니다. TweetMeMe 트윗 버튼으로 트위터를 사용하는 방법에 대한 튜토리얼을 작성했지만 (트위터가 자체 리트 윗 버튼을 출시 한 이후에는 더 이상 사용되지 않음) 여전히 다른 공유 버튼에 적용 할 수 있습니다.
서버 성능을 위해 Apache가 무거운 PHP 및 MySQL 리프팅을 처리하는 정적 컨텐츠의 프론트 엔드 프록시로 Nginx를 살펴보십시오.
아무도 언급하지 않았으므로 LAMP 설정과 함께 서버 성능을 향상시키는 가장 중요한 단계 중 하나는 아파치 작업자 스레드와 mod_fcgid로 전환하는 것입니다.
가상 사설 서버에서 500MB의 메모리를 확보했습니다.
페이지로드 시간 이라는 타이머가 페이지 바닥 글에 추가 되는 아름답고 간단한 플러그인 이 있습니다. 실제로 네 줄의 코드 만 있습니다.
<?php
function ur_pageload_footer() {
printf(__('Page in %s seconds', 'pageload'), timer_stop());
}
add_action('wp_footer', 'ur_pageload_footer')그때:
스프레드 시트는 다음과 같아야합니다.
+-------+-------+-------+-------+--------+
| Run 1 | Run 2 | Run 3 | Order | Plugin |따라서 플러그인을 비활성화 한 후 페이지 응답 시간이 크게 증가하면 해당 플러그인을 피할 수 있는지 확인할 수 있습니다.
나는 '중요한' mqtranslate 및 (오래되었지만 좋은) 다중 레벨 탐색 플러그인을 느리게하는 두 개의 플러그인을 발견했습니다 .
스틱 W3 총 캐시 워드 프레스의 캐싱 기능을위한 플러그인. 플러그인의 설정 페이지에서 페이지 캐싱 및 데이터베이스 캐싱을 활성화하십시오. 캐싱 메커니즘으로 '대체 PHP 캐시 (APC / APCu)'를 선택해야합니다. 사이트의 모양 및 / 또는 기능이 손상 될 가능성이 많으므로 W3 Total Cache를 축소하지 마십시오. Cloudflare로 남겨 두겠습니다.
나머지 플러그인 기능 구성을 마쳤 으면 웹 사이트에 Cloudflare를 설정하십시오. 'Extensions'아래의 W3 Total Cache 설정에서도 Cloudflare를 활성화해야합니다.
Cloudflare는 사이트의 모든 정적 컨텐츠 (이미지 파일, CSS, JS, 문서 등)를 캐시하고 글로벌 서버에서 방문자에게 제공하는 컨텐츠 전송 네트워크입니다. 이렇게하면 페이지로드 시간을 단축하고 서버의로드를 줄일 수 있습니다. Cloudlfare 점검에 의해 캐시되는 파일 유형 목록은 이 목록을 참조하십시오 . 또한 Cloudflare에는 무료 요금제가 있습니다.
Cloudflare에서 캐싱 수준을 표준으로 설정하고 브라우저 캐시 만료를 20 시간 이상으로 설정하십시오. 서버가 다운 되더라도 Cloudflare가 웹 사이트의 정적 페이지를 캐시에서 제공하도록 Always Online ™을 활성화하십시오. 또한 자동 축소 기능을 사용하도록 설정하십시오 (클라우드 플레어가 더 잘 수행하므로 축소를 사용하지 않도록 요청한 이유는 무엇입니까?를 기억하십시오!) 그런 다음 Rocket Loader ™를 자동으로 설정하십시오.
다음은 Rocket Loader가 수행 한 내용 중 일부입니다.
페이지 렌더링 속도 저하를 피하기 위해 JavaScript 파일 (타사 리소스 포함)을 번들링하여 네트워크 요청 수를 줄입니다.
페이지의 내용이
즉시 로드되는 것을 차단하지 않도록 타사 스크립트를 포함한 스크립트를 비동기 적 으로로드 합니다.
로컬
브라우저 ( 대부분의 브라우저 및 스마트 폰 에서 사용 가능한 LocalStorage를 사용하여)로 캐싱 하므로
필요한 경우가 아니면 다시 가져 오지 않습니다 .
자세한 내용은 여기를 참조하십시오 .
워드 프레스에 대한 창세기 프레임 워크에 가능한 스위치는 그들없이 깨끗하기 때문에 경우 어떤 부풀게. Genesis는 속도와 SEO를 염두에두고 구축되었습니다. 나는 그것을 직접 테스트했고 PageSpeed 점수는 좋았습니다. 또한 Genesis를 사용하는 경우 W3 Total Cache 설정에서 조각 캐시를 활성화하는 것을 잊지 마십시오.
Cloudlfare를 CDN으로 사용하고 있으므로 TingPNG에서 ' Imagify '또는 ' JPEG & PNG 이미지 압축 ' 과 같은 플러그인 을 사용하여 이미지를 압축 할 수 있습니다. 둘 다 WordPress.org 플러그인 저장소에서 사용 가능한 무료 플러그인입니다. 또한 Imagify는 강력한 손실 압축 알고리즘을 지원합니다.
마지막으로 CSS 및 JS 파일과 같은 정적 리소스에서 쿼리 문자열을 제거하도록 WordPress 리포지토리에서 ' 정적 리소스에서 쿼리 문자열 제거 '플러그인을 설치 하십시오 . URL에“?”또는“&”가있는 리소스는 일부 프록시 캐싱 서버에 의해 캐시되지 않기 때문입니다 (Cloudflare는 프록시 캐싱 서버이기도 함).
그런 다음 ' Use Google Libraries '플러그인을 설치 하십시오 . 이 플러그인을 사용하면 WordPress 사이트에서 WordPress 설치에서 이러한 파일을 직접 제공하지 않고 Google의 AJAX 라이브러리 API CDN을 사용할 수 있습니다.
다음과 같은 장점이 있습니다.
마지막 으로 Ruhani Rabin 의 ' WP-Optimize '플러그인을 사용하여 데이터베이스를 정리하고 최적화하십시오.
서버로드를 줄이기 위해 WordPress를 최적화하는 것과 관련하여 귀하의 질문에 대답하기를 바랍니다.