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은 성능에 관한 것이지 확장성에 관한게 아니다. 확장성은 구조 문제이지 언어에 관한게 아니다)"라는 말을 새겨보자.

저작자 표시
신고