厳選されたオンラインコンパイラー: ブラウザーでコードを直接実行してテストします。コンパイルについて考える時期

20.01.2024

PHP はインタープリタ型プログラミング言語であり、リクエストごとにソースコードが分析されて「実行」されます。もちろん、このアプローチはプロジェクト開発段階では非常に便利ですが、実稼働コードを実行するプロセスに追加のステップが導入されます。したがって、一見すると PHP の強みである解釈には、余分な CPU 時間とリソースがかかります。

以下では、PHP コードを C++ にコンパイルし、それを実行可能コードにコンパイルできるコンパイラーについて説明します。したがって、PHP アプリケーションは、インタープリターをバイパスして、プロセッサーによって直接実行されます。

実際にすべてがうまくいくかどうかを確認してみましょう。

通訳の仕組み

PHP コードの解釈は 2 つの段階で行われます。

コードの解析とオペコード (Zend オペコード) の生成 - インタプリタが理解できる命令。
オペコードの実行。

最初のフェーズは (オペコードキャッシュを使用した) 最適化に適していますが、2 番目のフェーズは完全にクローズドです。インタプリタは常に、一連の命令とそれらを実行するプロセッサとの間の仲介者です。インタプリタがなければ、プロセッサはオペコードをどう処理するかを理解できません。

インタプリタのリンクを取り除くために、コンパイラが発明されました。その中で最も人気があり、最近のものは Facebook の HipHop です。もっと近くで感じてみよう。

ヒップホップ PHP

HipHop は Facebook 開発者によって作成され、次のようなアプリケーションです。

PHPコードを最適化します
C++ に変換します
アプリケーションからそれを実行するマルチスレッド Web サーバーを生成します
g++ を使用して実行可能コードにコンパイルします

したがって、入力は PHP コード、出力はサーバーであり、その一部は記述された機能です。

Wordpress などのフレームワークを使用して作成されたアプリケーションのコンパイルを HipHop がどのように処理できるかを確認してみましょう。

Wordpress のコンパイル

HipHop をインストールした後、src/hphp/ フォルダーにコンパイラーである hphp ファイルを取得します。コンパイルを開始する前に、環境変数を設定します。

Cd .. # hiphop のあるフォルダーに移動します。

そして先に進みましょう！

Wordpress をダウンロードし、アーカイブを解凍します。

Wget http://wordpress.org/latest.tar.gz tar zxvf 最新.tar.gz

wp-config-sample.php を wp-config.php にコピーし、データベースに接続するための設定を指定します (ホスト設定では、localhost ではなく 127.0.0.1 を指定します)。

コンパイルを成功させるには、Wordpress に少しパッチを適用する必要があります。

wp-includes/js/tinymce/plugins/spellchecker/classes/SpellChecker.php を開き、 function &loopback(/* args.. */) ( return func_get_args(); ) を function &loopback(/* args.. */) に置き換えます。 ) ( $ret = func_get_args(); return $ret; )
wp-includes/query.php では、 if (!isset($q["suppress_filters"])) $q["suppress_filters"] = false; の代わりに、 $q["suppress_filters"] = true を挿入します。

ワードプレスの準備ができました。

Hiphop では、コンパイルするファイルのリストを指定する必要があります。それを取得して、files.list に保存します。

探す。 -name "*.php" > files.list

コンパイルの準備がすべて整ったので、次に進みます。

$HPHP_HOME/src/hphp/hphp --input-list=files.list -k 1 --log=3 --force=1 --cluster-count=50

コマンドが完了すると、一時フォルダー (コンパイルの開始時に、hphp は「/tmp/hphp_ptRgV1」などのパスを表示します) に、コンパイルされた Web サーバーを受け取ります。これを起動してみましょう (Apache や nginx など、ポート 80 で何かがハングしている場合は、まずそれを停止してポートを解放する必要があります)。

Sudo /tmp/hphp_6s0pzd/program -m server -v "Server.SourceRoot=`pwd`" -v "Server.DefaultDocument=index.php" -c $HPHP_HOME/bin/mime.hdf

出来上がり！ http://localost にアクセスすると、動作している Wordpress ブログが表示されます。

パフォーマンス

apache2 で実行されているコンパイルされていないバージョンの WordPress と比較してパフォーマンスが向上するかどうかを見てみましょう。以下は、ページ生成速度の並列ユーザー数への依存性を示すグラフです。

ご覧のとおり、結果は衝撃的でした。コンパイルされたブログは平均して 6 倍の速度で実行されます。 1 秒あたりに処理されるリクエストの平均数は、コンパイルされていないバージョンでは 9 ですが、コンパイルされたバージョンでは 50 です。あなたはどうか知りませんが、これほどパフォーマンスが大幅に向上するとは予想していなかったので、この結果には驚きました。

要約しましょう

このような驚くべき結果の後、言えることはただ 1 つだけです。Facebook のスタッフは素晴らしい仕事をしたということです。コンパイラはアプリケーションを本当に強力に作成します。コンパイル前にアプリケーションを準備する必要がありますが、結果はそれだけの価値があります。

話題について:

投稿が気に入ったら、Google +1 をクリックしてください。そうすることで、書くモチベーションがさらに高まり、とても嬉しいです。

ソースコードからの PHP のコンパイルは、多くの場合 Unix 系システムで行われます。 Windows OS 環境で作業している人は、バイナリパッケージから PHP をダウンロードしてインストールする可能性が高くなります。また、プリコンパイルされたソリューションを使用する方が簡単であるという意見には同意しませんが、Unix システム上であっても、ソースからバイナリをコンパイルすることで得られる利点がいくつかあります。全体として：

コンパイル中に最終製品を微調整することができます。おそらく、外部ライブラリとしてロードするのではなく、バイナリに直接コンパイルする特定の拡張機能が必要になるでしょう。あるいは、通常はデフォルトで使用できるものをオフにしたい場合もあります。
必要に応じてコンパイルプロセス中に、特定の環境のパフォーマンスを向上させるトリックを行うことができます (もちろん、この場合に何をしようとしているのかをすでに知っていることが前提です) あなたはこの記事を読まないでしょう !).
コンパイルされたバイナリが古いバージョンのサポートソフトウェアおよびライブラリに基づいて構築されており、現在新しいシステムで実行している場合、コンパイルが動作させる唯一の方法である可能性があります。

警告：コンパイルは、特に Windows ではイライラすることがあります。ビルド環境が正しく設定されていることを確認し、コンパイラーやその他のビルドツールの適切な使用方法を学習し、ライブラリの依存関係を満たす必要があります。この記事が、これらの障害の多くを克服するための第一歩となることを願っています。

ビルド環境のセットアップ

PHP は C で書かれているため、ソースコードから PHP をビルドする場合は C コンパイラが必要です。 C++ は C のスーパースイートであるため、優れた C++ コンパイラは C コードをコンパイルできる必要がありますが、常にそうであるとは限りません。 Windows の場合、Visual Microsoft、C++ Express (後に VC++ と呼ばれます) は Microsoft Web サイトから無料で入手できます。 2010年版を使用しました。

コンパイラーのバージョンを選択するときは、PHP をどのように実行するかを念頭に置く必要があります。公式にコンパイルされた Apache バイナリの mod_php を使用する必要があり、その場合は、Visual Studio 6 を使用して PHP をコンパイルします。これは、Apache コンパイルバージョンであるためです。モジュールは、Apache と同じランタイムライブラリ (この場合は msvcrt.dll) をターゲットにする必要があります。 Apache をソースからビルドする場合、または PHP を FastCGI または CLI として実行する場合、これは問題なく、2010 は正常に動作します。

Windows 開発キット (SDK) ソフトウェアもインストールする必要があります。 SDK は、正常にコンパイルするために必要な Windows プラットフォーム用の重要なヘッダーファイルを提供します。これもバージョン 7.1 が使用されました。

コンパイラをインストールしてから SDK をインストールします。どちらにもプロセス全体をガイドするグラフィカルなインストールウィザードがあるため、インストールについては説明しません。

動作するコンパイラビルドがある場合は、windows.php.net からバイナリツールと既知のパッケージをダウンロードします。バイナリツールパッケージ (私は 20110915 アーカイブを使用しています) には、re2c、bison などの開発ツールと、PHP のビルドに必要な追加のコマンドが含まれています。既知のパッケージ (コンパイルする PHP バージョンと一致するため、5.4 アーカイブを使用しています) には、必要な最小限のヘッダーと依存関係ライブラリ (zlib.h など) が含まれています。

PHP ソースも windows.php.net からダウンロードすることは言うまでもありません。この記事の執筆時点では、PHP の現在のバージョンは 5.4.6 なので、これが例に表示されるバージョン番号です。

システムの他の部分に影響を与えないように、ソースコードを抽出してコンパイルできるワークスペースを作成することをお勧めします。作業ディレクトリとして機能するフォルダー C:\PHP-Dev を作成し、そこにバイナリアーカイブとツールを抽出します。

次に、アーカイブの内容を抽出します。C:\PHP-Dev にある PHP ソースは、ソースフォルダーに php5.4 が存在し、その deps アーカイブを deps 兄弟フォルダーに抽出します。ディレクトリ構造は次のようになります。

SDK とともにインストールされた Windows SDK コマンドプロンプトを開き ([スタート] => Microsoft Windows SDK => Windows SDK コマンドプロンプト)、次のコマンドを実行します。

Setenv /release /xp /x86 cd C:\PHP-Dev bin\phpsdk_setvars.bat

SDK コンソールコマンドラインは、ソースコードのコンパイルに固有の多くの環境変数を設定するため、通常の cmd.exe コンソールよりも前に使用することをお勧めします。後でコマンドをコンパイルする場合も、このコンソールで実行する必要があります。

setenv は、環境のいくつかのビルドプロパティを設定します。この場合、ターゲット環境は Windows XP 32 ビットバージョンのビルドです。冒険を求めている場合は、/x64 を使用してビルドしてみてください。 /Vista などの異なるバージョンの Windows を定義すると、スクリプト内の奇妙な定義が原因で出力の問題が発生する可能性が高くなります (PHP は依然として XP との互換性を望んでいます)。自分が何をしているのかよくわかっていない限り、上で使用した推奨値に従うのがおそらく最も安全です。

phpsdk_setvars.bat スクリプトはいくつかの追加の環境変数にアクセスし、ビルドプロセスはバイナリツールを見つけることができました。

これらの変数設定はすべて、コンソール内の一時的なセッションにすぎないことに注意してください。後でコンパイルに戻るためにすべてをすぐに閉じると、コマンドを再度実行する必要があります。そうしないと、後でconfigureを実行するときに次のようなエラーが表示され、続行できなくなります。

bison.exe をチェックしています ... エラー: バイソンが必要です

適切なビルド環境、必要なソース、および依存関係があることを確認するのが、プロセスの最も難しい部分です。これで、ソースコードと依存関係が適切に設定された環境がセットアップされました。次はコンパイルします。

PHPのコンパイル

SDK コマンドラインで、PHP ソースフォルダーに移動し、buildconf を実行します。このコマンドは、コンパイルプロセスを制御するために Makefile によって作成される構成ファイルを生成します。

buildconf が完了したら (これには 1 秒しかかかりません)、configure --help を実行し、有効化/無効化したい機能のヘルプを調べてから、必要なオプションを指定してconfigure を再度実行します。必要な依存関係が利用できない場合は警告が表示されるため、移動する前に出力を確認することをお勧めします。この問題が発生した場合は、依存関係をインストールしてセットアップを再実行するか、呼び出しを調整して依存関係を必要とする拡張機能を無効にすることができます。

最後に、NMAKE を実行してコンパイルを開始します。

Cd C:\PHP-Dev\php5.4 buildconf configure nmake nmake test

構成または NMAKE が失敗した場合、問題は 2 つのうちのいずれかです。1 つ目は環境が正しく構成されていないこと、2 つ目は、外部ライブラリに依存する機能が有効になっており、そのライブラリがシステムにインストールされていないことです。上記の手順に従って環境を作成したこと、および基礎となる構成設定で必要となる可能性のある追加のライブラリが構成されていることを再確認してください。

コンパイルプロセスの最初の NMAKE が完了すると、Release_TS フォルダーに新しい PHP ファイルが見つかります。 NMAKE テストは、新しい二重容量エラーテストを実行して、すべてが正常に動作していることを確認します。 NMAKE テスト結果は QA チームに送信され、QA チームは PHP を改善するためにそれを利用するため、作業には数分かかることがありますが、これは非常に重要です。

この時点で、NMAKE スナップインを実行する追加手順を利用することもできます。これにより、コピー可能な ZIP アーカイブとバイナリが作成されます。

コンパイル拡張機能

PHP 拡張機能をコンパイルするには、静的と動的の 2 つの方法があります。静的にコンパイルされた拡張機能は PHP バイナリにコンパイルされますが、動的にコンパイルされた拡張機能は 1 つの別個の DLL であり、後で php.ini ファイルを介してロードできます。拡張機能は通常 DLL としてコンパイルされますが、静的コンパイルにはいくつかの利点があり、最終的にはニーズによって異なります。

Windows で PHP 拡張機能をコンパイルするには、ソースコード拡張フォルダーを PHP ソースディレクトリの ext フォルダーに抽出します。次に、buildconf --force を実行してスクリプトを再構成し、適切なオプションを使用して PHP を再コンパイルして拡張機能を有効にします。

例として、AOP 拡張機能を静的にコンパイルしてみましょう。 PECL からソースコードをダウンロードし、フォルダー ext に抽出します。次に、次の手順に従います。

Cd C:\PHP-Dev\php5.4 buildconf --force configure --enable-aop nmake

--force、buildconf オプションを指定すると、構成スクリプトが強制的に復元されます。次に、configure --help を実行すると、出力に新しい拡張機能を有効にするオプションが表示されるはずです。この場合、--enable-AOP です。

nmake が完了すると、AOP を使用して新しく構築された PHP バイナリが作成されます。

拡張機能は、PHP で焼き付けられるのではなく、DLL として利用できます。上記と同じ手順に従うことができますが、構成の値として「shared」を指定すると、このオプションが可能になります。

Buildconf --force configure --enable-aop=shared

その結果、コンパイルが終了すると、DLL は PHP バイナリとともに Release_TS フォルダー内に存在します。この場合、名前は php_aop.dll です。

追伸

Windows でのコンパイルは、特に拡張機能に関してはまだ少し注意が必要です。ソースコードをコンパイルできることは、特に後で PHP を変更する場合には、優れたスキルです。

この記事はサイトチームによって準備されました。
元の記事:
翻訳者: ヴィクトル・クリム

ここで紹介するすべての無料の PHP コンパイラーは、特別な PHP インタープリターをダウンロードしなくても、PHP スクリプトをコンピューター上で実行できるマシンコードに再構築したり、バイトコードコマンドラインインターフェイスにコンパイルしたりできます (インストールには NET または Mono フレームワーク、または Java バイトコードが必要です)インストールには Java 仮想マシンが必要です))。

このようなコンパイラは、さまざまな目的に役立ちます。実行時に解釈されなくなるため、スクリプトの実行を高速化できます。または、それらのおかげで、ソースコード (他の商用スクリプトでは必要とされる) を公開せずにアプリケーションを配布できます。これらは、Web 対応の PHP プログラムを作成し、(サーバー上で実行される通常の Web アプリケーションではなく) デスクトップ上で実行する機能を備えたプログラムを配布したい場合にも適していると思います。これはすべて可能です。 PHP は学習しやすいプログラミング言語であり、基本的にインターネットにアクセスできる多くの組み込み関数が含まれています。 (この場合、組み込み Web サーバーを使用してアプリケーションを配布するか、サーバーをアプリケーションにコンパイルするコンパイラーを使用する必要があります。)

ちなみに、コードで難読化を使用したい場合は、次のコマンドを使用するときにも難読化が可能であることを知っておいてください。 PHPアクセラレータ。このようなアクセラレータは、スクリプトの実行速度の向上も意味します。

PHP トランスレータの公式バージョンが PHP Web サイトからダウンロードできることをまだ知らない人にとって役立つ情報: ハイパーテキストプロセッサ。

ネイティブコード、.NET、または Java バイトコードスクリプトを作成するための無料の PHP コンパイラー。

バンバラム（新規）

このプログラムは、PHP ソースコード用のスタンドアロン Windows EXE アプリケーションを生成します。ソースコードをエンコードして PHP インタープリターを埋め込むだけなので、実際にはネイティブコードコンパイラーではありませんが、ネイティブおよびバイトコードコンパイラーを探している人には確かに適しています。プログラム全体が作成された時点では、その実行環境は PHP 4.4.4 の組み込みバージョンになっていました (プログラムは 2006 年以来更新されていませんでした)。 Bambalam のソースコードは公開されています。

ファランガー (.NET 用)

Phalanger は、PHP コードを CLI バイトコード (.exe または .dll) にコンパイルします。このプログラムは、.NET 4.0 または Mono フレームワークを通じて実行できます。 PHP コードでは、任意の .NET オブジェクトと追加の標準 PHP 拡張ライブラリを使用できます。結果として得られる NET アセンブリは、署名付きまたは非表示にすることができます。このプログラムは、Visual Studio を使用して PHP アプリケーションを作成できるテンプレートも生成します。このプログラムは Apache ライセンスに基づいてリリースされています。

HipHop for PHP (ネイティブコード用)

HipHop は PHP コードを C++ コードに変換し、後で GNU C++ コンパイラを使用して実行可能なバイナリコードにコンパイルします。コンパイラは、PHP 5.3 のすべての機能をサポートします (もちろん、次のような機能は除きます)。 eval()）。 64 ビット Linux および FreeBSD 用に動作し、コードをコンパイルします。プログラムはソースコード形式で配布されるため、手動（自分で）コンパイルする必要があります。 PHPライセンスに基づいてリリースされています。

Roadsend PHP (ネイティブコード用)。

Roadsend PHP コンパイラは、Windows および Linux 用のネイティブバイナリ (実行可能ファイル) を生成します。スクリプトはコンソールプログラム (コマンドライン) に限定されません。組み込み Web サーバーを使用してスクリプトを構築でき、独自のユーザーシステム上であっても、Web サイト上で実行するのと同じ方法でスクリプトを実行できます。コンパイラは GNU GPL ライセンスの下でリリースされ、GNU LGPL の下で実行されます。残念ながら、このプログラムは積極的な開発を停止しました。

プロジェクトゼロ (Java 用)

(注: このソフトウェアは廃止されたようです。サイトは約半年前からアクセスできなくなっています。) Project Zero には、PHP コードを Java バイトコードにコンパイルして実行できるコンパイラーと CLR が含まれています。 Project Zero は単なる PHP コンパイラー/ランタイムではないことに注意してください。 PHP または Groovy (別のスクリプト言語) を使用して Web アプリケーションを拡張できる豊富なフレームワークを提供します。このコンパイラは、Windows、Mac OS X、および Linux で使用できます。このコンパイラを使用するには、Java Development Kit をダウンロードする必要があります。

提案されたコンパイラのうちどれが好みですか? それとも他にお気に入りの翻訳者がいますか? ご意見やコメントを以下に残してください。喜んで読んで参考にさせていただきます。

タグ: PHPコンパイラ、スクリプト翻訳

プログラミング言語には、インタープリタ言語とコンパイル言語の 2 種類があります。 PHPとは何の言語ですか? この質問に答えるには、用語を理解する必要があります。

あるプログラミング言語で書かれたコードを別のプログラミング言語に翻訳するプログラムは、トランスレーターと呼ばれます。コンパイラはトランスレータでもあります。高級言語で書かれたコードをマシンコードに変換します。コンパイルプロセスでは、コンパイラなしで実行できるバイナリ実行可能ファイルが作成されます。

通訳というのは全く違うカテゴリーです。インタプリタはコードを翻訳するのではなく、実行します。インタプリタはプログラムコードを分析し、その各行を実行します。このようなコードを実行するたびに、インタープリターを使用する必要があります。

バイナリコードははるかに高速に実行されるため、パフォーマンスの点では、インタプリタはコンパイラよりも大幅に劣ります。ただし、インタープリタを使用すると、プログラムの実行中にプログラムを完全に制御できます。

PHP に関しては、コンパイラーでもインタープリターでもありません。 PHP はコンパイラとインタプリタを組み合わせたものです。これを理解して、PHP がコードをどのように処理するかを見てみましょう。

写真を見てみましょう:

PHP は、トランスレーターとインタープリターという 2 つのほぼ独立したブロックで構成されていることがわかります。なぜこれを行う必要があったのでしょうか? もちろん、速度の理由からです。

PHP 入力はスクリプトです。構文をチェックしながら、それを特殊なバイトコード (内部表現) に変換します。その後、PHP は (プログラムコード自体ではなく) バイトコードを実行しますが、実行可能ファイルは作成されません。

バイトコードは通常のプログラムコードよりもはるかにコンパクトなので、解釈 (実行) が簡単 (そして高速) です。自分で判断してください。解析は翻訳段階で 1 回だけ実行され、「半完成品」、つまりバイトコードが実行されます。これは、これらの目的にははるかに便利です。したがって、PHP はコンパイラーというよりもインタープリターに近いものになります。この「二重作業」は次の目的のために必要でした。

次のループを考えてみましょう。

(i=0;i の場合)<10; i++) { Operator_1; Operator_2; Operator_3; ............ Operator_99; Operator_100; }

このサイクルは 10 回「回転」します。これら 10 回のパスごとに、通訳者は次のことを行う必要があります。 100 コード行。そして、10*100 = 1000 行のコードを分析して実行する必要があります。ループ全体を 1 回バイトコードに変換すると、解析の必要性が 10 分の 1 に減ります。これは、スクリプトが 10 倍速く実行されることを意味します。

PHP であることがわかりました。

PHP の作業の主な段階は、プログラムの内部表現の解釈とその実行です。深刻なシナリオでは、このフェーズが最も時間がかかります。ただし、減速はそれほど顕著ではありません。

PHP バージョン 3 は「純粋な」インタプリタであり、PHP バージョン 4 (および PHP5) はインタプリタ型トランスレータであるため、PHP 4 ではスクリプトがはるかに高速に実行されるようになったということを覚えておく価値があります。

Perl 言語は、ほとんどの場合コンパイラと呼ばれますが、まったく同じように機能します。プログラムテキストを内部表現に変換し、実行中に結果のコードを使用します。したがって、PHP バージョン 4 は Perl と同じくらいコンパイラであると言えます。

したがって、PHP は、解釈のフローを最適化する組み込みの変換ブロックを備えたインタープリターであると結論せざるを得ません。

インタプリタ (したがって PHP) を使用すると、否定できない利点があります。

割り当てられたメモリの解放について心配する必要はありません。ファイルの操作が終了したときにファイルを閉じる必要もありません。プログラムは監視制御の下で実行されるため、ルーチン作業はすべてインタープリタによって実行されます。
変数の型について考える必要はなく、最初に使用する前に変数を宣言する必要もありません。
プログラムのデバッグとエラーの検出が大幅に簡素化され、インタプリタがこのプロセスを完全に制御します。
Web アプリケーションのコンテキストでは、インタープリタには非常に重要な利点もあります。プログラムが正しく動作しない場合でも、サーバーが「フリーズ」する危険性がありません。

他にも利点があります。一般に、インタプリタを使用すると、Web ユーザーがスクリプトに期待する機能をスクリプトに与えることができます。

PHP のパフォーマンスの低下は、大規模で複雑なループの場合や、多数の行を処理する場合などに顕著になります。ただし、これが PHP の唯一の欠点であることに注意してください。より強力なプロセッサがリリースされるにつれて、この欠点はますます少なくなります。、最終的には完全に消えてしまいます。

<<< Назад
(PHP5 の新機能は何ですか?)

コンテンツ

進む >>>
(PHP 5.3への移行)

他にご質問がある場合、または不明な点がある場合は、こちらへようこそ。

アレクセイ・ロマネンコ：私の名前はアレクセイ・ロマネンコ、RBCで働いています。このレポートのテーマには多少の議論の余地があります。すべてがそのように動作しているように見えるのに、なぜ PHP スクリプトをコンパイルする必要があるのでしょうか?

おそらく主な疑問は「なぜ?」ということでしょう。一般に、このプレゼンテーションの目的は、そのような編集が必要かどうか、必要な場合は、その理由、どのような形式で、誰に対して必要かを理解しようとすることです。

PHPコンパイラとは何ですか?

まず、PHP コンパイラーとは何かについて簡単に説明します。それがどのように機能するか、それが何であるか、そしてそれを高速化する方法について説明します。

最初の機能モジュールは、いわゆる SAPI (サーバー API) で、さまざまなクライアント (Apache、ある種の CGI サーバー (共通ゲートウェイインターフェイス) など) から PHP にアクセスするためのインターフェイスを提供します。 SAPI も組み込まれており、PHP を任意のアプリケーションに埋め込むことができます。

2 番目の主要な部分は PHP コアで、リクエストを処理し、ネットワーク、ファイルシステムに関するすべての作業を実装し、スクリプト自体を解析します。

3 番目のグローバルパーツは Zend エンジンです。これはスクリプトを何らかのバイトコードにコンパイルし、それを仮想マシン上で実行し、メモリ管理を処理します (包括的なアロケータを実装します)。

最も重要かつ最大の部分の 1 つは、PHP で使用するものの 99% を実装する拡張モジュールです。これらは、一部のライブラリ、機能、クラス、組み込みライブラリなどの「ラッパー」です。独自の拡張機能を作成することもできます。

スクリプト自体はどのように実行されるのでしょうか?

初め。字句解析が行われます。ファイルがダウンロードされ、解析され、このファイルのセットのすべての文字が特定のトークンのセットに変換され、その後、それを処理します。

解析フェーズでは、これらのトークンを解析します。この分析に基づいて、特定の文法構造がコンパイルされ、それに基づいてバイトコードが生成されます。

最後に、Zend Engine がそれを実行します。結果はクライアントに返されます。

私たちは高負荷について話しています。この一連の操作を毎回繰り返すと、すべての動作が非常に遅くなります。私たちの通訳者が同時に数百、数千のリクエストを受け取ると、その速度はまったく存在しません。

しかし、解決策はあります。彼らは長い間知られてきました。

加速を実現するにはどうすればよいでしょうか?

最も単純で、安価で、十分にテストされたソリューションは、バイトコードキャッシュです。解析フェーズを経る代わりに、単純にバイトコードをキャッシュします。これには特別な拡張機能があり、PHP を使ったことがある人にはよく知られています。APC、eAccelerator、Xcache などです。 Zend Engine は単純にバイトコードを実行します。

2 番目のオプションはコードプロファイリングで、ボトルネックを特定します。何かを PHP 拡張機能 (これは C/C++ の拡張機能になります) として書き直し、コンパイルしてモジュールとして使用できます。

3 番目のオプションはよりグローバルです。PHP のことは忘れて、すべてを書き直します。一般に、このオプションには存続する権利がありますが、それは十分な PHP コードがない場合に限られます。大規模なプロジェクト (またはかなり長期間存在するプロジェクト) では、通常、その多くが蓄積され、すべてを書き直すには長い時間がかかります。ビジネス要件により、これを行うことはできません。一般に、PHP は単純な言語であるため、フロントエンドサーバーなどで何かを記述するのにそれほど時間はかかりません。これにより、低レベル言語では時間がかかる作業をすばやく実行できるようになります。

最近普及してきた代替オプションとして、PHP をどこかでコンパイルして、より高速なものを作成するという方法があります。

何かコンパイルしましょうか？

「コンパイル」という言葉は、PHP スクリプトコードを別のもの、別のコードに変換することを意味します。

この場合、2 つのタイプが考えられます。

ネイティブコードは、物理マシン上で実行できる一種のバイナリファイルです。

非ネイティブコード。別の仮想マシン (JVM など) で実行できるバイトコードをコンパイルできます。

PHP からネイティブコードをコンパイルするにはどうすればよいでしょうか?

ロードセンドコンパイラ。その続編が『レイヴン』です。 PHC (これは PHP オープンソースコンパイラーです) もあります。最近ではHipHop（Facebook）も登場しています。

非ネイティブコードに対して何ができるかを簡単に説明します。私の知る限り、作業オプションは 3 つあります。これは、Java のバイトコード生成と .Net: Quercus、Project Zero、Phalanger のバイトコード生成です。非ネイティブコードは使用しないため、コンパイルは考慮しません。ネイティブコードへのコンパイルに戻りましょう。

私の意見では、最も古いコンパイラは Roadsend です。開発はかなり昔、2002 年に始まりました。元々は商用アプリケーションでした。それはクローズされましたが、2007 年にのみオープンソースとしてリリースされました。非常に複雑なコンパイルスキームがあります。特定の Bigloo コンパイラーが Scheme 言語に使用され、その後ネイティブコードが生成されます。このコンパイラは Zend Engine を使用しません。

個別の実行可能バイナリを生成することも、Apache 用のモジュールを生成することもできます。 Web サーバーとして動作するバイナリを生成することもできます。しかし、うまくいきません。理由は分かりませんが、私にはまったく効果がありません。

私の知る限り、Roadsend に関する作業は現在進行中ではありません。それは Raven プロジェクトに発展し、完全に C++ で書き直されました。コンパイラとして、LLVM を使用してコードを生成します。

現時点では、すべてが非常に有望に見えます。

しかし、まだ建設中です。ドキュメントにも、バイナリを生成しないというヒントがあります。待って。

PHC がなかったら悲しいことになるでしょう。これはオープンソースのコンパイラです。 2005 年から開発されています。欠点の 1 つは、組み込みの SAPI を使用することです。私たちは Java マシンである Zend Engine を放棄するわけではありません。基本的に、PHP コードを PHP 拡張モジュールコードに変換します。その後、コンパイルが行われますが、実行プロセスにはやはり Zend エンジンが関与します。

PHCの使用例

たとえば、従来のコンパイラ gcc での作業方法と非常によく似ています。最初のものは、バイナリが 1 つあることを示しています。単純に C コードを生成することもできます。このコードを生成した後、内部では同じ gcc が使用されるため、最適化などを目的としたフラグを使用できます。

コマンドラインで実行されるアプリケーションについて話していました。

Web アプリケーションを起動するには、いくつかの手順を実行する必要があり、非常に複雑です。まず拡張機能を生成し、次にコードをコンパイルし、それを何らかの方法で (動的または静的に) 接続する必要があります。

PHC の主な利点

基本的に同じ PHP を使用しており、完全な互換性があります。他のすべての拡張子はサポートされています。私たちはコンパイルしたものをすべて使用します。かなり良いドキュメントです。

ちなみに、PHC の追加の利点の 1 つは、XML の構築方法に基づいてスクリプトの XML 作業を生成できることです。これは場合によっては便利です。

短所

私の意見では、これは依然として Zend Engine への依存関係があるため、劣ったバイナリです。 Web プロジェクトの接続に関しても、多少の複雑さがあります。

主なものについて

Facebook のソリューションである HipHop が登場しなければ、おそらくこの報道は行われなかったでしょう。その作成者も大量の PHP コードを蓄積しており、それをどうするかを長い間考えていました。

私の理解では、すべてを書き換えるオプションが拒否された後、ある種のトランスレーター (この場合は C++ コードに) を作成することが決定されました。このプロジェクトは比較的若いもので、正式にリリースされたのは今年の 2 月です。 PHP コードは C++ コードに変換され、オペレーティングシステムの標準ツールを使用して生成されます。ただし、現時点では Linux オペレーティングシステムのみがサポートされています。

ちょうど昨日、私はフェイスブックの担当者にこの決定について尋ねました。同氏は、現在、PHP コードの 100% が HipHop を通じてコンパイルされていると述べました。コードは、PHP インタープリターを介した純粋な形式では機能しません。繰り返しになりますが、作成者はプロセッサ負荷の大幅な削減を発表しました。

ヒップホップの基本機能

バイナリ自体を直接生成し、コマンドラインで実行できます。ストリーミング Web サーバーとして起動するためのオプションがあります。別の組み込みデバッガもあります。ローカルとリモートの両方でスクリプトをデバッグできます (サーバーとして機能します)。

組み立てプロセスは非常に簡単ではありません。説明はありますが、どこにでもまとまっているわけではありません。現時点では、前述したように、すべてが Linux 用に組み立てられており、さらに当初はすべてが 64 ビット用に「調整」されていました。ただし、32 ビットは現在実験的にサポートされています。しかし、なんとかアセンブルして少しパッチを適用することができました。デフォルトではアセンブルされていないため、一般的にはこれですべてが完了しました。

さらに、彼らは独自のバージョンの libcore を持っており、私の意見では、パッチを適用する必要があるライブラリもいくつかあります。一般に、組み立てプロセスはそれほど単純ではありません。

アセンブリ後の出力では、PHP コードを C++ に変換する特定の hphp ファイルを受け取ります。国旗を見てみると、たくさんの国旗があります。ここでは、必要になる可能性のある基本的なものをいくつか取り上げました。

HDF 形式のファイルを設定ファイル (config) として使用し、さまざまなディレクティブを指定できます。そこでエラーレベルやその他のものを設定できます (HDF は構造化された形式で利用できるものすべてです)。構成自体をデータベースから取得したり、コマンドラインで直接使用したりすることもできます。

コンパイル中にログレベルを設定します。すべてのエラーを表示するか、警告や追加情報も表示するか、通常は発生したすべての完全なログを保存します。

非常に便利なディレクティブは input_list=FILE で、コンパイルするスクリプトのリストを指定できます。また、lazy-bind などのディレクティブについても言及する価値があります。すべてのプロジェクトファイル (コンパイルされるファイル) を指定できます。

PHPスクリプトのコンパイル実行例

3 番目のレベルのログがインストールされており、時間に関する非常に一般的な情報があり、どれくらいの時間がかかったかがわかります。実際、スクリプトは非常に単純です。いつもの「Hello, World」です、スクリーンショットを撮りました。

最も重いファイルは「プログラム」バイナリで、そのサイズは 28 MB です。基本的に、「Hello, World」の重さは 28 MB です。このバイナリには、標準的な行「Echo "Hello, World!"」に加えて、さらに多くの機能が含まれていることに注意してください。これは、本格的な Web サーバー、つまり管理用の本格的なサーバーです。

私たちは何をしているのでしょうか？

C++ には「Hello…」があり、「echo "Hello, World"」という 1 行で構成される関数が実行されます。さらに、多くのサードパーティ製ファイルがロードされていることがわかります。 C++で。

これが結果として得られるプログラムです。さまざまな構成に対応するさまざまなキーがすでに多数含まれていますが、そのうちのいくつかについてのみ説明します。

これは --mode です。これはプログラムの起動モードです。直接 (コマンドラインから) 実行することも、Web サーバーまたは本格的なデーモンモードで実行することもできます。他にもいくつかのオプションがありますが、それらは重要ではありません。

config も同じ形式で使用されます。指示は多いので指示しませんでした。 HipHop にはドキュメントが付属しています。これは Wiki サイトにはありませんが、ディストリビューションに付属のドキュメントが提供されており、そこにすべてが明確に説明されています。これほど詳細な説明が記載されるとは予想していませんでした。これにより、ソリューションを非常に柔軟に構成できるようになります。

サーバーモードで実行するには、ポートを指定できます。管理には別のポートが使用され、サーバーの管理を可能にするいくつかのリクエストを送信できます。デバッグサーバーを実行している場合は、デバッグのために「バインド」するホストとポートを指定します。

起動例

たとえば、ブロードキャスト用にポート 9999 を指定した場合、単純な http リクエストを実行することで、統計を受信したり、何らかの方法でサーバーを管理したり、追加情報を取得したりできます。一般的に、それは非常に便利です。

ステータス情報を取得するオプション

各種組み込みフォーマット(xml、json、html)で設定されたサーバーステータスを受信することが可能です。基本的に、サーバーマスタープロセス自体とハンドラー (要求を処理するスレッド) に関する情報が提供されます。

追加の統計

実際、多くの統計が提供されています。 HipHop は memcache および MySQL 形式の SQL とネイティブに連携するため、HipHop で実行されるすべての操作に関する詳細情報が提供されます。

完全なメモリ統計

ここにはアプリケーション統計という非常に便利な機能があります。 PHP で HipHop 自体の追加機能を使用すると、スクリプトに統計を書き込むことができ、その後、http への定期的なアクセスを通じて統計を受け取ります。

デバッグ

すでに述べたように、組み込みの「デバッグ」を使用してスクリプトをデバッグすることができます。 hphpi インタープリターは私たちがコンパイルしたものと同様に動作するため、これは非常に便利です。スクリプトを標準の PHP で実行するときと、コンパイルされたデータを使用するときのスクリプトの「動作」には違いがあります。コンパイルされたものをデバッグするために、Facebook は別のインタープリターを作成しました。

最初のケースでは、「-f」スイッチを使用してコードを実行し、ファイルがどのように動作するかを確認します。すべての出力は標準出力に送られます。または、デバッグモードで実行し、対話型デバッガーを起動することもできます。これは標準の GDB と非常に似ており、ブレークポイントの設定、実行、変数値の入力、追跡なども行うことができます。

追加機能の 1 つ

コンパイル後に判明したプログラムがあります。 RPCサーバーとしても利用可能です。 http 経由でリクエストを実行し、params 関数を呼び出すことで、パラメーターを json 配列または別個のパラメーターとして渡すことができます。これらの関数の結果を返す json が返されます。これは非常に便利です。必要な機能が最初から組み込まれています。

ヒップホップの短所

現時点では、HipHop は、eval()、create_function()、/e を使用した preg_replace() などの言語構造と関数をサポートしていませんが、これらはすべて eval() に似ています。ただし、私の意見では、最新のリリースでは、構成経由で eval() を有効にすることができます。しかし、これを行うことはお勧めできません。一般に、eval() の使用は良くありません。

ヒップホップの主な利点

もちろん、最大の利点は Facebook からのサポートです。それは機能しており、非常に活発に開発されています。このプロジェクトを中心に開発者のコミュニティが誕生しています。まったく新しい PHP 実装が作成されました。

すでに述べたように、利点はネイティブコードが生成されることです。プロセッサの負荷コストを削減することでパフォーマンスが向上すると主張されています (テストでこれが確認されています)。

構成は非常に柔軟です。カスタマイズのオプションがかなりたくさんあることに嬉しい驚きを感じました。これはプロジェクトが実際に機能しているからだと思います。使用されたものはすべてインクリメントされます。

すでに述べたように、HipHop は非常に多くの追加機能を提供します。これらには、RPC サーバー、管理、さまざまな統計などとしての使用が含まれます。ちなみに、他の言語と連携するための API もあります。

このソリューションに関しては、非常に優れたドキュメントが作成されています。もう 1 つの利点: これは、運用環境で実際に使用できるソリューションです (例: Facebook)。

短所

主な欠点は、現時点ではサポートされるモジュールの数がかなり限られていることです。たとえば、データベースを操作する場合、MySQL を操作するための関数のみを使用できます。ここでは PostgreSQL はサポートされていません。

すでに述べたように、組み立ての複雑さもあります。 32 ビットシステム上での構築には問題があります。しかし、これはすぐに修正されると思います。現時点では、PHP 5.2 からのコンパイルのみが使用されます。バージョン 5.3 はまだサポートされていませんが、約束どおりサポートされる予定です。

コンピレーション全般、特にヒップホップに期待してはいけないことは何ですか?

コンパイルによってデータベース内の遅い SQL クエリが高速化されることはありません。ボトルネックがデータベースである場合は、データベースをコンパイルしてもコンパイルしなくても、何の効果もありません。

コンパイルでは静的読み込みは高速化されず、動的読み込みのみが高速化されます。デバッグがはるかに困難になります。おそらく多くの人は、PHP ではすべてのデバッグが非常に簡単であるという事実に慣れているでしょう。これはコンパイル中に発生しなくなりました。前述したように、Facebook はこのプロセスを可能な限り簡単にしていますが、それがなければ毎回コンパイルするのはさらに困難になります。

これがすべての問題を解決するある種の「特効薬」であると期待しないでください。実際、コンパイルはかなり狭い範囲の問題を解決します。そうであれば、これが役に立つかもしれません。

コンパイルはどのような問題を解決しますか?

PHP や大量のリクエストを積極的に処理する場合、CPU の負荷が大幅に増加するため、CPU の負荷が軽減されます。もちろん、いくつかのテストを実施したいと思います。

テスト

最初のテスト (最も単純な) は、完了までにかなりの時間がかかる、かなり高価な操作です。テストでは、自分自身を抽象化して、外部リソースを使用してリクエストを作成しないようにしました。

負荷は完全にプロセッサにかかります。テストの結果、HipHop が誰に対しても「勝った」ことがわかりました。標準の PHP コンパイラーよりもほぼ 1.5 倍高速に動作します。 PHC はこのテストに非常にゆっくりと合格しました。

2 番目のパフォーマンステストでは、SVN からダウンロードできる公式 PHP スクリプトを使用しました。これは、並べ替え、代入、合計など、数学的な観点から非常に高価な操作を実行する多くの関数を実行します。

ヒップホップが再び先を行っていた。また、標準的なPHPでは約3倍の時間差があります。ここでは PHC のパフォーマンスが良かったが、ヒップホップの約半分の悪さでした。

PHP は主に http リクエストを処理するスレッドに使用されます。これは覚えておく価値があります。

いくつかの標準構成 (PHP を使用した Apache、fpm-php を使用した Nginx、およびコードキャッシュ用のプラグイン APC)。 5 番目のオプションとして、ヒップホップがあります。

正直に言うと、私はサーバーではなくラップトップでテストを実施しました。もちろん、数値は現実と完全に一致していない可能性がありますが、この場合、結果は正常です。負荷が増加すると、リクエストの数とリクエストの合計数も同時に増加することに注意してください。次にRPSです。 10 個の単純なインクルージョンを含む標準ページをテストしました。基本的に、これは PHP をインタープリターとしてテストします。

聴衆からの質問:セル内の数字は何秒ですか?

アレクセイ・ロマネンコ：これがfpsです。

ここで、同時リクエストの数が増加するにつれて、HipHop は非常に適切に動作すると結論付けることができます。

APC を使用することが標準的な方法であることがわかります。たとえば、Apache としてパフォーマンスが約 2 倍向上することがわかります。これはNginxでも起こります。しかし、Nginx が遅いという事実は、このパッケージの方が悪いという意味ではありません。まさに具体的なテスト。ここで実際にテストすると、Apache は遅いリクエストで「停止」します。

おそらく、これが必要かどうかを理解したいと考えています。

コンパイルについていつ考えるべきでしょうか?

おそらく、これが必要になるのは、ボトルネックが CPU であることがわかった場合です。 PHP を標準インタープリターとして使用する CPU に制約がある場合は、プロジェクトの一部をコンパイルできる可能性があることを検討する価値があるでしょう。

アプリケーションの実行に自律性が必要な場合には、この方法が適さない可能性があります。

サーバーの数を減らす。サーバーの数が多い場合、生産性を 2 倍にすることで、大まかに言うと台数も半分になります。サーバーが 1 台の場合は意味がありませんが、サーバーが 100 ～ 200 台ある場合はおそらく意味があります。

Facebook が HipHop を使用し始めた主な理由は、書き換える方法がない (または書き換える方法が存在しないか、単に高価である) 大量の PHP コードが存在することです。生産性が 2 倍向上するのはすでに良いことです。

おそらくすべてです。質問をお待ちしています。

質疑応答

聴衆からの質問:こんにちは。 Facebook以外にもHiphopの導入で成功した例があれば教えてください。たとえば、RBC Web サイトを HipHop に転送しますか? アレクセイ・ロマネンコ： 2番目から始めます。 RBC のウェブサイトは翻訳が難しいです。導入の成功について。 PHP Unit を自分でコンパイルしたところ、正常にコンパイルされました。また、私の知る限り、PHP Bunty ボードは正常にコンパイルされます。実際、多くの組織がすでにコンパイルを使用しています。今後のテストにより、このプロジェクトの使用がどれほど正当であるかが明らかになるでしょう。 聴衆からの質問:それを使用している組織の例を挙げていただけますか? アレクセイ・ロマネンコ：正直に言うと、今は言えませんが、ここは西洋です。私の知る限り、ここでは誰もそれを使用していません。 聴衆からの質問:あなたが言及した一部の機能がサポートされていないこと以外に、実行時の違いは何ですか。「ライブ」プロジェクトを翻訳することはどのくらい危険ですか? アレクセイ・ロマネンコ：違いは、コンパイルされたプログラムはクラッシュする可能性があることです。おそらく、まだ特定されていない問題がいくつか現れるでしょう。実際、PHP 自体の「動作」には多くの違いがあります。詳細な情報はドキュメントに記載されているため、これらは含めませんでした。 Facebook チームは独自のインタプリタを作成しました。これは実際、コンパイルされた形式で動作するインタプリタと 99.9% 同等です。コードをテストするときは、標準の PHP インタープリターではなく、前述したように PHP 用の hphpi を使用することをお勧めします。