속도와 확장 성을 위해 Kohana 기반 웹 사이트 최적화

Question 1

Kohana로 구축 한 사이트는 어제 엄청난 양의 트래픽으로 인해 피해를 입어 한 걸음 물러서서 디자인의 일부를 평가하게되었습니다. Kohana 기반 응용 프로그램을 최적화하기위한 몇 가지 표준 기술이 궁금합니다.

벤치마킹에도 관심이 있습니다. 나는 설정해야합니까 Benchmark::start()하고 Benchmark::stop()모든 페이지에 실행 시간을보기 위해 각각의 컨트롤러 방법에 대한, 또는 I는 전 세계적으로 빠르게 벤치마킹 적용 할 수 있어요?

앞으로 캐시 라이브러리를 더 많이 사용할 예정이지만, 지금은 알지 못하지만 할 수있는 일이 많이있을 것이므로 더 많은 제안을 기다리고 있습니다.

Question 2

이 답변에서 내가 말할 것은 Kohana에만 국한되지 않으며 아마도 많은 PHP 프로젝트에 적용될 수 있습니다.

성능, 확장 성, PHP 등에 대해 이야기 할 때 떠오르는 몇 가지 요점은 다음과 같습니다
. 여러 프로젝트에서 작업하는 동안 이러한 아이디어를 많이 사용했으며 도움이되었습니다. 여기에서도 도움이 될 수 있습니다.

우선 공연과 관련하여 고려해야 할 많은 측면 / 질문이 있습니다 .

서버 구성 (Apache, PHP, MySQL, 기타 가능한 데몬 및 시스템 모두) ; ServerFault 에서 더 많은 도움을받을 수 있습니다 .
PHP 코드,
데이터베이스 쿼리,
웹 서버를 사용 하시나요?
어떤 종류의 캐싱 메커니즘을 사용할 수 있습니까? 아니면 웹 사이트에 항상 더 많은 최신 데이터가 필요합니까?

역방향 프록시 사용

사용하고 정말 유용 할 수있는 우선 역방향 프록시를 같은 광택 웹 서버의 앞은 : 그것은 수 있도록 가능한 한 많은 것들로 캐시 , 정말 PHP / MySQL의 계산이 필요하므로 요청 만 물론, (그리고 일부 다른 요청이 프록시의 캐시에없는 경우) Apache / PHP / MySQL로 보냅니다.

우선, CSS / Javascript / Images-음 , 정적 인 모든 것 - 아마도 Apache에서 항상 제공 할 필요는 없습니다.
- 따라서 역방향 프록시가 모든 것을 캐시하도록 할 수 있습니다.
- 이러한 정적 파일을 제공하는 것은 Apache에게는 큰 문제가 아니지만, 이러한 파일을 위해 작동해야하는 작업이 적을수록 PHP로 더 많은 작업을 수행 할 수 있습니다.
- 기억하세요 : Apache는 한 번에 제한적이고 제한된 수의 요청 만 처리 할 수 있습니다.
그런 다음 역방향 프록시가 캐시에서 가능한 한 많은 PHP 페이지를 제공하도록합니다. 자주 변경되지 않고 캐시에서 제공 될 수있는 페이지 가있을 수 있습니다. PHP 기반 캐시를 사용하는 대신 다른 더 가벼운 서버가 이러한 캐시를 제공하도록하는 것은 어떨까요 (그리고 때때로 PHP 서버에서 가져 와서 항상 최신 상태로 유지합니다) ?
- 예를 들어, 매우 자주 요청 되는 RSS 피드 (일반적으로 성능 최적화를 시도 할 때 잊어 버리는 경향이 있음) 가있는 경우 이를 캐시에 몇 분 동안두면 Apache + PHP에 대한 수백 / 수천 건의 요청을 줄일 수 있습니다. + MySQL!
- 사이트에서 가장 많이 방문한 페이지에 대해 동일합니다. 최소 몇 분 동안 변경되지 않으면 (예 : 홈페이지?) 사용자가 요청할 때마다 CPU를 다시 생성하는 데 낭비 할 필요가 없습니다.
익명 사용자에게 제공되는 페이지 (모든 익명 사용자에게 동일한 페이지) 와 식별 된 사용자에게 제공되는 페이지 (예 : "Hello Mr X, you have new messages" ) 간에 차이가있을 수 있습니다 .
- 그렇다면 아마도 익명 사용자에게 제공되는 페이지를 캐시하도록 역방향 프록시를 구성 할 수 있습니다 (일반적으로 세션 쿠키와 같은 쿠키 기반).
- 이는 Apache + PHP가 처리 할 것이 적다는 것을 의미합니다. 식별 된 사용자 만-사용자의 일부일 수 있습니다.

정보 캐시로 리버스 프록시를 사용 에서 PHP 응용 프로그램, 당신은, 예를 들어, 좀 걸릴 수 있습니다 벤치 마크 결과는 400 % -700 APC와 오징어 캐시와 서버 기능에서 %의 증가를 보여 .
(그래, 그들은 Squid를 사용하고 있고 나는 바니시에 대해 이야기하고 있었는데-그것은 또 다른 가능성입니다 ^^ 바니시는 더 최근이지만 캐싱에 더 헌신적입니다)

충분히 잘하고 너무 많은 페이지를 반복해서 다시 생성하는 것을 중단하면 코드를 최적화 할 필요조차 없을 것입니다 ;-)
적어도 서두르지는 않을 것입니다. 그리고 너무 많은 압박을받지 않을 때 최적화를 수행하는 것이 항상 좋습니다.

참고로 OP에서 다음과 같이 말합니다.

내가 Kohana로 만든 사이트는 어제 엄청난 양의 트래픽으로 인해 충돌했습니다.

이것은의 종류 갑작스러운 상황에 어디 리버스 프록시 할 수있는 말 그대로 하루 저장 , 당신의 웹 사이트가 두 번째로 최신없는 해결할 수있는 경우 :

그것을 설치하고, 구성하고, 항상 -매일 매일- 실행하십시오.
- PHP 페이지를 캐시에 보관하지 않도록 구성하십시오. 또는 짧은 기간 동안 만; 이렇게하면 항상 최신 데이터가 표시됩니다.
그리고 slashdot 또는 digg 효과를 취하는 날 :
- PHP 페이지를 캐시에 유지하도록 역방향 프록시를 구성하십시오. 또는 더 오랜 기간 동안; 아마도 귀하의 페이지는 초까지 최신 상태가 아닐 수 있지만 웹 사이트가 굴착 효과에서 살아남을 수 있습니다!

그것에 대해 어떻게 "Slashdotted"를 감지하고 생존 할 수 있습니까? 흥미로운 읽을 수 있습니다.

PHP 측면에서 :

우선 : 최신 버전의 PHP 를 사용하고 있습니까? 새 버전으로 속도가 정기적으로 향상됩니다 ;-)
예를 들어, Benchmark of PHP Branches 3.0 ~ 5.3-CVS를 살펴보십시오 .

공연은 꽤 좋은 이유는 PHP 5.3을 사용하는 것을 주 ( I ()는 프랑스어로 일부 벤치 마크를했습니다 , 결과는 중대하다) ...
PHP 5.2의 수명이 다했음을 물론, 또 다른 꽤 좋은 이유 존재를 , 그리고 더 이상 유지되지 않습니다!

opcode 캐시를 사용하고 있습니까?

예를 들어 ( pecl , manual ) APC-Alternative PHP Cache 에 대해 생각하고 있는데, 내가 가장 많이 사용한 솔루션이며 내가 작업 한 모든 서버에서 사용됩니다.
- 참조 : Slides APC Facebook ,
- 또는 벤치 마크 결과 APC 및 Squid Cache를 통해 서버 기능이 400 % -700 % 증가한 것으로 나타났습니다 .
어떤 경우에는 서버의 CPU 부하를 상당히 낮출 수 있습니다 (APC를 설치하고 opcode-cache 기능을 활성화하는 것만으로도 일부 서버의 CPU 부하가 80 %에서 40 %로 증가하는 것을 보았습니다!).
기본적으로 PHP 스크립트 실행은 두 단계로 진행됩니다.
- PHP 소스 코드를 opcode로 컴파일 (JAVA의 바이트 코드와 동일)
- 해당 opcode 실행
- APC는이를 메모리에 보관하므로 PHP 스크립트 / 파일이 실행될 때마다 수행해야 할 작업이 적습니다. RAM에서 opcode 만 가져 와서 실행합니다.
그런데 APC의 구성 옵션을 살펴 봐야 할 수도 있습니다.
- 그 중 상당수는 속도 / CPU 부하 / 사용 편의성에 큰 영향을 미칠 수 있습니다.
- 예를 들어, 비활성화 [apc.stat](https://php.net/manual/en/apc.configuration.php#ini.apc.stat)는 시스템 부하에 좋을 수 있습니다. 그러나 이것은 전체 opcode-cache를 플러시하지 않는 한 PHP 파일에 대한 수정이 고려되지 않음을 의미합니다. 자세한 내용은 예 를 들어 To stat () 또는 Not To stat ()?

데이터에 캐시 사용

가능한 한 같은 일을 반복 해서 하지 않는 것이 좋습니다 .

제가 생각하는 주요 사항은 물론 SQL 쿼리입니다. 많은 페이지에서 동일한 쿼리를 수행 할 수 있으며 일부 결과는 거의 항상 동일합니다. 즉, "쓸모없는" 쿼리가 많이 있음을 의미 합니다. 동일한 데이터를 반복해서 제공하는 데 시간을 소비해야합니다.
물론 이것은 웹 서비스 호출, 다른 웹 사이트에서 정보 가져 오기, 무거운 계산 등과 같은 다른 작업에도 해당됩니다.

다음을 식별하는 것이 매우 흥미로울 수 있습니다.

여러 번 실행되는 쿼리는 항상 동일한 데이터를 반환합니다.
항상 동일한 결과를 반환하는 다른 (무거운) 계산이 많은 시간에 수행됨

그리고 이러한 데이터 / 결과를 어떤 종류의 캐시에 저장하면 더 쉽게 얻을 수 있고 더 빨리 얻을 수 있으며 "아무것도"하지 않으려 고 SQL 서버로 이동할 필요가 없습니다.

예를 들어 훌륭한 캐싱 메커니즘은 다음과 같습니다.

APC : 앞서 언급 한 opcode-cache 외에도 메모리에 데이터를 저장할 수 있습니다.
그리고 / 또는 memcached ( 참조 ) , 말 그대로 많은 양 의 데이터가 있거나 분산되어있는 여러 서버를 사용하는 경우 매우 유용합니다 .
물론 파일에 대해 생각할 수 있습니다. 그리고 아마도 다른 많은 아이디어.

나는 당신의 프레임 워크가 캐시와 관련된 것들을 제공한다고 확신합니다. OP에서 "나는 캐시 라이브러리를 더 많이 사용할 것" 이라고 말했듯이 이미 알고있을 것입니다 ;-)

프로파일 링

이제 할 수있는 좋은 일은 Xdebug 확장 을 사용 하여 응용 프로그램 을 프로파일 링하는 것입니다 . 적어도 시간이 많이 걸리는 함수가 있다면 몇 가지 약점을 아주 쉽게 찾을 수 있습니다.

올바르게 구성 되면 다음과 같은 일부 그래픽 도구로 분석 할 수있는 프로파일 링 파일이 생성됩니다.

KCachegrind : 내가 가장 좋아하지만 Linux / KDE에서만 작동합니다.
Windows 용 Wincachegrind ; 불행히도 KCacheGrind보다 약간 적은 작업을 수행합니다. 일반적으로 콜 그래프를 표시하지 않습니다.
PHP 웹 서버에서 실행되는 Webgrind 는 어디서나 작동하지만 기능이 적을 것입니다.

예를 들어, 다음은 KCacheGrind의 몇 가지 스크린 샷입니다.

_{(출처 : pascal-martin.fr )}_{(출처 :}_{pascal-martin.fr}₎

(BTW, 두 번째 스크린 샷에 표시된 callgraph는 일반적으로 올바르게 기억하면 WinCacheGrind도 Webgrind도 할 수없는 일입니다 ^^)

(댓글에 대해 @Mikushi에게 감사드립니다) 제가 많이 사용하지 않은 또 다른 가능성은 xhprof 확장입니다. 프로파일 링에도 도움이되고 콜 그래프를 생성 할 수 있지만 Xdebug보다 가볍기 때문에 설치할 수 있어야합니다. 프로덕션 서버.

데이터 시각화에 도움이되는 XHGui 와 함께 사용할 수 있어야합니다 .

SQL 측면에서 :

이제 PHP에 대해 조금 이야기 했으므로 병목 현상이 PHP 측이 아니라 데이터베이스 문제 일 가능성 이 더 크다는 점에 유의하십시오 .

여기에서 적어도 두세 가지 :

다음을 결정해야합니다.
- 애플리케이션이 수행하는 가장 빈번한 쿼리는 무엇입니까?
- MySQL을 사용하는 경우 지침을 사용 하여 최적화되었는지 여부 ( 주로 올바른 인덱스 사용 ?)EXPLAIN
  - 참고 항목 : SELECT 및 기타 문 최적화
  - 예를 들어 활성화 log_slow_queries하여 "너무 많은" 시간 이 걸리는 요청 목록을 가져 와서 최적화를 시작할 수 있습니다.
- 이러한 쿼리 중 일부를 캐시 할 수 있는지 여부 (앞서 언급 한 내용 참조)
MySQL이 잘 구성되어 있습니까? 그것에 대해 잘 모르지만 약간의 영향을 미칠 수있는 몇 가지 구성 옵션이 있습니다.
- MySQL 서버를 최적화 하면 이에 대한 흥미로운 정보를 얻을 수 있습니다.

그래도 가장 중요한 두 가지는 다음과 같습니다.

할 필요가 없다면 DB로 가지 마십시오. 가능한 한 많이 캐시하십시오 !
DB로 가야 할 때 효율적인 쿼리를 사용하십시오. 인덱스를 사용하십시오. 및 프로필!

그리고 지금은?

아직 읽고 있다면 무엇을 최적화 할 수 있습니까?

글쎄요, 여전히 개선의 여지가 있습니다 ... 몇 가지 아키텍처 지향 아이디어는 다음과 같습니다.

n 계층 아키텍처로 전환합니다.
- MySQL을 다른 서버에 배치 (2 계층 : 하나는 PHP 용, 다른 하나는 MySQL 용)
- 여러 PHP 서버 사용 (그리고 이들 서버 간에 사용자 부하 분산)
- 다음과 같이 더 가벼운 웹 서버와 함께 정적 파일에 다른 시스템을 사용하십시오.
  - lighttpd
  - 또는 nginx- 이것은 점점 더 인기를 얻고 있습니다, btw.
- MySQL 용 여러 서버, PHP 용 여러 서버, 그 앞에 여러 개의 역방향 프록시를 사용합니다.
- 물론 : 여유 RAM이있는 서버에 memcached 데몬을 설치 하고 가능한 한 많이 캐시하는 데 사용하십시오.
Apache보다 "더 효율적인"것을 사용 하시겠습니까?
- nginx 에 대해 점점 더 자주 듣 습니다. PHP와 대용량 웹 사이트에 있어서는 좋을 것 같습니다. 나는 그것을 직접 사용한 적이 없지만 인터넷에서 흥미로운 기사를 찾을 수 있습니다.
  - 예를 들어, PHP 성능 III-nginx 실행 .
  - 참조 : PHP-FPM-FastCGI Process Manager , PHP> = 5.3.3과 함께 번들로 제공되며 nginx에서 놀라운 기능을 수행합니다.

글쎄, 그런 아이디어 중 일부는 당신의 상황에서 약간 과장된 것일 수 있습니다 ^^
하지만 그래도 ... ;-)

그리고 Kohana는 어떻습니까?

귀하의 초기 질문은 Kohana를 사용하는 응용 프로그램을 최적화하는 것이 었습니다 ... 글쎄요, 모든 PHP 응용 프로그램에 대해 사실 인 아이디어를 게시했습니다 ... 즉, Kohana에도 사실임을 의미합니다 ;-)
(특정하지 않더라도 ^^)

나는 말했다 : 캐시 사용; Kohana는 일부 캐싱 작업 을 지원하는 것 같습니다 (자신이 그것에 대해 이야기 했으므로 여기
에는 새로운 것이 없습니다 ...) 신속하게 수행 할 수있는 작업이 있으면 시도해보십시오 ;-)

나는 또한 당신이 필요하지 않은 것은하지 말아야한다고 말했습니다. Kohana에서 필요하지 않은 것이 기본적으로 활성화되어 있습니까?
인터넷을 살펴보면 적어도 XSS 필터링에 대해 뭔가가있는 것 같습니다. 그게 필요합니까?

그래도 유용 할 수있는 몇 가지 링크가 있습니다.

결론?

그리고 결론적으로, 간단한 생각 :

회사에서 5 일 동안 지불하는 데 드는 비용은 얼마입니까? -훌륭한 최적화를 수행하는 데 합리적인 시간이라는 점을 고려
회사에서 두 번째 서버 를 구입 (비용을 지불합니까?) 하고 유지 관리 하는 데 얼마나 많은 비용이 듭 니까?
더 크게 확장해야하는 경우 어떻게해야합니까?
- 10 일을 보내는 데 드는 비용은 얼마입니까? 더? 가능한 모든 애플리케이션을 최적화하고 있습니까?
- 그리고 몇 대의 서버를 추가하려면 얼마입니까?

최적화하지 말아야한다고 말하는 것이 아닙니다. 확실히해야합니다!
그러나 먼저 큰 보상을 얻을 수있는 "빠른"최적화를 선택하십시오 . 일부 opcode 캐시를 사용하면 서버의 CPU 부하를 10 ~ 50 % 줄이는 데 도움이 될 수 있습니다. 설정하는 데 몇 분 밖에 걸리지 않습니다. ) 반면에, 2 %에 3 일을 보냅니다 ...

아, 그리고 btw : 무엇이든하기 전에 : 모니터링 항목을 제자리에 두십시오 . 그러면 어떤 개선이 이루어 졌는지, 어떻게 개선되었는지 알 수 있습니다!
모니터링하지 않으면 수행 한 작업의 효과를 전혀 알 수 없습니다. 실제 최적화 여부에 관계없이!

예를 들어 RRDtool + cacti 와 같은 것을 사용할 수 있습니다 .
그리고 상사에게 CPU 부하가 40 % 감소한 멋진 그래픽을 보여주는 것은 항상 좋습니다 ;-)

어쨌든, 정말로 결론을 내릴 수 있습니다.
(예, 최적화하는 것은 재미 있습니다!)
(어, 저는 그렇게 많이 쓸 줄은 몰랐습니다. 적어도 이것의 일부가 유용하길 바랍니다 ... 그리고 저는이 대답을 기억해야합니다 : 다른 때에 유용 할 수도 있습니다. ..)

Question 3

XDebug 및 WinCacheGrind 또는 WebCacheGrind 를 사용 하여 느린 코드 실행을 프로파일 링하고 분석합니다.

_{(출처 : jokke.dk )}
WinCacheGrind

Question 4

XDebug를 사용한 프로필 코드 .

많은 캐싱을 사용하십시오. 페이지가 상대적으로 정적 인 경우 역방향 프록시가 가장 좋은 방법 일 수 있습니다.

Question 5

Kohana는 데이터베이스 개체를 사용하는 것을 제외하고는 매우 빠릅니다. Zombor를 인용하려면 "결과 배열 대신 데이터베이스 결과 객체를 사용하여 메모리 사용량을 줄일 수 있습니다." 이것은 슬래 밍되는 사이트에서 HUGEE 성능 차이를 만듭니다. 더 많은 메모리를 사용할뿐만 아니라 스크립트 실행 속도가 느려집니다.

또한-캐싱을 사용해야합니다. 나는 memcache를 선호하고 다음과 같이 내 모델에서 사용합니다.

public function get($e_id)
{
    $event_data = $this->cache->get('event_get_'.$e_id.Kohana::config('config.site_domain'));

    if ($event_data === NULL)
    {
        $this->db_slave
            ->select('e_id,e_name')
            ->from('Events')
            ->where('e_id', $e_id);

        $result = $this->db_slave->get();
        $event_data = ($result->count() ==1)? $result->current() : FALSE;

        $this->cache->set('event_get_'.$e_id.Kohana::config('config.site_domain'), $event_data, NULL, 300); // 5 minutes
    }

    return $event_data;
}

또한 성능이 크게 향상됩니다. 위의 두 기술은 사이트 성능을 80 % 향상 시켰습니다.

병목 현상이 발생했다고 생각하는 위치에 대해 더 많은 정보를 제공했다면 더 나은 아이디어를 제공 할 수있을 것입니다.

다른 성능 팁을 보려면 yslow (google it)를 확인하십시오.

Question 6

Kohana와 엄격하게 관련이 있습니다 (이미이 작업을 수행했는지 여부) :

프로덕션 모드에서 :

내부 캐싱을 활성화합니다 (Kohana :: find_file 결과 만 캐시하지만 실제로는 많은 도움이 될 수 있습니다.
프로파일 러 비활성화

내 2 센트 :)

Question 7

나는 XDebug 및 캐싱 답변에 전적으로 동의합니다. 최대 속도 및 규모 병목 현상을 식별 할 때까지 최적화를 위해 Kohana 계층을 조사하지 마십시오.

XDebug는 사용자가 대부분의 시간을 소비했는지 알려주고 코드에서 '핫스팟'을 식별합니다. 성능 향상을 기준으로하고 측정 할 수 있도록이 프로파일 링 정보를 보관하십시오.

예제 문제 및 솔루션 : 매번 데이터베이스에서 값 비싼 객체를 구축하고 있지만 실제로 자주 변경되지 않는 경우 memcached 또는 다른 메커니즘을 사용하여 캐시하는 방법을 살펴볼 수 있습니다. 이러한 모든 성능 수정은 시간이 걸리고 시스템에 복잡성을 추가하므로 수정을 시작하기 전에 병목 현상을 확인하십시오.