最近、Avito PHPプロジェクトはPHP 7.1に切り替わりました。 この機会に、私たちとOLXの同僚とでPHP 7.0への移行がどのように行われたかを思い出すことにしました。 過去の例ですが、世界に見せたい美しいグラフィックがありました。

ストーリーの最初の部分は、 死んでいないPHPの記事に基づいています！ OLXŁukaszSzymański （Lukasz Szymanski）の同僚によって書かれたPHP7の実践 ：OLXからPHP 7への移行

パート1. OLXのPHP 7

OLX Europeは10のWebサイトを運営しており、そのうち最大のものはOLX.plです。 すべてのサイトは可能な限り効率的に動作する必要があるため、PHP 7への移行が最優先事項になりました。

この投稿では、PHP 7への移行で直面した問題と対処方法について説明します。移行については、PHPers Summit 2016カンファレンスで議論されました。

移行

私たちの不安に反して、移行はスムーズに進みました。 公式ドキュメントからの必要な変更の標準リストを除いて、私たちのアーキテクチャに関連するいくつかの変更を行うだけでした。

10のサイトが異なる国で運営されていることに言及する価値があります。 そして、変更を順番に展開します。次々にサイトで。 このアプローチは、大きな変更にとって特に重要です。

最小のサイトからバージョンの更新を開始し、より大きなサイトに移行して、テストが成功したことを確認しました。 これにより、予期しない問題の発生を監視し、潜在的な損傷を減らすことができました。

Memcache

PHP 7でのMemcacheサポートの放棄により、Memcachedへの移行が促されました。 サイトの2つのバージョンをサポートする必要がありました：PHP 5 + MemcacheおよびPHP 7 + Memcached。

この問題を解決するために、彼らは単純なラッパーを使用しました。 彼女は、コードが実行されているサーバーに関する情報に基づいて、キャッシュに接続するための適切なPHPモジュールを選択します。

<?php $factory = new CacheWrapperFactory(); $factory->createServer( extension_loaded('memcache') ? 'memcache' : 'memcached', $uri );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、Memcachedでの冒険はそこで終わりませんでした。 Memcacheを使用してシリアル化されたオブジェクトは、Memcachedを使用して逆シリアル化できないことが判明しました。

ただし、キャッシュはキャッシュであり、簡単に削除できます。 したがって、古い問題のあるオブジェクトをキャッシュから削除し、新しいモジュールを使用して再作成しました。

APC、APCu、およびOPCache

用語について少し。

APC（代替PHPキャッシュ）は、バイトコードとユーザーデータのキャッシュです。

APCu（APCユーザーキャッシュ）-ユーザーデータのキャッシュのみ。

OPCacheはバイトコードキャッシュのみです。

PHP 7にはAPCはありません。APCuとOPCacheの両方を使用する必要がありました。 以前は、キャッシュ管理フレームワークの多くの重要な部分でAPC APIを使用していたため、APC APIと互換性のあるapcu-bcモジュールをAPCuに固定しました。

結果

以下は、当社の最大のサイトであるOLX.plの結果です。

ApacheのCPU

Webサーバー（Apache）は、それぞれ32のプロセッサコアを備えた20台の物理マシンで実行されます。 移行の結果としてのピークプロセッサ消費は、50％から20％に減少しました。

ApacheのLA

同様に、Webサーバーの負荷平均も減少しました。

数値は、負荷を軽減し、リソースを節約し、効率を向上させることを表しています。 プロジェクトマネージャーまたはクライアントが移行に十分な時間を与えていない場合、これらのスケジュールで確実に納得できます。

PHP 7のパフォーマンスの理由

このような印象的な結果は、3つの主要な領域での最適化によって達成されました。

少ないメモリ割り当て操作

PHP 5は、メモリ割り当て操作でのみ消費するプロセッサ時間の20％を費やしました。 言語開発者はこれに注意を喚起し、メモリ割り当て操作の数を減らし、プロセッサの消費を大幅に減らしました。

少ないメモリ消費

このスケッチは、プロセッサがランダムアクセスメモリ（RAM）にアクセスするために必要なパスを示し、各ステップの時間を示しています。 ご覧のとおり、RAMへのセグメントは最長です。 PHP開発者は、アプリケーションの応答を高速化することでメモリ使用量を削減しました。

中間ポインターが少ない

PHP 7のパフォーマンスを改善する最後の理由は、中間ポインターの数の減少です。 これを行うために、PHP開発者は他のポインターを参照する多くのポインターを取り除きました。 代わりに、要求されたエンティティを直接参照するようにポインターを強制しました。

コード

パフォーマンスの向上に加えて、PHP 7はコード構造に小さな革命をもたらしました。

関数宣言のスカラー

PHP 7より前は、オブジェクト、インターフェイス、配列、または呼び出し可能な関数のみが関数の引数型になりました。 例として次のコードを取り上げます。

明らかに、そのようなメソッドの使用は、入ってくる引数の正確さがわからない場合、多くの問題を約束します。

各メソッドに型チェックを追加することに加えて、ドメイン指向プログラミング（DDD）のValueObjectコンストラクトを使用できます。

PHP 7では、string、int、float、boolなどのスカラーを簡単に指定できます。 さらに、戻り値のタイプを指定できます。

厳格モード

ただし、上記の構成をコードに追加するだけでは、期待した結果が得られない場合があります。 これは、PHP 7がデフォルトで強制モードで動作し、通常の型変換が行われるためです。 厳密モードを強制的にオンにしていない場合は、上記のメソッドを次のように書き換えることができます。

残念ながら、宣言構造（strict_types = 1）をPHPisNotDead.phpファイルに追加しても、厳格モードは含まれません。 以下の例の説明。 コメントは戻り値を示します。

なぜこれが起こっているのですか？ PHPisNotDeadクラスのメソッドでの厳密な型指定は、戻り値に対してのみ有効です。

引数の厳密な型指定も有効にする必要がある場合は、クラスメソッドが呼び出されるすべてのファイルにstrict_types宣言を追加する必要があります。

タイプの指定とプログラム実行への影響の詳細については、 ドキュメントを参照してください。 このドキュメントを読むことで、コードを実行する際の驚きを避けることができます。

未来

今でもPHP 7に切り替えることに決めていない場合は、 サポートされているPHPのバージョンのリストをご覧ください 。 バージョン5.6はアクティブなサポートを受けなくなり、2018年末には重大な脆弱性の修正でさえも公開されなくなります。 バージョン7.0以降のアクティブサポートは継続されます。

最新のPHPニュースと新しいリリースの計画をお楽しみに。 最も興味深い投稿： フレンドリークラス 、 ジェネリック型、関数 。 PHP RFCで他の言語開発の提案を見つけることができます。

まとめ

PHP 7は印象的です。効率の向上に加えて、開発者がより良いコードを書くのに役立ちます。 切り替えを決定するのに役立つ小さなマニュアルをスケッチしました。

-PHP 7にアップグレードする必要があるのはいつですか？

「今すぐ。」

パート2. AvitoのPHP 7

PHP 7.0への移行プロセス

OLXと同様に、サービスを徐々にPHP 7に翻訳しました。 まず、小規模なスタンドアロンサービスを転送してテストし、発生したエラーを修正しました。 次に、サイト管理サーバーの順次更新に進み、その後、残りのサービスとサイトをPHP 7にロールアウトしました。

移行の難しさ

後方互換性のない変更のリストを読みます 。 しかし、これはすべての病気を防ぐことはできませんでした。

古いコードには、Stringというクラスがありました。 PHP 7は、「予約されているため、クラス名として「String」を使用できません」というエラーをスローします。 クラスの名前が変更されました。 予約語のリストに注意してください 。

PHP 7では、SoapClientのWSDLスキームのキャッシュファイル形式が変更されました。 PHPのバージョンに応じてキャッシュを異なるディレクトリに保存するように設定するか、インタープリターのバージョンを変更する前にキャッシュを完全にクリアすることができます。

私たちが積極的に使用したmongo拡張モジュールは、新しいPHPではサポートされなくなりました。 代わりに、公式のMongoDB PHP Libraryを使用し始めました。 コード全体を見て、MongoCollection :: insert（）をMongoDB \ Collection :: insertOne（）に、MongoCollection :: remove（）をMongoDB \ Collection :: deleteMany（）に、さらにリストを下に置き換えました 。 たとえば、MongoDB \ BSON \ UTCDateTimeの代わりにMongoDateなど、新しいMongoDBドライバーからBSONを操作するためにクラスを使用し始めました。

結果

管理領域が優れています。

サイトのバックエンドも満足しています。

PHP 7.1へのアップグレード

PHP 7.1では、いくつかの非常に優れた革新が導入されました。戻り値のvoid型、反復可能、型付き戻り値にnullを返す機能、定数のスコープなどです。 さらに、PHP 7.0の積極的なサポート期間は今年の終わりに終了します。 PHP 7.1にアップグレードすることにしました。

驚き

すぐに更新すると、問題が発生しました。 7.1のphp-memcachedパッケージは、php-igbinaryパッケージをプルしました。 バトルサーバーの1つにPHP 7.1をインストールすると、他のサーバーからエラーが流れ始め、「igbinary」という単語が表示されました。

Memcacheの古くからの友人、シリアル化の違いですが、ソースは少し異なります。 php-memcachedモジュールはデフォルトでリストから最初に利用可能なシリアライザーを使用することが判明しました：igbinary（別のモジュール）、msgpack（別のモジュール）、php（別のモジュールを必要としない、常に利用可能）。 そして、igbinaryで7.1をインストールしたサーバーは、igbinaryによってシリアル化されたmemcacheにデータを書き始めました。 また、他のサーバーでは、このシリアライザーのサポートがなく、更新されたPHPを使用してサーバーによって書き込まれたデータを読み取ることができませんでした。 問題を特定し、他のすべてのサーバーにigbinaryをインストールすると、エラーが停止しました。

あとがき

PHP開発者は良いコースを取っています。 彼らは便利なツールを追加し、言語の遺産に関連する欠点を取り除き、パフォーマンスについて真剣に考えています。

先ほど、Avitoのサービスアーキテクチャへの移行について説明しました（ one 、 two ）。 このアーキテクチャにより、任意の言語で記述できます。ほとんどの場合、GoまたはPythonで新しいサービスを記述します。 ただし、PHPを放棄することに疑問の余地はありません。サイト（モノリス）のメインロジックはまだPHPであり、チームはそれを使用する方法を非常によく知っています。 インタープリターの新しいバージョンは、コードを改善し、その実行を高速化します。

PHP 7以降に切り替えた経験を共有してください。その過程で出会った発見とレーキについてお話しします。