Program Tip

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

programtip 2020. 10. 6. 18:56

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

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

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

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

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

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

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

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

역방향 프록시 사용

정말 유용 할 수있는 첫 번째 방법은 웹 서버 앞에 varnish 와 같은 역방향 프록시를 사용하는 것입니다. 가능한 한 많은 것을 캐시 하도록하여 실제로 PHP / MySQL 계산이 필요한 요청 만 (물론 다른 요청이 프록시의 캐시에없는 경우) Apache / PHP / MySQL로 보냅니다.

우선, CSS / Javascript / Images-음 , 정적 인 모든 것 - 아마도 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을 사용하는 좋은 이유라는 점에 유의하십시오 ( 몇 가지 벤치 마크 (프랑스어) 를 작성했으며 결과는 훌륭합니다) ...
물론 PHP 5.2가 수명이 다한 또 다른 좋은 이유는 , 그리고 더 이상 유지되지 않습니다!

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

나는에 대해 생각하고 대체 PHP 캐시 - APC 예를 들어, ( PECL , 수동 ) 내가 작업 한있는 모든 서버에서 사용되는 -, 내가 사용 본 적이 솔루션 가장이다.
- 참조 : 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가 할 수없는 일입니다 ^^)

(Thanks @Mikushi for the comment) Another possibility that I haven't used much is the the xhprof extension : it also helps with profiling, can generate callgraphs -- but is lighter than Xdebug, which mean you should be able to install it on a production server.

You should be able to use it alonside XHGui, which will help for the visualisation of data.

On the SQL side of things:

Now that we've spoken a bit about PHP, note that it is more than possible that your bottleneck isn't the PHP-side of things, but the database one...

At least two or three things, here:

You should determine:
- What are the most frequent queries your application is doing
- Whether those are optimized (using the right indexes, mainly?), using the EXPLAIN instruction, if you are using MySQL
  - See also: Optimizing SELECT and Other Statements
  - You can, for instance, activate log_slow_queries to get a list of the requests that take "too much" time, and start your optimization by those.
- whether you could cache some of these queries (see what I said earlier)
Is your MySQL well configured? I don't know much about that, but there are some configuration options that might have some impact.
- Optimizing the MySQL Server might give you some interesting informations about that.

Still, the two most important things are:

Don't go to the DB if you don't need to: cache as much as you can!
When you have to go to the DB, use efficient queries: use indexes; and profile!

And what now?

If you are still reading, what else could be optimized?

Well, there is still room for improvements... A couple of architecture-oriented ideas might be:

Switch to an n-tier architecture:
- Put MySQL on another server (2-tier: one for PHP; the other for MySQL)
- Use several PHP servers (and load-balance the users between those)
- Use another machines for static files, with a lighter webserver, like:
  - lighttpd
  - or nginx -- this one is becoming more and more popular, btw.
- Use several servers for MySQL, several servers for PHP, and several reverse-proxies in front of those
- Of course: install memcached daemons on whatever server has any amount of free RAM, and use them to cache as much as you can / makes sense.
Use something "more efficient" that Apache?
- I hear more and more often about nginx, which is supposed to be great when it comes to PHP and high-volume websites; I've never used it myself, but you might find some interesting articles about it on the net;
  - for instance, PHP performance III -- Running nginx.
  - See also: PHP-FPM - FastCGI Process Manager, which is bundled with PHP >= 5.3.3, and does wonders with nginx.

Well, maybe some of those ideas are a bit overkill in your situation ^^
But, still... Why not study them a bit, just in case ? ;-)

And what about Kohana?

Your initial question was about optimizing an application that uses Kohana... Well, I've posted some ideas that are true for any PHP application... Which means they are true for Kohana too ;-)
(Even if not specific to it ^^)

I said: use cache; Kohana seems to support some caching stuff (You talked about it yourself, so nothing new here...)
If there is anything that can be done quickly, try it ;-)

I also said you shouldn't do anything that's not necessary; is there anything enabled by default in Kohana that you don't need?
Browsing the net, it seems there is at least something about XSS filtering; do you need that?

Still, here's a couple of links that might be useful:

Conclusion?

And, to conclude, a simple thought:

How much will it cost your company to pay you 5 days? -- considering it is a reasonable amount of time to do some great optimizations
How much will it cost your company to buy (pay for?) a second server, and its maintenance?
What if you have to scale larger?
- How much will it cost to spend 10 days? more? optimizing every possible bit of your application?
- And how much for a couple more servers?

I'm not saying you shouldn't optimize: you definitely should!
But go for "quick" optimizations that will get you big rewards first: using some opcode cache might help you get between 10 and 50 percent off your server's CPU-load... And it takes only a couple of minutes to set up ;-) On the other side, spending 3 days for 2 percent...

Oh, and, btw: before doing anything: put some monitoring stuff in place, so you know what improvements have been made, and how!
Without monitoring, you will have no idea of the effect of what you did... Not even if it's a real optimization or not!

For instance, you could use something like RRDtool + cacti.
And showing your boss some nice graphics with a 40% CPU-load drop is always great ;-)

Anyway, and to really conclude: have fun!
(Yes, optimizing is fun!)
(Ergh, I didn't think I would write that much... Hope at least some parts of this are useful... And I should remember this answer: might be useful some other times...)

Use XDebug and WinCacheGrind or WebCacheGrind to profile and analyze slow code execution.

_{(source: jokke.dk)}
WinCacheGrind

Profile code with XDebug.

Use a lot of caching. If your pages are relatively static, then reverse proxy might be the best way to do it.

Kohana is out of the box very very fast, except for the use of database objects. To quote Zombor "You can reduce memory usage by ensuring you are using the database result object instead of result arrays." This makes a HUGEE performance difference on a site that is being slammed. Not only does it use more memory, it slows down execution of scripts.

Also - you must use caching. I prefer memcache and use it in my models like this:

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;
}

This will also dramatically increase performance. The above two techniques improved a sites performance by 80%.

If you gave some more information about where you think the bottleneck is, I'm sure we could give some better ideas.

Also check out yslow (google it) for some other performance tips.

Strictly related to Kohana (you probably already have done this, or not):

In production mode:

Enable internal caching (this will only cache the Kohana::find_file results, but this actually can help a lot.
Disable profiler

Just my 2 cents :)

I totally agree with the XDebug and caching answers. Don't look into the Kohana layer for optimization until you've identified your biggest speed and scale bottlenecks.

XDebug will tell you were you spend the most of your time and identify 'hotspots' in your code. Keep this profiling information so you can baseline and measure performance improvements.

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

참고 URL : https://stackoverflow.com/questions/1260134/optimizing-kohana-based-websites-for-speed-and-scalability

'Program Tip' 카테고리의 다른 글

Google Maps API V3 : 이상한 UI 디스플레이 결함 (스크린 샷 포함) (0)	2020.10.06
Unix의 특수 문자에 대한 grep (0)	2020.10.06
iOS 9의 스 와이프 가능한 표보기 셀 (0)	2020.10.06
Python-클래스에서 "self"를 사용하는 이유는 무엇입니까? (0)	2020.10.06
물체 감지 및 컴퓨터 비전의 mAP 메트릭 (0)	2020.10.05

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

programtip

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

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

역방향 프록시 사용

PHP 측면에서 :

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

데이터에 캐시 사용

프로파일 링

On the SQL side of things:

And what now?

And what about Kohana?

Conclusion?

'Program Tip' 카테고리의 다른 글

'Program Tip'의 다른글

티스토리툴바

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

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

역방향 프록시 사용

PHP 측면에서 :

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

데이터에 캐시 사용

프로파일 링

On the SQL side of things:

And what now?

And what about Kohana?

Conclusion?

'Program Tip' 카테고리의 다른 글

'Program Tip'의 다른글

관련글

티스토리툴바