Rasmus 아저씨의 "Simple is Hard"라는 PT 중 PHP 성능에 관한 내용 일부를 소개해볼까 한다. 이 아저씨의 Simple is Hard라는 PT가 좀 여러 버전이 있는데, 2008년 DrupalCon 발표자료를 참고했다. 예전에  소개했던 자료랑 거의 비슷하긴 한데 좀 추가된 내용이 있어서 재탕을 해볼까 한다.

그나저나, 참 뭐 하나 만들고 운영하고 하는데 신경 쓸 일이 한두 가지가 아니다. 설계도 중요하고, 보안도 생각해야되고, 성능도 빼놓을 수 없고 ... 잘 한답시고 주구장창 붙잡고 있어도 안 된다. 인생은 타이밍이니까. 그런데 요즘 HipHop도 공개되고 그러는 분위기니까 '성능'이란 주제에 대해 좀 더 생각해보는 시간을 갖도록 하자. 안그래도 구글이 빠른 웹사이트에 랭킹 보너스를 줄지도 모른다는 얘기도 있고. 빠른 웹사이트가 빠르면 좋은거다.

오늘은 잡설은 짧게 끝내고 본론 바로 갑니다. 이 PT는 Scalability, Performance, Security 이렇게 세 부분으로 나뉜다. Scalability는 한국말로 옮기기가 참 애매한데, 확장성이라고 주로 옮기기는 하는 모양이지만 꼭 그 뜻은 아니고, 간혹 가용성 이렇게 옮기기도 하는데 꼭 그 뜻도 아닌 것 같다. 아.. 이것도 본론은 아닌데. 다음 문단부터 본론 나갑니다.

이 자료에서 Rasmus 아저씨는 "PHP가 성능상의 병목이 되는 경우는 흔치 않지만, 몇 가지 도구를 써서 성능을 향상하는 기법을 소개합니다.

8페이지부터 시작합니다. 우선 Laconica, Habari, Wordpress, Magento를 차례대로 Siege로 테스트합니다. 표 안의 숫자는 높을수록 빠른거에요. 1초에 몇 번의 트랜잭션(즉 페이지뷰)을 처리하는지. (Siege는 Apache ab랑 비슷한 벤치마킹 툴)

normal with APC enabled 
Laconica - PHP 5.2.7-dev 18.71   45.37
Laconica - PHP 5.3.0-dev 20.58   46.14
Habari - PHP 5.2.10-dev 11.41   26.69
Wordpress 7.27  33.08
Magento 2.33 4.10

일단 APC를 안 쓸 이유가 없다는 걸 알 수가 있다. APC는 eAccelerator같은 OP Code Cache의 하나다. Rasmus 본인이 개발한거고. 보통은 eAccelerator를 많이들 쓰던데 특별한 이유는 모르겠다. 내 경우 APC나 eAccelerator에서 문제가 있던 부분을 xCache(lighttpd 개발자가 만든 OPCode cacher)를 써서 해결본 경험이 있기는 하다. 자세하게 분석하거나 벤치마킹 해본 건 아니니 그냥 참고하시라고.

이어서 10페이지부터는 System call overhead를 줄여서 성능상의 이득을 얻는 과정이 나온다. 이를테면 Apache httpd.conf에 DirectoryIndex index.php를 명시해줘서 index.html index.cgi index.pl index.php를 차례대로 찾는 수고를 줄이는 것 만으로도 시스템콜을 절약할 수 있다는 얘기다. 개발자로서는 놓치기 쉬운 부분 되겠다.

다음은 include_path다.

;include_path = ".:/usr/local/lib/php"
include_path = "/usr/local/lib/php:."

현재 디렉토리(.)를 먼저 찾은 다음에 /usr/local/lib/php를 찾도록 되어있던 걸 순서만 바꿔준건데 이것만으로 시스템콜이 많이 줄어든 걸 볼 수 있다.

수정하기전:
close(10)                               = 0

getcwd("/var/www/laconica", 4096)       = 18
time(NULL)                              = 1216449985
lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/www", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/www/laconica", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/www/laconica/PEAR.php", 0xbffcf5fc) = -1 ENOENT (No such file or directory)
open("/var/www/laconica/PEAR.php", O_RDONLY) = -1 ENOENT (No such file or directory)
time(NULL)                              = 1216449985
open("/usr/local/lib/php/PEAR.php", O_RDONLY) = 10
fstat64(10, {st_mode=S_IFREG|0644, st_size=34813, ...}) = 0
stat64("./PEAR.php", 0xbffd1654)        = -1 ENOENT (No such file or directory)
stat64("/usr/local/lib/php/PEAR.php", {st_mode=S_IFREG|0644, st_size=34813, ...}) = 0
close(10)                               = 0

수정한다음:
close(10)                               = 0
time(NULL)                              = 1216450700
open("/usr/local/lib/php/PEAR.php", O_RDONLY) = 10
fstat64(10, {st_mode=S_IFREG|0644, st_size=34813, ...}) = 0
stat64("/usr/local/lib/php/PEAR.php", {st_mode=S_IFREG|0644, st_size=34813, ...}) = 0
close(10)                               = 0

각각이 뭐하는건지 자세히는 모르더라도, 여러 디렉토리에서 파일이 있나없나 찾아보는데 시간을 많이 썼었다는 걸 짐작해볼 수 있다. 이렇게 고치고 나니 45.37 trans/sec 나오던 것이 46.63 trans/sec으로 빨라졌다. 2.7% 빨라진건데, 큰 수치가 아니라 생각할지도 모르지만 소스코드 한 줄 안 고치고 이정도면 대단한거다. 시스템이 크고 바쁠수록 더.

그런데 혹시나 해서 부연 설명하는건데, 무조건 저렇게 고친다고 빨라지는게 아니라, 로그를 남기고 그걸 분석해서 뭘 할지 정해야된다. "아, include_path에 .를 무조건 마지막에 넣는구나."와 같은 결론을 내리면 곤란하다.

다음은 apc.stat값을 0으로 바꾸는 것이 어떤 영향을 미치는지를 보여주고 있다. apc.stst은 APC OP cache의 설정값 중 하나인데 소스코드가 거의 바뀌지 않는 상황(예를들어 실제 운영중인 서버)에서 유용하게 쓸 수 있다. 이 값은 기본이 켜진(1) 상태인데, 이 상태에서는 APC가 혹시 소스코드에 바뀐게 있나 계속 검사를 한다. 그런데 이걸 꺼버리면(apc.stat=0) 웹서버를 재시작하거나 강제로 캐시를 비우지 않는 한 계속 캐시된 OP Code를 쓴다. 메뉴얼에 다 나온 내용이니 RTFM하시기 바란다. 이런류의 설정은 굉장히 유용하긴 한데 정확한 의미를 모르고 쓰거나, apc.stat=0으로 해놓고 까먹거나 하게되면 "왜 고쳤는데 반영이 안 되는거야!?" 따위의 어이없는 혼선을 빚을 수 있다.

왼쪽이 apc.stat 고치기 전, 오른쪽이 후.


왼쪽에는 있는 것들 중에 오른쪽에는 안보이는 것들이 좀 있다. 그만큼은 절약이 된거라고 보면 되겠다. 벤치마크 결과를 확인해보면 46.15 trans/sec. 큰 의미는 없는 수치로 보인다. 하지만 로그에서 보았듯이 실제로는 절약되고 있기 때문에 아주 바쁜 상황에서라면 고려해볼 수 있는 방법이다.

14, 15장에서는 include hierarchy를 고쳐 성능상의 이득을 보는 방법을 설명한다. include 계층이 어떻게 되는지 조사하는데 PECL/Inclued(스펠링 주의. 오타아님)를 쓴다. 쪼고만 모니터에서 비교해보느라 눈 빠지는 줄 알았다.

위가 시술전 아래가 시술후다. 이 아저씨가 뭘 어떻게 고쳤는가 모르겠다만, 내가 이해한 건 이렇다. 시술전에는 common.php가 DataObject.php를 require_once함에도 불구하고, common.php가 불러들이는 다른 여러 파일들이 DataObject.php를 또 불러댄다. 즉 점선으로 표시된 의존관계 중 어떤 것들은 군더더기라는 뜻이다. 이런식으로 몇 군데를 고친 것 같은데 다들 숨은그림 찾듯이 찾아보시고 저도 좀 알려주세요. 30인치 모니터가 있으면 저도 볼 수 있는데....

중요한게, 그래서 얼마나 효과를 봤느냐? 46.15 에서 49.84로 뛰었다. 1%에 조금 못 미치지만 괜찮지 않습니까?

지금까지는 주로 설정이나 순서 이런걸 바꿔서 효과를 보는, 상대적으로 쉬운 방법들이었다. 이번에는 프로파일링을 해 본다. 프로파일링 툴로 valgrind나 xdebug를 쓴다. 프로파일링 결과를 여기서 보는것처럼 그래프로 그려서 볼 수도 있는데, 꼭 그래프로 안 봐도 되기는 하지만 이렇게 보면 멋있기는 하다. 암튼 결과를 보고 어느 함수가 자원을 많이 잡아먹는지를 확인할 수 있다. 확인했는게 그 루틴이 너무 중요한거면 어쩔 수 없지만 만약 대안이 있다면 .....

첫 번째 사례로 Remove some XMLWriter code라는걸 소개했는데, 아마 꼭 필요하지 않은 코드였거나 좀 더 가벼운 (자원 덜 먹는) 코드로 대체했다는 뜻인 것 같다. 특히 XML하고 관련된 것들이 메모리나 자원을 엄청 잡아먹는 경향이 있는데 간단한 XML이라면 DOM이나 OO스타일의 라이브러리 안 쓰고 그냥 문자열로 만들어도 된다는게 내 생각이다.

두 번째 케이스에서는 PHP가 시스템의 기본 Timezone을 쓰느라 헛짓하는 걸 간단하게 php.ini파일에 date.timezone 설정을 추가해서 정리해준다. 이렇게만 해줘도 160 trans/sec정도였던 것이 180으로 향상되었다.

다음이 진짜 재밌는데, 내가 이걸 보면서 "앗 정리해서 포스팅해봐야겠다"고 생각했었다. 간단하게 "Hello World"만 출력하는 루틴의 성능을 비교해보는건데 Plain HTML부터 CakePHP, CodeIgniter, Zend Framework 등 널리 쓰이는 프레임웍에다 .. 두둥 .. Drupal 6.4도 같이 비교를 해놔서 아주 재밌었다. (DrupalCon에서 발표한거니까 ㅋㅋ) 이 페이지부터 차례로 넘겨보면 되겠다. 행여나 이런 단순 벤치마크를 가지고 확대해석하는 분들은 없었으면 하는게 나의 작은 소망이자 바램이다.

 Method  transactions / sec
 Plain HTML 611.78 
 Trivial PHP 606.77 
 CakePHP 1.2.0.rc2 25.88 
 Symfony 1.1 100.63 
 Solar 1.0.0alpha1 271.18 
 Agavi 1.0-beta1 (production) 126.91
 Zend Framework 1.6.0-rc1(with include_path tweak) 130.08 
 CodeIgniter 1.6.3 305.90 
 Prado 3.1.2 76.95 
 Drupal 6.4 51.37 

참 가지각색이죠? 2년차 드루팔러로서 변호를 좀 해보자면, 드루팔은 다른 MVC 웹프레임웍하곤 좀 다르죠. 그것들보다는 좀 더 상위에 있다고 보는게 맞고, 아무리 Hello World만 출력하는 모듈을 짜넣었다고 해도 기본적으로 권한이라던가 캐시라던가 DB연결 이런게 다 돌아가고 있다는겁니다. 그러니까 단순비교는 무리.

자 지금까지 Simple is Hard라는 라스무스 아저씨의 발표자료를 살펴봤다. 직접 발표장에 간 것도 아니고 동영상을 본 것도 아니라 내가 잘못 이해한게 있을지도 모르겠지만 손가락을 보지 말고 달을 보는 지혜를 발휘해보도록 하자.

저작자 표시
신고

HipHop for PHP 소식 조금 더.

몇 일 인터넷이 안됐다. 시간이 천천히 가더라. 그 사이에 HipHop이 공개됐나 봤더니 아직이다. GitHub에 위키 몇 페이지가 올라오긴 했지만 소스코드는 몇 일 더 기다려 달란다.

Within the next few days (and maybe even sooner) we'll release an initial copy of the source code that you can build on CentOS, but doesn't have a lot of commit history and has some workarounds for these build issues.

몇 일 내에(어쩌면 더 빨리) CentOS에서 빌드할 수 있는 첫 번째 소스코드를 내놓을 겁니다. 하지만 커밋 히스토리가 별로 없고 지금 겪고있는 빌드관련 문제를 피하기 위한 코드가 있을겁니다. (즉, 완전하지 않을거란 말)

힙합에 관심을 갖고 찾아보신 분들은 알겠지만, 이게 얼른 가져다 쓸 수 있는 물건이 아니다. 최소한 아직은 아니다. 힙합이 어떤 의미를 가져다주는가에 대해 잘 정리한 글이 있어 허락도 안 받고 옮겨본다.

원문은 굉장히 길어서 일부분만 옮긴다. 원문은 http://terrychay.com/article/hiphop-for-faster-php.shtml

What HipHop means

힙합이 (당신에게) 의미하는 것

If you use some open-source PHP applications on your hosted website, the answer is nothing. You don’t have the ability to compile HipHop, you don’t have access to server restricted ports, etc.

공유 호스팅(대부분의 웹호스팅에 해당)에서 오픈소스 PHP 프로그램(드루팔, 워드프레스, 텍스트큐브 등)을 쓰고 있다면 의미없다. HipHop으로 컴파일 할 수도 없고 서버의 제한된 포트도 쓸 수 없고 등등.

If you are developing a PHP application that currently can be run on two servers or less (or virtual servers in the cloud) the answer is nothing. You don’t have the scale for this to be worth your time.

두어개 정도의 서버(혹은 가상서버)에서 실행되는 PHP프로그램을 개발하고 있다면 역시 의미없다. 시간을 들일만한 규모가 아니다. (작은 규모에서는 별로 얻는게 없다는 뜻)

If you do not have a separate development and deployment environment, don’t have a developer who knows C/C++, or use any PHP libraries where the source is not available (thankfully the encoded scripting market is small to non-existent in the PHP world), then the answer is nothing. You don’t have the development model that can support HipHop. Also note, HipHop has bugs, and—given the state of APC development as a model—will never have true compatibility with PHP. You’ll need some resources to either recode around those bugs or fix HipHop.

만약 개발과 배포 환경이 분리되어있지 않거나, C/C++를 아는 개발자가 없거나, 소스코드가 제공되지 않는 PHP 라이브러리를 쓴다면 (다행히 PHP 세계에는 인코딩된 스크립트 시장이 거의 없다) 대답은 '의미없음'이다. HipHop을 쓸 수 있는 개발 모델이 아니다. 추가로 HipHop에는 버그가 있다. 그리고 APC가 그러하듯 HipHop은 PHP와 진정한 호환성을 가질 수 없다. 버그를 고치거나 HipHop을 수정할 필요가 있을거다.

If you are a developer of an open-source PHP application, then the answer is not much. Most PHP applications will be deployed in a shared-hosted environment. They won’t be using HipHop.

오픈소스 PHP 소프트웨어를 개발하고 있다면 그다지 큰 의미 없다. 대부분의 PHP 소프트웨어는 공유호스팅에서 배포되기 때문이다. 그들은 HipHop을 지원하지 않을거다.

If you are a shared hosting company, the answer is not much. This is because the HipHop parser needs access to all the PHP in an application in order for it to create a working project. The exception is if you provide software as a service that you maintain (say a static build of WordPress, or a custom site tool written in PHP). You can have HipHop optimize this and get the performance increase.

공유 호스팅 회사에게도 큰 의미는 없다. 왜냐하면 HipHop이 실제로 작동하려면 그 PHP 애플리케이션 전체에 접근할 수 있어야 한다. (즉 모든 소스코드에 접근해야 한다는) 예외적으로 static build한 워드프레스나 직접 개발한 사이트 관리툴을 제공하고 있다면, 그것들의 HipHop 버전을 제공함으로서 성능 향상을 꾀할 수는 있을거다.

If PHP is not the operational bottleneck of your web application (your app spends a lot of time waiting on the database, disk, a 3rd party Web API call, etc.), the answer is not yet. At this time, there’s no point in getting a performance gain in PHP. If you don’t know what I’m talking about, your bottleneck is the database.

만약 PHP가 운영상의 병목지점이 아니라면(즉 DB나 Disk, 써드파티 API call등에서 시간을 많이 소비한다면), 대답은 '아직'이다. 지금 PHP에서 (HipHop을 도입해서) 얻을 수 있는 성능상 잇점이 없다. 무슨 얘긴지 모르겠다면 지금 당신의 병목지점은 DB다. (ㅋㅋ)

If you have an application already scaled across many machines, a significant number of them running PHP in processor-intensive tasks, have separate development/deployment, have your entire PHP source code, have modest C/C++ resources, then the answer is possibly. It wouldn’t hurt for a developer there to try a hand at cross-compiling the PHP into HipHop and seeing if it runs. An operational deployment will return about 50% of those machines to a pool for other uses or future growth—or, put differently HipHop will basically double that processing on the same hardware/power.

많은 서버에 걸쳐 동작하는 애플리케이션을 갖고있고, 그 중 많은 서버가 프로세서를 잡아먹는 작업을 하는 PHP를 운영중이라면, 그리고 분리된 개발/배포 체계를 갖고 있고 모든 PHP 소스코드도 가지고 있고 C/C++ 자원도 있다면, 답은 '어쩌면'이다. HipHop으로 크로스컴파일하고 돌아가는지 한 번 시도해보는 것도 나쁘진 않을거다. (성공한다면) 50% 정도의 머신은 다른 용도로 쓰거나 앞으로의 성장을 대비할 수 있을거다. 다시말하자면 기본적으로 HipHop은 같은 하드웨어/성능으로 (PHP에 비해)두 배의 프로세스를 처리한다.

If you make a turnkey application based on PHP, the answer is somewhat. These are rare, but now you can shrink-wrap PHP into a binary. This isn’t the intended use of HipHop, so some development might have to be done to get this fully supported. Also this is a true binary, not an op-code compile—it cannot run across platforms.

만약 PHP 기반의 턴-키 애플리케이션을 만들고 있다면 HipHop은 어느정도 의미가 있다. 드물긴 하지만 PHP를 바이너리로 포장할 수 있다. HipHop의 원래 용도가 아니기 때문에 ..(뭐라는지 모르겠음) 그리고 이건 OP-code가 아니라 진짜 바이너리다 - 다른 플랫폼에서는 동작하지 않는다.

If you are developing a PHP framework, the answer is some. If your framework can compile and run successfully in HipHop, then it should be a good selling point to enterprises in case their application becomes bottlenecked on performance.

만약 PHP 프레임웍을 개발하고 있다면 대답은 '약간'이다. 만약 제작한 프레임웍이 HipHop으로 잘 컴파일되고 실행된다면, 기업에 그 프레임웍을 판매할 때 좋은 요소가 된다. 특히 그 애플리케이션이 성능상의 병목이 된다면.

If you have highly-cohesive parts of your architecture that fall into above requirements and those parts are weakly-coupled (via API?) to the rest of the system, then the answer is a lot. Those parts can probably benefit from HipHop, and it should be relatively easy to try it.

만약 전체 아키텍쳐에서 위에 언급한 요구조건에 해당하면서 highly-cohesive()한 부분이 있다면, 그리고 그 부분이 시스템의 다른 부분과 느슨하게 연결되어 있다면 (API등을 통해서) 큰 의미가 있다. 그 부분들은 HipHop으로 큰 이득을 볼 수 있고, 상대적으로 시도해보기 쉬울거다.

If you are making a decision on which web language to build your site in, the answer is a heck of a lot. Arguing against PHP for performance reasons no longer holds water. PHP under HipHop will probably now out-benchmark Perl, Python, Ruby and possibly even Java and C#. In practice, you can get the advantages of having a scripting language without operational costs. Moreover, because the target is C++ which is more easy to integrate as a library, if you have a multi-language support, you can now provide C++, Python, and other languages with access to components that have before only been written in PHP (without resorting to a web API).

웹사이트를 어떤 언어로 개발할지 결정하는 중이라면 의미는 굉장히 크다. PHP의 성능에 관한 논쟁은 끝이다. HipHop/PHP 벤치마크는 아마도 Perl, Python, Ruby를 넘어서고 어쩌면 Java나 C#마저도 제낄지 모른다.실제로 운영비용 없이 스크립트 언어의 장점을 가질 수 있다. 게다가 C++는 다른 언어와 라이브러리 형태로 통합하기 쉽다. 만약 이전에는 PHP로만 제공되었던 컴포넌트를 여러 언어에 지원해야 한다면 이제 C++나 파이썬 그리고 다른 언어들을 제공할 수 있다. (즉 PHP로 작성한 콤포넌트를 다른 언어에 바인딩하기 쉬워졌다는 말인 듯)

If you are making an argument to recode your entire site from PHP to some other language, the answer is you just lost that argument. (I never bought the argument of recoding an entire site from another language to PHP.)

만약 PHP로 개발한 사이트를 통째로 다른 언어로 다시 코딩하는 것에 관해 논쟁하고 있다면, 그 논쟁은 끝이다.

----

원문을 읽어보면 힙합에 대한 정보를 더 많이 얻을 수 있기는 한데, 워낙 긴데다 다른 글을 많이 인용해놔서 읽기가 벅차다. 암튼 정리를 해보자면, HipHop for PHP 뿐 아니라 그 어떤 것도 만병통치약이 될 수는 없는거다. 특히 "HipHop is a performance mod, not a scalability one. That’s good because scalability is an architecture problem, not a language one. (HipHop은 성능에 관한 것이지 확장성에 관한게 아니다. 확장성은 구조 문제이지 언어에 관한게 아니다)"라는 말을 새겨보자.

저작자 표시
신고



티스토리 툴바