문서, CSS, 이미지를 제공하기 전 느린 Apache 웹 서버 응답

문서, CSS, 이미지를 제공하기 전 느린 Apache 웹 서버 응답

WordPress(PHP 및 MySQL)를 실행하는 웹사이트가 있습니다. 웹사이트가 요청에 매우 느리게 응답합니다.

Safari에서 웹 검사기를 살펴보니 문제는 파일 크기가 아닌 것 같습니다.

http://img.skitch.com/20100127-1yjnf586wdr3tx4akk8fj5qwhx.png

콘텐츠를 제공하는 데 5초가 걸립니다. 내가 취할 수 있는 조치는 무엇입니까? 저는 서버 관리를 처음 접했고 이것은 단지 공유 서버입니다. 제가 완전히 제어할 수는 없지만 최적화해 볼 가치가 있을 수 있습니다.

traceroute명령 을 시도했지만 ping문제 없이 명령이 작동합니다.

답변1

서버에서 실제 문제 해결을 수행하려면 관리자 권한이 필요합니다.

그러나 이것이 귀하의 코드인지 서버의 오류인지 확인하려는 경우(), 취할 수 있는 몇 가지 단계가 있습니다. 그 중 하나는 PHP 코드에 타이머를 추가하여 서버에서 실행하는 데 걸리는 시간을 확인하는 것입니다. 에서여기:

<!-- put this at the top of the page --> 

<?php 
  $mtime = microtime(); 
  $mtime = explode(' ', $mtime); 
  $mtime = $mtime[1] + $mtime[0]; 
  $starttime = $mtime; 
?> 

<!-- put other code and html in here --> 

<!-- put this code at the bottom of the page --> 
<?php 
  $mtime = microtime(); 
  $mtime = explode(" ", $mtime); 
  $mtime = $mtime[1] + $mtime[0]; 
  $endtime = $mtime; 
  $totaltime = ($endtime - $starttime); 
  echo 'This page was created in ' .$totaltime. ' seconds.'; 
?>

이를 사용하면 서버가 실제로 느린지, 연결이 끊어진 상태인지 확인할 수 있습니다.

서버가 느린 경우 수행해야 할 여러 단계가 있지만 더 진행하려면 관리자 권한이 필요합니다. 특히 전 세계 수십만 개의 서버에 있고 상당히 최적화된 wordpress를 사용하고 있기 때문입니다.

한 가지 더 시도해 볼 수 있는 방법은 플러그인을 비활성화하고 하나씩 활성화하여 속도 저하의 원인이 있는지 확인하는 것입니다.

답변2

아마도 파일 크기와 관련이 없을 것입니다. WordPress를 실행하는 경우 백로그는 데이터베이스와 프로세서가 됩니다. 페이지의 모양, 콘텐츠 등에 대한 모든 정보를 복구하기 위한 데이터베이스. 그리고 모든 내용을 실제 문서로 컴파일하여 전송하기 위한 프로세서.

Apache의 캐시 설정을 조정해 보고 싶을 수도 있습니다. 특정 페이지가 자주 요청된다면 해당 페이지를 계속해서 구축할 필요가 없습니다.

답변3

Firefox를 사용해 보고 Firebug(http://getfirebug.com/). 설정이 완료되면 'net' 패널을 활성화하고 페이지를 다시 로드하십시오. 그러면 초기 연결 속도, 다운로드 시간, 서버 응답 지연 등을 포함하여 서버 응답의 각 부분에 걸리는 시간이 표시됩니다. 또한 이 패널을 사용하여 JavaScript, 이미지와 같은 항목을 캐시하고 있는지 확인할 수 있습니다. , CSS.

공유 호스팅을 사용하고 있기 때문에 서버 설정을 거의 제어할 수 없지만 서버에 요청하는 작업에 주의를 기울이면 다른 방법으로 작업 속도를 높일 수 있습니다.

GL! Firebug를 사용하는 데 익숙해지면 생명의 은인이 됩니다.

마지막으로, 가능한 최신 버전의 WordPress를 사용하고 있는지 확인하고 너무 많은 플러그인을 사용하지 마십시오. 오버헤드가 발생할 때마다 로드 속도가 느려집니다.

답변4

많은 CMS와 마찬가지로 Wordpress는 상당히 무거운 것으로 알려져 있습니다. 공유 서버가 첫 번째 바이트를 제공하기 위해 이와 같은 지연을 제공하는 것은 놀라운 일이 아닙니다.

가장 먼저 해야 할 일은 사용 가능한 opcode 캐시(php-apc가 "표준" 캐시)가 있는지 확인하는 것입니다. 이것이 없으면 Wordpress는 새로운 사용자가 요청할 때마다 홈페이지를 생성합니다. apc가 서버에 설치되어 있고 이를 구성할 수 있는 방법이 있으면 먼저 다음 구성을 시도해 볼 수 있습니다.

apc.enabled=1
apc.shm_size=64
apc.max_file_size=3M
apc.ttl=7200
apc.user_ttl=7200
apc.stat_ctime=1

그런 다음 패키지에 포함된 apc.php 스크립트에서 제공하는 통계를 살펴보면 설정하는 데 도움이 됩니다.그 가치좀 더 적절하게.

두 번째로 할 일은 다음과 같은 Wordpress용 캐시 플러그인을 사용하는 것입니다.http://wordpress.org/extend/plugins/w3-total-cache/

첫 번째 요청 시 콘텐츠를 렌더링한 다음 가능할 때마다 정적 콘텐츠를 제공합니다.

관련 정보