先日、Zend Serverを調べていて、なぜこれを使用するのか疑問に思いました。OK、彼らはそれがすべてテストされ、ミッションクリティカルでエンタープライズ対応などだと言っています。しかし私にとっては、それはマーケティング部門が話しているだけです。
この製品を使用している人はいますか？もしそうなら、あなたはそれとあなたの経験を共有できますか、そして多分あなたはあなたのアプリケーションにこの製品を選ぶ理由について詳しく説明することができます。
Zendサーバーを使用することの本当のメリットはありましたか？
私はZendPlatformを使用していて（Zend Serverについて質問されていたので、そこに着きました）、ZendServerでも使用できるエラー報告ツールに非常に熱心に取り組んでいます。
エラーが発生したり例外がスローされたりすると、Zend Serverは可能な限り多くの情報を保存します（たとえば、使用されていた要求パラメーター、エラーが発生した場所、時間、エラーメッセージ、スタックトレースなど）。また、スクリプトの実行が遅いことが報告されています。
「サイトが機能していません。修正してください」などのエラーメッセージを顧客よりも受け取る方が本当に好きです。
ZendServerをZendStudioと組み合わせて使用する場合、Zend Debuggerがすでにプリインストールされているのは非常に便利です（ただし、自分でインストールすることもできます）。
また、php-java-bridge（JavaクラスはPHPで使用できます）が付属していますが、これは必要ありませんでした。
Webアプリケーションにphpベースのエラー報告ソリューションがすでにある場合、またはこれやJavaブリッジを使用していない場合は、ZendServerを自分で使用している場合は実際には違いはないと思います。 apacheのインストール（正しく構成する方法を知っている限り）。
少なくともそれは私の意見/経験です。
私は無料のZendPlatformのDeveloperEditionを使用しています。Zend Platform / Serverの料金を支払わなければならないとしたら、それを使用することはないと思います。しかし、それは本当にプロジェクトに依存します。
Zend Serverは、テストおよびサポートされているスタックを持っているだけではありません。Andreは、ZendServerの機能の1つである監視について触れました。監視は、特定の条件についてPHPスクリプトの実行を監視し、特定のしきい値を超えると、その要求のコンテキストが記録され、後で調べることができます。アプリケーションの問題を抱えている顧客とオンサイトで作業する場合、最初に行うことは、ZendServerをインストールして監視をオンにすることです。数分以内に、私は通常、彼らの問題が何であるかについて少なくともかなり良い理論を持っています。
Zend Server 5では、リクエストの過程で行われたほぼすべての個々の関数/メソッド呼び出しの実行時インストルメンテーションを実行するコードトレース機能の導入により、はるかに高度になりました。これは、実行時に実行されるデバッグとプロファイリングの組み合わせのようなものです。多くの場合、実際に問題を再現することなく、実稼働環境で問題を診断することができます。
他にも使用できる機能がいくつかあります。ジョブキューは私にとって大きなものであり、私はかなり広範囲に使用しています。Do you queue？での使用方法の例があります。ZendServerジョブキューの概要
また、2つの異なるキャッシュ機能があります。PHP-Javaブリッジ（Andreもほのめかしました）と、利用可能な最速のオペコードアクセラレータの1つであるOptimizer+です。
確かに、「テスト済み、認定済み」のビットは、一部の環境では優れています。私たちの場合、監査要件は、認定されたソフトウェアスタックを使用するか、独自に使用するが、それにフィードするすべての小さなコンポーネントに対して迅速な更新を行っていることを示す必要があることです。そのため、健全性を確保するために、これまでLinuxディストリビューションの標準製品を使用してきました。これに伴う問題は、彼らがカーブから何年も遅れる傾向があるということです。たとえば、ほとんどのディストリビューションは、5.1（！）に固執した後、最近PHP5.3を採用しました。これは、最新のコーディング手法を使用する最新のアプリケーションを開発しようとしている場合には受け入れられません。さらに、PHPのパフォーマンスと信頼性の点で1トンも諦めています。
そうは言っても、機能もかなりいいです。@Kevenはすでにジョブキューについて言及しています。非同期で実行されるあらゆる種類のタスクを非常に簡単にオフロードし、メインのリクエストプロセスを実行し続けることができるという点で、これは私たちにとって素晴らしいことです。例として、特定のタイプのイベントが発生するたびに、アプリケーションの1つがバグトラッカーにタスクを作成します。これはWebサービスによって実行され、バグトラッカーは非常に遅いため、これには数秒かかる場合があります。ただし、アプリケーションのユーザーを待たせるのではなく、ジョブをキューに入れてバックグラウンドで実行するだけです。同様に、標準の電子メールクラスは、コードがSMTPサーバーと通信している間、ユーザーを待機させるのではなく、ジョブキューを使用します。そして、それは、大きなレポートの生成、データベースの整合性チェックの実行、キャッシュの再構築などの有用性にさえ触れていません。
ページキャッシュは、ページ全体をキャッシュしてそれで済ませることができる場合に最適です。PHP独自のキャッシングコントロールよりも優れたコントロールがあるため、これをWSDLで使用します。同様に、ダウンロードサーバーは、画像などの特定の種類のコンテンツをキャッシュするのに最適です。また、ローカルmemcachedサーバーのようにデータキャッシュを使用して、低速ネットワーク上の別の場所にある低速データベースサーバーへのクエリを回避することで、あらゆる種類のリクエストを大幅に高速化します。
そしてもちろん、@Andréが言及しているように、そこには非常に優れたデバッグ、トレース、およびイベントレポート機能がいくつかあります。
展開とロールバックを実行するための優れた機能もいくつかあります。これらは、ビジネスクリティカルなアプリケーションで非常に重要です。いつか試してみるつもりですが、今のところ、ZSを使う前にまとめたツールを使っています。
これで、他のさまざまなツールを組み合わせることで、これらの機能のほとんど（特に、すべてのキャッシュビット）を取得できます。ただし、それらすべてを調査して学習し、すべてをインストールして連携させてから、何かが更新されたときに適切な統合テストを行うなど、すべてを維持する必要があります。それは多くの作業と時間です-私が個人的にコードを書くのに費やしたい時間です。
そうは言っても、欠点があります。一つには、物事は時々感じます...中途半端なおよび/または誤解されています。たとえば、存在しないアイテムをフェッチしようとすると、データキャッシュAPIはブール値のfalseを返します。また、フェッチせずにアイテムが存在するかどうかをチェックする機能はありません。これが何を意味するかを推測します。ブール値を安全に取得できないため、安全に格納することはできません。文書化が不十分なAPC互換性レイヤーが含まれていますが、APCから存在関数を使用しようとすると、未定義関数エラーが発生します。
別の例として、開発ステーションにMacを使用していますが、PHPサーバーソフトウェアに数千を投じるすべてのプロの開発者によって実行される傾向がある古代のハードウェアとの互換性に関する非常に誤った懸念から、Zendは出荷することを選択しましたMacバージョン（開発専用）は32ビットのみ。そのため、64ビットで他のすべての場所で実行される32ビットでアプリケーションを開発する必要があります。これにより、かなりの数のバグが発生し、アプリケーションの自動テストに失敗しました。これにより、開発、テスト、ステージング、QA、および本番環境全体で同一のソフトウェアスタックであるZSの主要な目的の1つが失われます。私は彼らにこれを変えるように話そうとしましたが、彼らはすぐに私を無視し始めました。
もう1つの大きな問題は、ジョブキューがHTTPリクエストを介してのみジョブを処理できることです。APIは、他のメソッド（はるかに賢明なコマンドライン呼び出しなど）を許可するように設定されていますが、機能するのはHTTPだけです。これにより、Webサーバー接続を、設計上長時間実行される傾向があるタスクと結び付ける必要があります。そのため、Webコンテキストから除外する必要があります。そして、それはあなたにフープを飛び越えて、ブラウザのURLにアクセスすることによって世界があなたの仕事を引き起こすことができないようにすることを強制します。それはただのばかげた決断です。
他の例としては、APIを介してZend Monitorに送信されるカスタムイベントの処理が不十分である、シェバンラインによってトリガーされたときにMacで中断するPHPバイナリのphp-cliラッパー、キャッシュ内のヘルスとパフォーマンスのレポートの完全な（完全な）欠如がありますツール（これはZS 6で変更されると言われていますが）、および恥ずかしいほど不完全なドキュメント。私は続けることができました...
さて、これらの欠点と、乗車に伴う無駄な時間とリソースは、明らかに私たちのメリットを上回っていませんが、私たちが費やしている金額については、間違いなくもっと期待しています。
コードトレースは、ZendSeverが提供する最高のツールです。
根本原因分析は開発者にとって時間の浪費です
問題の原因がわかっていれば、問題の修正は簡単です。ただし、問題の根本原因を見つけることは、テスト中に困難なことが多く、アプリケーションが本番環境で実行されている場合は非常に困難です。開発ラボでまったく同じ環境、アプリケーションの状態、および負荷を再現しようとすると、時間がかかり、エラーが発生しやすくなり、開発者は最も重要なタスクであるコードの記述から離れることになります。Zend Server 5は、コードトレースを特徴とすることにより、根本原因分析をまったく新しいレベルに引き上げます。
PHPアプリケーション用のフライトレコーダーコードトレースとは何ですか？
ブラックボックスのフライトレコーダーを考えてみてください。飛行機に問題が発生した場合、おそらく問題を「再現」したくないでしょう。これが、フライトレコーダーが、問題が発生した理由を理解するためにフライトアナリストが必要とする可能性のある完全なデータをキャプチャする理由です。
Zend Server Code Tracingは、PHPのフライトレコーダーのようなものです。
Zend Serverは、環境のセットアップに時間を費やして障害に至るまでのすべての手順を再現するのではなく、アプリケーションの完全な実行をリアルタイムで（本番環境またはテストラボで）キャプチャするため、すばやく見つけることができます。根本的な原因。
Zend Serverコードトレースは根本原因分析時間
を短縮しますZendServerコードトレースは、問題が検出されたときに自動的にアクティブ化されるか、最適化プロジェクト中などにユーザーが手動でアクティブ化します。ZendServerのコードトレースによって記録されるデータは次のとおりです。
Zend Server Webコンソールに表示されるトレースを使用すると、DVDのように、アプリケーションの実行履歴を表示し、問題のある1つの要求の足跡をたどって、根本的な原因をすばやく特定できます。
私は、大規模なIBMサーバー（IBMiシリーズ）で実行されるPHPアプリケーションで、COBOLを使用して20、30年ほど実行されている古いソフトウェアを使用して作業しています。つまり、基本的にZend Serverは、IBMiで動作する、または少なくともそれと同じくらい堅牢であると私が知っている唯一のPHPプラットフォームです。これらのシステムはミッションクリティカルです。基本的に、ほとんどの保険会社、銀行、株式、さらには学区でさえ、これらのタイプのシステムを実行しています。Zend Serverのようなものを実行できるので、それらの古いシステムを最新の方法で公開し、サービス指向アーキテクチャーを可能にするRESTAPIを構築するようなことを行うことができます。これは私が取り組んできたものであり、PHPCLIとデータをサードパーティにプッシュするZendJobQueueを利用するイベント駆動型システムでもあります。この場合、データを自社側からベンダー側に同期します。
IBMi上のZendServerは、静的リソース（CSS、イメージなど）用のnginxフロントエンドでセットアップされ、動的PHP用のFastCGIプロセスを使用するため、非常に強力なセットアップです。それは間違いなく近代化のための古いシステムを開きます。
Zend Serverを使用して、PHPのソフトウェアバージョンと、すべてのサーバーにわたるさまざまな拡張機能の管理を軽減することが、最大の利点であることがわかりました。
また、ユーザー入力と環境変数を使用して特定のPHP関数まで問題の原因を特定できると、特にトラフィックの多いサーバーでPHPエラーログをトローリングするよりもはるかに役立ちます。
それに代わるオープンソースがあれば、私はそれについて知りたいです！Zendが無料版を廃止したことにはあまり満足していません。