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

https://stackoverflow.com/questions/1260134

12-09-2019
|

문제

내가 Kohana와 함께 지은 사이트는 어제 엄청난 양의 트래픽으로 부딪쳐서 한 걸음 물러서서 디자인의 일부를 평가할 수있었습니다. Kohana 기반 애플리케이션을 최적화하기위한 몇 가지 표준 기술은 무엇입니까?

벤치마킹에도 관심이 있습니다. 설정해야합니까? Benchmark::start() 그리고 Benchmark::stop() 모든 페이지의 실행 시간을 보려면 각 컨트롤러 방법에 대해 전 세계적으로 빠르게 벤치마킹을 적용 할 수 있습니까?

나는 앞으로 시간에 캐시-라이브러리를 더 많이 사용할 것이지만, 나는 지금은 단순히 잘 모르기 위해 할 수있는 일이 많이 있다고 확신하기 때문에 더 많은 제안에 열려 있습니다.

해결책

이 답변에서 내가 말할 것은 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, 새 메시지가 있습니다", 예를 들어)?
- 그렇다면 익명 사용자를 위해 제공되는 페이지를 캐시하기 위해 리버스 프록시를 구성 할 수 있습니다. (세션 쿠키와 같은 쿠키를 기반으로합니다.
- 이는 Apache+PHP가 다루기가 적다는 것을 의미합니다. 식별 된 사용자 만 사용자의 작은 부분 일 수 있습니다.

에 대한 캐시로 리버스 프록시를 사용합니다, PHP 응용 프로그램의 경우 예를 들어, 벤치 마크 결과는 APC 및 오징어 캐시를 사용하여 서버 기능이 400% -700% 증가한 것으로 나타났습니다..
(그렇습니다. 그들은 오징어를 사용하고 있으며 바니시에 대해 이야기하고있었습니다. 그것은 또 다른 가능성 일뿐입니다 ^^ 바니시는 더 최근이지만 캐싱에 더 전념합니다)

당신이 그렇게 충분히 잘하고 너무 많은 페이지를 다시 생성하는 중지를 계속하면, 당신은 당신의 코드를 최적화 할 필요조차 없을 것입니다 ;-)
적어도, 어쩌면 어떤 종류의 서두르지 않을 수도 있습니다 ... 그리고 당신이 너무 많이 추정하지 않을 때 항상 최적화를 수행하는 것이 좋습니다 ...

사이드 노트로 : 당신은 OP에서 말하고 있습니다 :

내가 Kohana와 함께 지은 사이트는 어제 엄청난 양의 트래픽으로 부딪쳤다.

이것은 일종의 것입니다 역 프로시서가 말 그대로 하루를 구할 수있는 갑작스런 상황, 귀하의 웹 사이트가 두 번째로 최신 상태가되지 않는 경우 :

설치하고 구성하고 항상 놔두십시오 -평범한 날- 운영:
- 캐시에 PHP 페이지를 유지하지 않도록 구성하십시오. 또는 짧은 기간 동안 만; 이렇게하면 항상 최신 데이터가 표시됩니다.
그리고 당신이 슬래시 도트 또는 발굴 효과를 섭취하는 날 :
- 캐시에 PHP 페이지를 유지하도록 리버스 프록시를 구성하십시오. 또는 더 오랜 시간 동안; 어쩌면 귀하의 페이지가 두 번째로 최신 상태가되지는 않지만 웹 사이트가 Digg-Effect에서 살아남을 수 있습니다!

그것에 대해, “슬래시 팅”되는 것을 어떻게 감지하고 살아남을 수 있습니까? 흥미로운 독서 일 수 있습니다.

사물의 PHP 측면에서 :

우선 : 당신은 a를 사용하고 있습니까? PHP의 최근 버전? 새로운 버전으로 정기적으로 속도가 향상됩니다 ;-)
예를 들어, 살펴보십시오 PHP 브랜치 3.0에서 5.3-cvs의 벤치 마크.

공연은 PHP 5.3을 사용해야하는 좋은 이유입니다. (벤치 마크를 만들었습니다 (프랑스어), 그리고 결과는 훌륭합니다)...
물론 PHP 5.2가 삶의 끝에 도달했으며 더 이상 유지되지 않는 또 다른 좋은 이유입니다!

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

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

데이터 용 캐시 사용

가능한 한 더 낫습니다 똑같은 일을 반복해서하지 마십시오.

내가 생각하는 가장 중요한 것은 물론 SQL 쿼리입니다. 많은 페이지의 많은 페이지가 아마 같은 쿼리를 할 것입니다. 그 중 일부의 결과는 거의 항상 동일합니다 ... 이것은 많은 것을 의미합니다. "쓸모없는" 데이터베이스에 대한 쿼리는 동일한 데이터를 반복해서 제공하는 데 시간을 소비해야합니다.
물론 이것은 웹 서비스 호출, 다른 웹 사이트의 정보 가져 오기, 무거운 계산 등 다른 것들에 해당됩니다.

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

어떤 쿼리가 많이 실행되는지 항상 동일한 데이터를 반환합니다.
기타 (무거운) 계산은 많은 시간이 완료되었으며 항상 같은 결과를 반환합니다.

이 데이터/결과를 일종의 캐시에 저장하므로 쉽게 얻을 수 있습니다. 더 빠르게 - 그리고 "아무것도 없음"을 위해 SQL 서버로 이동할 필요가 없습니다.

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

APC: 이전에 이야기 한 Opcode-Cache 외에도 메모리에 데이터를 저장할 수 있습니다.
및/또는 memcached (또한보십시오), 말 그대로 가지고 있다면 매우 유용합니다 많이 데이터 및/또는 여러 서버 사용, 분포되어 있습니다.
물론 파일에 대해 생각할 수 있습니다. 그리고 아마도 다른 많은 아이디어 일 것입니다.

나는 당신의 프레임 워크에 캐시 관련 물건이 포함되어 있다고 확신합니다. 당신은 아마도 당신이 말했듯이 이미 알고있을 것입니다 "나는 앞으로도 캐시-라이브러리를 더 많이 사용할 것이다" OP에서 ;-)

프로파일 링

이제 좋은 일은 xdebug 연장 응용 프로그램을 프로필하십시오: 그것은 종종 두 개의 약한 스포트를 아주 쉽게 찾을 수 있습니다. 적어도 많은 시간이 걸리는 기능이 있다면.

제대로 구성되었습니다, 그것은 다음과 같은 일부 그래픽 도구로 분석 할 수있는 프로파일 링 파일을 생성합니다.

Kcachegrind: 내가 가장 좋아하지만 Linux/KDE에서만 작동합니다.
윈클 린드 Windows의 경우; 불행히도 kcachegrind보다 약간 덜한 것입니다. 일반적으로 콜 그래프를 표시하지 않습니다.
WebGrind PHP 웹 서버에서 실행되므로 어디에서나 작동하지만 기능이 적을 수 있습니다.

예를 들어, Kcachegrind의 스크린 샷은 다음과 같습니다.

_{(원천: Pascal-Martin.fr)}

_{(원천: Pascal-Martin.fr)}

(BTW, 두 번째 스크린 샷에 제시된 콜 그라프는 일반적으로 윈클 린드 나 웹 그라인드가 할 수없는 일입니다. ^^)

(주석에 감사드립니다) 내가 많이 사용하지 않은 또 다른 가능성은 xhprof 확장 : 프로파일 링에 도움이되고 콜 그라프를 생성 할 수 있지만 XDEBUG보다 가볍습니다. 즉, 프로덕션 서버에 설치할 수 있어야합니다.

당신은 그것을 Alonside를 사용할 수 있어야합니다 XHGUI, 데이터의 시각화에 도움이됩니다.

사물의 SQL 측면에서 :

이제 우리는 PHP에 대해 조금 이야기 했으므로 병목 현상이 PHP 측의 사물이 아닐 가능성이 높습니다., 그러나 데이터베이스 하나 ...

여기에서 최소한 두세 가지 :

당신은 결정해야합니다 :
- 응용 프로그램이 수행하는 가장 빈번한 쿼리는 무엇입니까?
- 그것들이 최적화되었는지 여부 (사용 사용 올바른 색인, 주로?), 사용 EXPLAIN MySQL을 사용하는 경우 지시 사항
  - 또한보십시오: 선택 및 기타 진술을 최적화합니다
  - 예를 들어 활성화 할 수 있습니다 log_slow_queries 취하는 요청 목록을 얻으려면 "너무 많이" 시간을 보내고 최적화를 시작하십시오.
- 이 쿼리 중 일부를 캐시 할 수 있는지 여부 (앞에서 말한 내용보기)
MySQL이 잘 구성되어 있습니까? 나는 그것에 대해 많이 모르지만, 약간의 영향을 줄 수있는 구성 옵션이 있습니다.
- MySQL 서버 최적화 그것에 대한 흥미로운 정보를 줄 수 있습니다.

그럼에도 불구하고 가장 중요한 두 가지는 다음과 같습니다.

필요하지 않은 경우 DB에 가지 마십시오. 가능한 한 많이 캐시하십시오!
DB로 이동 해야하는 경우 효율적인 쿼리를 사용하십시오 : 색인 사용; 그리고 프로필!

그리고 지금 뭐야?

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

글쎄, 여전히 개선의 여지가 있습니다 ... 몇 가지 건축 지향적 아이디어는 다음과 같습니다.

N-Tier 아키텍처로 전환하십시오.
- MySQL을 다른 서버에 넣으십시오 (2 계층 : 하나는 PHP를위한 것; 다른 하나는 mySQL의 경우)
- 여러 PHP 서버를 사용하십시오 (그리고 그 사이의 사용자를로드 균형
- 더 가벼운 웹 서버와 함께 정적 파일에 다른 시스템을 사용하십시오.
  - lighttpd
  - 또는 nginx - 이것은 점점 더 인기를 얻고 있습니다. BTW.
- MySQL 용 여러 서버, PHP 용 여러 서버 및 그 앞에있는 몇 가지 역 프로시서를 사용하십시오.
- 물론 : 설치 memcached 서버의 데몬에는 모든 양의 무료 RAM이있는 데몬을 사용하여 최대한 많이 캐시하는 데 사용합니다.
아파치를 더 효율적으로 사용합니까?
- 나는 점점 더 자주 들린다 nginx, PHP 및 대량 웹 사이트와 관련하여 훌륭 할 것입니다. 나는 그것을 직접 사용한 적이 없지만 그물에서 그것에 관한 흥미로운 기사를 찾을 수 있습니다.
  - 예를 들어, PHP 성능 III- 실행 Nginx.
  - 또한보십시오: PHP -FPM -FASTCGI 프로세스 관리자, PHP> = 5.3.3으로 번들로 번들로, Nginx로 놀라운 일을합니다.

글쎄, 아마도 그 아이디어 중 일부는 당신의 상황에서 약간 과잉 일 것입니다 ^^
그러나 여전히 ... 만일을 대비하여 조금 연구하지 않겠습니까? ;-)

그리고 Kohana는 어떻습니까?

당신의 초기 질문은 Kohana를 사용하는 응용 프로그램을 최적화하는 것입니다 ... 글쎄, 나는 일부 게시했습니다. 모든 PHP 응용 프로그램에 맞는 아이디어... 이것은 그들이 코나에게도 사실이라는 것을 의미합니다 ;-)
(그것에 대해 구체적이지 않더라도 ^^)

나는 말했다 : 캐시 사용; 코나는 일부를 지원하는 것 같습니다 캐싱 물건 (당신은 그것에 대해 스스로 이야기 했으므로 여기에 새로운 것은 없습니다 ...)
빨리 할 수있는 일이 있다면 시도해보십시오 ;-)

또한 필요하지 않은 일을해서는 안된다고 말했습니다. Kohana에서 기본적으로 필요하지 않은 것이 있습니까?
그물을 탐색하면 XSS 필터링에 대해서는 적어도 무언가가있는 것 같습니다. 필요합니까?

그럼에도 불구하고 유용한 몇 가지 링크가 있습니다.

결론?

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

회사가 5 일을 지불하는 데 드는 비용은 얼마입니까? - 훌륭한 최적화를 수행하는 데 합리적인 시간이라는 점을 고려하십시오.
회사를 구매하는 데 드는 비용은 얼마입니까? (지불?) 두 번째 서버 및 유지 보수?
더 크게 확장해야한다면 어떨까요?
- 10 일을 소비하는 데 드는 비용은 얼마입니까? 더? 가능한 모든 응용 프로그램을 최적화 하시겠습니까?
- 그리고 몇 개의 서버가 더 얼마나됩니까?

나는 당신이 최적화해서는 안된다고 말하는 것이 아닙니다 : 당신은 확실히해야합니다!
하지만 큰 보상을받을 "빠른"최적화로 이동하십시오. 첫째 : 일부 opcode 캐시를 사용하면 서버의 CPU로드가 10 ~ 50 %를 얻는 데 도움이 될 수 있습니다. 설정하는 데 몇 분 밖에 걸리지 않습니다. ..

아, 그리고 btw : 무엇이든하기 전에 : 모니터링 물건을 제자리에 두십시오, 그래서 당신은 어떤 개선이 이루어 졌는지, 어떻게!
모니터링하지 않으면, 당신은 당신이 한 일의 효과에 대해 전혀 알지 못할 것입니다 ... 그것이 진정한 최적화인지 아닌지에도 불구하고!

예를 들어, 당신은 같은 것을 사용할 수 있습니다 rrdtool + 선인장.
그리고 당신의 상사에게 40% CPU로드 드롭으로 멋진 그래픽을 보여줍니다.

어쨌든, 실제로 결론을 내립니다. 재미있게 보내세요!
(예, 최적화는 재미 있습니다!)
(Ergh, 나는 그렇게 많이 쓸 것이라고 생각하지 않았다 ... 적어도 일부 부분이 유용하기를 바랍니다 ... 그리고 나는이 대답을 기억해야합니다 : 다른 시간에 유용 할 수도 있습니다 ...)

다른 팁

사용 xdebug 그리고 윈클 린드 또는 WebCachegrind 느린 코드 실행을 프로파일하고 분석합니다.

_{(원천: jokke.dk)}
WinCacheGrind

프로필 코드 xdebug.

많은 캐싱을 사용하십시오. 페이지가 비교적 정적 인 경우 리버스 프록시가 가장 좋은 방법 일 수 있습니다.

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

또한 - 캐싱을 사용해야합니다. 나는 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)를 확인하십시오.

Kohana와 엄격하게 관련되어 있습니다 (아마도 이미 이것을 해왔 든 아니든) :

생산 모드에서 :

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

내 2 센트 만 :)

나는 Xdebug 및 캐싱 답변에 전적으로 동의합니다. 가장 큰 속도와 스케일 병목 현상을 식별 할 때까지 최적화를 위해 Kohana 레이어를 살펴 보지 마십시오.

Xdebug는 당신이 당신의 코드에서 가장 많은 시간을 보내고 '핫스팟'을 식별했다고 말할 것입니다. 이 프로파일 링 정보를 유지하여 기준선 및 성능 향상을 측정 할 수 있습니다.

문제 및 해결책 : 매번 데이터베이스에서 비싼 물체를 구축한다는 것을 알게되면 실제로 자주 변하지 않는 경우 멤버 또는 다른 메커니즘으로 캐싱을 볼 수 있습니다. 이러한 모든 성능 수정은 시간이 걸리고 시스템에 복잡성을 추가하므로 수정을 시작하기 전에 병목 현상을 확인하십시오.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow