캐시된 PHP 생성 미리 보기가 느리게 로드됩니다.

캐시된 PHP 생성 미리 보기가 느리게 로드됩니다.

질문 A 파트 » (100 현상금, 수상)
주요 질문은 어떻게 하면 이 사이트를 더 빨리 로딩할 수 있는가 하는 것이었습니다.처음에 우리는 이 폭포들을 읽을 필요가 있었다.폭포 판독치 분석에 대한 당신의 제안에 감사드립니다.여기에 표시된 다양한 워터폴 그래프로 볼 때 주요 병목 현상인 PHP 생성 썸네일이 분명합니다.David가 조언한 CDN의 프로토콜 없는 jquery 로딩은 내 사이트를 전체적으로 3%만 빠르게 만들었지만 사이트의 주요 병목현상에 대한 응답은 하지 않았다.내 질문에 대한 해명과 또 다른 보상이 필요한 시간이다.

질문 B 파트 » (100 현상금, 수상)
새로운 초점은 로딩 지연의 가장 큰 원인이 되고 있는 6개의 jpg 이미지 문제를 해결하는 것이었습니다.이 6개의 이미지는 PHP에 의해 생성된 썸네일로 작으며 3~5kb밖에 되지 않지만 로딩이 비교적 느립니다.다양한 그래프에서 "첫 번째 바이트까지의 시간"에 주목하십시오.이 문제는 해결되지 않은 채로 남아 있었지만, RedBot이 밑줄 친 헤더 오류를 수정한 James에게 현상금이 주어졌습니다: "An If-Modified-Since conditional request returned full content."

질문 C 파트 ① (마지막 현상금 : 250점)
안타깝게도 REdbot.org 헤더 오류가 수정되어도 PHP가 생성한 이미지에 의한 지연은 변경되지 않았습니다.이 작은 3~5Kb 썸네일들은 도대체 무슨 생각을 하고 있는 걸까요?그 모든 머리글 정보는 달로 로켓을 보내고 돌아올 수 있다.저는 벌써 7개월째 이 병목현상에 빠져있기 때문에, 이 병목현상에 대한 어떠한 제안도 매우 고맙고 가능한 답변으로 취급됩니다.

[내 사이트의 배경 정보 : CSS는 맨 위에 있습니다.하단의 JS(쿼리,JQuery UI, 메뉴 awm/menu.js 엔진, 탭 js 엔진, 비디오 swfobject.js)를 구입했습니다.두 번째 이미지의 검은색 선은 로드 대상을 시작하는 항목을 나타냅니다.화가 난 로봇은 내 애완견 "잠"이다. 그는 무해하고 종종 더 행복해 한다.

---

워터폴 로드: 시간순 | http://webpagetest.org

---

병렬 도메인 그룹화| http://webpagetest.org

---

Site-Perf Waterpol | http://site-perf.com

---

Pingdom Tools Waterpal | http://tools.pingdom.com

---

GTmetrix Waterpol | http://gtmetrix.com

---

우선, 이러한 복수의 도메인을 사용하려면 , 몇개의 DNS 룩업이 필요합니다.요청을 퍼뜨리는 대신 많은 이미지를 스프라이트로 결합하는 것이 좋습니다.

둘째, 페이지를 로드하면 all.js의 블로킹(~1.25s)이 대부분 표시됩니다.(이전 버전의) jQuery로 시작하는군요.Google CDN에서 참조하면 로드 시간을 줄일 수 있을 뿐만 아니라 잠재적으로 이 CDN에 대한 HTTP 요청을 완전히 피할 수 있습니다.

특히 최신 jQuery 및 jQuery UI 라이브러리는 이러한 URL에서 참조할 수 있습니다(관심 있는 경우 이 게시물을 참조하십시오).http:):

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

//ajax.googleapis.com/ajax/libs/jqueryui/1.8.9/jquery-ui.min.js

기본 jQuery UI 테마 중 하나를 사용하는 경우 해당 CSS와 이미지를 Google CDN에서 가져올 수도 있습니다.

jQuery 호스팅이 최적화되어 있는 경우,awmlib2.js그리고.tooltiplib.js하나의 파일로 만듭니다.

이러한 문제에 대처하면, 대폭적인 개선을 기대할 수 있습니다.

며칠 전에도 비슷한 문제가 있어서 head.js를 찾았습니다.JS 파일 패러렐을 모두 로드할 수 있는 Javascript 플러그인입니다.도움이 됐으면 좋겠다.

전문가와는 거리가 멀지만...

이에 대해 "조건부 요청으로 내용 전체를 변경하지 않고 반환했습니다."라고 코멘트를 했습니다.

썸네일을 생성하는 데 사용되는 코드는 다음을 확인합니다.

1. 미리보기의 캐시된 버전이 있습니까?
2. 캐시된 버전이 원래 이미지보다 최신 버전입니까?

이 중 하나가 false일 경우 반드시 썸네일이 생성되어 반환됩니다.둘 다 참일 경우 다음 검사를 수행해야 합니다.

1. HTTP_가 있나요?IF_MODIFED_SHINCE
2. 캐시된 버전의 마지막 수정 시간이 HTTP_와 같습니까?IF_MODIFED_부터

이 중 하나가 거짓일 경우 캐시된 섬네일이 반환됩니다.

둘 다 true이면 304 http 상태가 반환됩니다.꼭 필요한지는 모르겠지만 304와 함께 개인적으로 Cache-Control, Expires 및 Last-Modified 헤더를 반환합니다.

GZipping에 대해서는 GZip 이미지가 필요없다고 하니 그 부분은 무시해 주세요.

편집: 게시물에 추가한 것을 알아차리지 못했습니다.

session_cache_limiter('public');
header("Content-type: " . $this->_mime);
header("Expires: " . gmdate("D, d M Y H:i:s", time() + 2419200) . " GMT");
// I'm sure Last-Modified should be a static value. not dynamic as you have it here.
header("Last-Modified: " . gmdate("D, d M Y H:i:s",time() - 404800000) . " GMT");

또한 당신의 코드가 HTTP_를 확인해야 한다고 확신합니다.IF_MODIFED_SHIS 헤더와 리액션을 실시합니다.이러한 헤더와 .htaccess 파일을 설정하는 것만으로는 필요한 결과를 얻을 수 없습니다.

이런 게 필요할 것 같아요

$date = 'D, d M Y H:i:s T'; // DATE_RFC850
$modified = filemtime($filename);
$expires = strtotime('1 year'); // 1 Year

header(sprintf('Cache-Control: %s, max-age=%s', 'public', $expires - time()));
header(sprintf('Expires: %s', date($date, $expires)));
header(sprintf('Last-Modified: %s', date($date, $modified)));
header(sprintf('Content-Type: %s', $mime));

if(isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) {
    if(strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) === $modified) {
        header('HTTP/1.1 304 Not Modified', true, 304);
        // Should have been an exit not a return. After sending the not modified http
        // code, the script should end and return no content.
        exit();
    }
}
// Render image data

와, 그런 이미지로는 설명하기 어렵네요.하지만 여기서 몇 가지 시도를 합니다.

• 파일 33~36은 SWF 내에서 동적으로 로드되기 때문에 추가 콘텐츠를 로드하기 전에 먼저 SWF(25)가 완전히 로드됩니다.
• 파일 20과 21은 all.js(11)에 의해 로드되는 (코드를 모르기 때문에) 라이브러리입니다만, 11이 실행될 때까지 페이지 전체(및 자산)가 로드될 때까지 기다립니다(이것을 domready로 변경해야 합니다).
• 파일 22~32는 이들 2개의 라이브러리에 의해 로드되며, 이들 라이브러리가 완전히 로드된 후 다시 로드됩니다.

이런 종류의 분석에는 많은 A/B 테스트가 필요하기 때문에 단순한 추측입니다.사용자의 .ch 도메인은 도달하기 어려운 것 같습니다(첫 번째 바이트가 도착하기 전에는 긴 녹색 대역).

이는 .ch 웹사이트가 제대로 호스트되지 않았거나 ISP가 적절한 경로를 가지고 있지 않음을 의미합니다.

이 그림을 보면 퍼포먼스가 크게 히트한 것을 알 수 있습니다.

참고로 자원 로딩 순서에 따라 분류할 수 있는 멋진 툴이 있습니다.

Y를 실행해 보세요!사이트/페이지에서의 저속 테스트와 페이지 속도 테스트를 실시합니다.또한 가이드라인에 따라 퍼포먼스의 병목현상이 발생할 수 있습니다.Y점수가 올라가면 퍼포먼스가 크게 향상됩니다!저속 또는 페이지 속도.

이 테스트들은 무엇이 잘못되었고 무엇이 바뀌어야 하는지를 알려줄 것입니다.

그럼 당신의 PHP 스크립트가 모든 페이지를 로드할 때마다 미리 보기를 생성한다는 건가요?우선, 썸네일 하고 있는 이미지가 그다지 자주 바뀌지 않는 경우는, 페이지가 로드될 때마다 해석하지 않아도 되도록 캐시를 설정해 주실 수 있습니까?두 번째로, 당신의 PHP 스크립트는 다음과 같은 것을 사용하고 있습니까?imagecopyresampled()썸네일을 작성하시겠습니까?이것은 간단한 다운샘플이 아니고, PHP 스크립트는 축소할 때까지 아무것도 반환하지 않습니다.사용.imagecopymerged()대신 이미지 품질은 떨어지지만 처리 속도는 빨라집니다.그리고 얼마나 깎아주실 건가요?이 썸네일은 원본 이미지의 5% 크기입니까, 아니면 50% 크기입니까?PHP 스크립트가 축소하여 작은 섬네일을 출력하기 전에 원본 이미지를 메모리에 저장해야 하기 때문에 원본 이미지의 크기가 커지면 속도가 느려질 수 있습니다.

귀사의 웹사이트 URL을 찾아 홈페이지에서 개별 jpg 파일을 확인하였습니다.로딩 시간은 현재(161ms)는 적당하지만 126ms를 기다리는 것은 무리입니다.

마지막으로 변경된 헤더는 모두 2011년 1월 1일 토요일 12:00:00 GMT로 설정되어 있습니다.이는 실제 생성 날짜로는 "둥근"으로 보입니다.-)

Cache-control이 "public, max-age=syslog15200"이므로 168일 후에 임의의 last-display 헤더가 문제를 일으킬 수 있습니다.

어쨌든, 이것이 지연의 진짜 이유는 아닙니다.

썸네일이 이미 존재하는 경우 썸네일 생성기의 기능과 사진 확인 및 전달에 시간이 걸리는 부분을 확인해야 합니다.

xdebug를 설치하여 스크립트를 프로파일하고 병목 현상이 있는 위치를 확인할 수 있습니다.

이 모든 것이 프레임워크를 사용하거나 데이터베이스와 무료로 연결되었을 수도 있습니다.일부 서버에서 매우 느린 mysql_connect()를 볼 수 있었습니다.주로 소켓이 아닌 TCP를 사용하여 접속하고 있기 때문입니다.DNS 문제가 있는 경우도 있습니다.

여기에 유료 발전기를 게시할 수 없다는 것은 알지만 문제가 너무 많습니다.

정당한 이유가 없는 경우(보통 없습니다), 이미지는 PHP 인터프리터를 기동하지 않습니다.

이미지가 파일시스템에 있는 경우 이미지를 직접 서버하는 웹 서버용 리라이트 규칙을 만듭니다.그렇지 않으면 PHP 스크립트로 수정하여 이미지를 생성합니다.이미지를 편집할 때 캐시된 버전을 가진 사용자가 새로 편집한 이미지를 가져오도록 이미지 파일 이름을 변경합니다.

그래도 작동하지 않으면 이미지 생성 및 확인 방법과는 관계가 없습니다.

PHP의 세션 데이터 사용을 조사합니다.아마도 (아마도) 이미지 생성 PHP 스크립트가 세션 데이터를 잠그기 위해 대기하고 있을 것입니다.세션 데이터는 아직 렌더링 중인 메인 페이지나 다른 이미지 렌더링 스크립트에 의해 잠겨 있습니다.이렇게 하면 브라우저가 서버를 대기하고 있기 때문에 모든 JavaScript/브라우저 최적화는 거의 무의미해집니다.

PHP는 세션 처리가 시작된 시점부터 스크립트가 종료된 시점까지 또는 session_write_close()가 호출될 때까지 실행 중인 모든 스크립트의 세션 데이터를 잠급니다.이것은 효과적으로 사물을 연재한다.세션의 PHP 페이지, 특히 이 코멘트를 확인해 주세요.

당신의 코드를 보지 않았기 때문에 이것은 추측일 뿐이지만 세션이 여기서 역할을 하고 있는 것 같습니다.다음은 의 PHP Manual 엔트리에서 나온 것입니다.

세션 데이터는 보통 스크립트가 종료된 후 session_write_close()를 호출할 필요 없이 저장되지만 동시 쓰기를 방지하기 위해 세션 데이터가 잠기므로 세션에서 작동할 수 있는 스크립트는 1개뿐입니다.프레임셋을 세션과 함께 사용하면 이 잠금으로 인해 프레임이 하나씩 로드됩니다.세션 변수에 대한 모든 변경이 완료되는 즉시 세션을 종료함으로써 모든 프레임을 로드하는 데 필요한 시간을 줄일 수 있습니다.

말했듯이, 네 코드가 뭔지는 모르겠지만 그 그래프들은 이상하게 수상해 보여.멀티파트 파일 서비스 기능을 코딩했을 때도 같은 문제가 있었습니다.대용량 파일을 제공할 때 멀티파트 기능을 사용할 수 없었고 다운로드가 완료될 때까지 다른 페이지를 열 수 없었습니다.전화로 두 가지 문제를 해결했어요.

php에서 생성된 thumnails를 일반 이미지로 대체하여 차이가 있는지 확인해 보셨습니까?문제는 주변일 수 있습니다.서버 기동 시마다 섬네일이 재생성되는 php 코드의 버그, 클럭 문제와 관련된 코드(sleep()?)의 지연, 모든 섬네일이 동시에 로드/생성되기 때문에 하드 드라이브의 문제가 발생할 수 있습니다.

썸네일 생성기 스크립트를 사용하는 대신 TinySRC에서 빠르고 클라우드 호스팅된 썸네일 생성을 시도해야 합니다.매우 심플하고 사용하기 쉬운 API를 갖추고 있어 다음과 같이 사용할 수 있습니다.

http://i.tinysrc.mobi/ [높이] / [폭] / http://domain.tld/path_to_img.jpg

[width] (옵션):- 픽셀 단위의 폭입니다(적응 크기 또는 패밀리 크기보다 우선합니다).앞에 '-' 또는 'x'가 붙으면 결정된 크기에서 빼거나 비율로 축소됩니다.

[height] (옵션):-폭도 존재하는 경우는, 픽셀 단위의 높이입니다.또한 적응형 또는 패밀리 크기를 재정의하고 접두사에 '-' 또는 'x'를 붙일 수 있습니다.

API 요약은 이쪽에서 확인하실 수 있습니다.

---

FAQ

tinySrc에 드는 비용

아무 것도 없어요.

언제부터 tinySrc를 사용할 수 있습니까?

지금이다.

서비스는 어느 정도 신뢰성이 있습니까?

tinySrc 서비스에 대해서는 보증하지 않습니다.그러나 대규모 분산 클라우드 인프라에서 실행되므로 전 세계적으로 고가용성을 제공합니다.당신의 모든 요구에 충분할 겁니다.

얼마나 빠른가요?

tinySrc는 크기 조정된 이미지를 최대 24시간 동안 메모리 및 데이터스토어에 캐시하며 매번 원래 이미지를 가져오지 않습니다.이것에 의해, 유저의 관점에서는 서비스가 매우 고속화됩니다(그리고, 뛰어난 부작용으로서 서버의 부하를 경감합니다).

---

행운을 빌어요.그냥 제안이야, 넌 우리에게 코드를 보여주지 않잖아:p

일부 브라우저는 도메인당 2개의 병렬 다운로드만 다운로드하므로 1.imagecdn.com과 같이 2~3개의 다른 호스트 이름으로 요청을 샤드하기 위해 도메인을 추가할 수 없습니다.

우선, 당신은 이 문제를If-Modified-SinceJames가 말한 대로 적절한 요청 등입니다.이 에러는, 「그 이미지가 전회 이후에 변경되고 있는지를 서버에 문의하면, 단순한 예/아니오 대신에 이미지 전체가 송신됩니다」라고 표시됩니다.

연결과 첫 번째 바이트 사이의 시간은 일반적으로 PHP 스크립트를 실행하는 데 걸리는 시간입니다.그 스크립트가 실행되기 시작할 때 뭔가가 일어나고 있는 것이 분명합니다.

1. 프로파일링 고려해봤어?문제가 있을 수 있습니다.
2. 위의 문제와 함께 스크립트가 필요한 횟수보다 많이 실행될 수 있습니다.이상적으로는 원본 이미지를 수정하고 다른 요청에 대해 캐시된 엄지손가락을 보내는 경우에만 엄지손가락을 생성해야 합니다.스크립트가 불필요하게 이미지를 생성하고 있는지 확인했습니까(예: 요청별로).

애플리케이션을 통해 적절한 헤더를 생성하는 것은 다소 까다롭고 서버에 의해 덮어쓰기될 수 있습니다.또한 캐시 없는 요청 헤더를 보내는 사람이 있으면 섬네일 생성기가 연속적으로 실행(및 부하 증가)되기 때문에 악용될 수 있습니다.따라서 가능하면 생성된 엄지손가락을 저장하고 저장된 이미지를 페이지에서 직접 호출하여 헤더를 관리합니다..htaccess이 경우, 당신은 아무것도 필요 없을 것이다..htaccess서버가 올바르게 설정되어 있는 경우.

이 외에도 쿠키를 사용하지 않는 하위 도메인으로 리소스를 나누는 등 웹 사이트를 올바르게 운영하는 방법에 대한 이 전반적으로 좋은 SO 질문의 성능 부분에서 얻은 몇 가지 밝은 최적화 아이디어를 적용할 수 있습니다.그러나 3k 이미지는 로드하는 데 1초도 걸리지 않습니다.이것은 그래프의 다른 항목과 비교하면 명백합니다.최적화하기 전에 문제를 찾아내야 합니다.

NGINX 웹 서버에서 이미지나 스타일시트 같은 정적 데이터를 제공하기 위해 여러 하위 도메인을 설정해 본 적이 있습니까?이 항목에서 유용한 정보를 이미 찾을 수 있습니다.

지연된 썸네일에 대해서는 썸네일 생성 스크립트에서 header()에 대한 마지막 호출 직후에 flush()에 대한 호출을 시도합니다.완료되면 워터폴 그래프를 재생성하여 지연이 헤더 대신 본문에 있는지 확인합니다.이 경우 이미지 데이터를 생성 및/또는 출력하는 로직을 자세히 검토해야 합니다.

썸네일을 처리하는 스크립트는 어떤 종류의 캐싱을 사용해야 합니다.이것에 의해, 사용하고 있는 이미지에 대해서 어떠한 액션이 행해지든, 반드시 필요한 경우에만 행해지게 됩니다.스크립트의 출력(헤더 포함)이 지연되는 썸네일을 제공할 때마다 고가의 작업이 발생하고 있는 것 같습니다.

느린 문제의 대부분은 TTFB(Time to first byte)가 너무 높다는 것입니다.서버 구성 파일, 코드 및 기본 하드웨어를 숙지하지 않고는 이 문제를 해결하기 어렵지만, 모든 요구에 대해 난무하는 것을 알 수 있습니다.녹색 막대가 너무 많고(나쁨), 파란색 막대가 너무 적습니다(좋습니다).프런트엔드의 최적화를 잠시 중단하는 것이 좋을 것 같습니다.그 분야에서는 많은 일을 해왔기 때문입니다."최종 사용자 응답 시간의 80%~90%가 프런트엔드에 소비된다"는 속설에도 불구하고, 백엔드에서 발생하고 있다고 생각합니다.

TTFB는 백엔드, 서버, 출력 및 핸드쉐이킹 전 처리입니다.

느린 데이터베이스 쿼리, 느린 함수/메서드의 입력/종료 시간 등 느린 함수를 찾기 위해 코드 실행 시간을 설정합니다.php를 사용하는 경우 Firephp를 사용해 보십시오.세션 정보 풀이나 인증 확인 등 시작 또는 초기화 중에 한두 개의 느린 쿼리를 실행하는 경우가 있습니다.쿼리를 최적화하면 성능이 향상될 수 있습니다.때로는 코드가 php 프리펜드 또는 spl autoload를 사용하여 실행되어 모든 것에서 실행됩니다.또한 잘못된 설정이 Apache conf 및 조정으로 인해 문제가 발생할 수 있습니다.

비효율적인 루프를 찾습니다.캐시 호출이 느리거나 디스크 드라이브 장애 또는 디스크 공간 사용률 증가로 인해 I/O 작업이 느릴 수 있습니다.메모리의 사용법, 사용처, 사용처 등을 확인합니다.동일한 위치가 아닌 전 세계 다른 위치에서 첫 번째 보기만 사용하여 단일 이미지 또는 파일에 대해 10회 실행의 웹 페이지 테스트를 반복합니다.액세스 로그와 에러 로그를 읽어 주세요.너무 많은 개발자가 이를 무시하고 화면에 표시되는 에러에만 의존합니다.웹 호스트가 지원을 받고 있다면 도움을 요청하십시오. 그래도 정중하게 도움을 요청하지 않으면 해가 되지 않습니다.

DNS 프리페치를 사용하여 많은 도메인과 리소스에 대응할 수 있습니다.http://html5boilerplate.com/docs/DNS-Prefetching/

고객님의 서버는 우수한/델트 서버입니까?때때로 더 나은 서버가 많은 문제를 해결할 수 있습니다.저는 '하드웨어는 싸고 프로그래머는 비싸다'는 사고방식의 팬입니다. 기회가 된다면, 그리고 돈을 들여 서버를 업그레이드 할 수 있습니다.또는 maxcdn이나 cloudflare와 같은 CDN을 사용합니다.

행운을 빕니다.

(p.s. 저는 어느 회사에서도 일하지 않습니다.또한 위의 Cloudflare 링크는 TTFB가 그다지 중요하지 않다고 주장할 것입니다.또 다른 정보를 얻을 수 있도록 TTFB를 삽입한 것입니다.)

미안하지만, 당신은 데이터를 거의 제공하지 않습니다.그리고 당신은 이미 몇 가지 좋은 제안을 했습니다.

이 이미지들을 어떻게 제공하고 있습니까?PHP를 통해 스트리밍을 하고 있다면 이미 생성되었다고 해도 매우 나쁜 짓을 하고 있는 것입니다.

PHP를 사용하여 이미지를 스트리밍하지 마십시오.사용 방법에 관계없이 서버 속도가 느려집니다.

Put them in a accessible folder, with a meaningful URI. Then call them directly with their real URI. If you need on the fly generation you should put an .htaccess in the images directory which redirects to a generator php-script only if the request image is missing. (this is called cache-on-request strategy).

Doing that will fix php session, browser-proxy, caching, ETAGS, whatever all at once.

WP-Supercache uses this strategy, if properly configured.

I wrote this some time ago ( http://code.google.com/p/cache-on-request/source/detail?r=8 ), last revisions are broken, but I guess 8 or less should work and you can grab the .htaccess as an example just to test things out (although there are better ways to configure the .htaccess than the way I used to).

I described that strategy in this blog post ( http://www.stefanoforenza.com/need-for-cache/ ). It is probably badly written but it may help clarifying things up.

Further reading: http://meta.wikimedia.org/wiki/404_handler_caching

ReferenceURL : https://stackoverflow.com/questions/4810806/cached-php-generated-thumbnails-load-slowly