PHPプログラマーの目を通したPython Web開発

はじめに

この記事では、Web開発にPythonを使用することとPHPでPythonを使用することの違いについて質問します。 この記事がホリバーにつながらないことを願っています。これは、どちらの言語が良いか悪いかではなく、Pythonの技術的特徴のみに関するものだからです。

言語自体について少し

PHPは、（言葉の意味で） 死ぬように設計されたWeb指向の言語です 。 低レベルの観点から見ると、PHPアプリケーションは、おそらく単一のセマンティックエントリポイントを持つ個別のスクリプトのコレクションに似ています。



Pythonは汎用プログラミング言語であり、Webでも使用できます。 技術的な観点から見ると、Python Webアプリケーションはメモリにロードされた完全なアプリケーションであり、リクエストごとに内部状態が保存されます。



上記の機能に基づいて、Webアプリケーションでのエラー処理の違いも続きます。 PHPには、エラーの種類（エラー、例外）全体の動物園があり、それぞれを傍受することはできませんが、1つのリクエストが処理されている限りアプリケーションは存続するため、これ（傍受の不可能性）は実際には重要ではありません。 キャッチされないエラーは、単にハンドラーから早期に終了し、メモリからアプリケーションを削除するだけです。 新しいリクエストは、新しい「クリーン」アプリケーションによって処理されます。 Pythonでは、アプリケーションは常にメモリ内にあり、「再起動」せずに多くのリクエストを処理します。 したがって、アプリケーションの正しい予測可能な状態を維持することが重要です。 すべてのエラーは標準の例外メカニズムを使用し、キャッチできます（SyntaxErrorの例外を除く）。 不明なエラーが発生すると、アプリケーションが終了し、外部から再起動する必要があります。



Web用にPHPとPythonを「調理」する方法はたくさんあります。 次に、私が最もよく知っている2つ（最も人気があるようです） -PHP + FastCGI （ php-fpm ）とPython + WSGI （ uWSGI ）に焦点​​を当てます。 もちろん、これらの両方のバンドルの前にフロントエンドサーバー（たとえば、Nginx）が想定されています。

Pythonマルチスレッドサポート

アプリケーションサーバー（uWSGIなど）を起動すると、Pythonインタープリターがメモリに読み込まれ、Webアプリケーション自体が読み込まれます。 通常、アプリケーションブートストラップモジュールは必要なモジュールをインポートし、初期化呼び出しを行い、最終的にWSGI仕様に準拠した準備済みの呼び出し可能オブジェクトをエクスポートします。 ご存じのとおり、Pythonモジュールを初めてインポートすると、作成されて値で初期化される変数を含む、モジュール内のコードが実行されます。 2つの連続したHTTP要求の間では、インタープリターの状態はリセットされないため、モジュールレベルのすべての変数の値が保存されます。



上記を例で明確に示す最も単純なWSGIアプリケーションを作成しましょう。

n = 0 def app(env, start_response): global n n += 1 response = "%.6d" % n start_response('200 OK', [('Content-Type', 'text/plain')]) return [bytes(response, 'utf-8')]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、 nはモジュール変数であり、次のコマンドを使用してアプリケーションをメモリにロードすると、値0で作成されます。

 uwsgi --socket 127.0.0.1:8080 --protocol http --single-interpreter --processes 1 -w app:app
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーション自体は、ページに変数nの値を表示するだけです。 入念なPHPプログラマーにとっては、ページに「000001」という行を「毎回」表示する必要があるため、意味がありません。



テストしてみましょう：

 ab -n 500 -c 50 http://127.0.0.1:8080/ curl http://127.0.0.1:8080
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、行"000501"を取得します。これは、アプリケーションがuwsgiメモリにロードされ、リクエスト間でその状態を保持しているという主張を確認します。



--processes 2パラメーターを指定してuWSGIを実行し、同じテストを実行すると、curlを何度か呼び出すと、2つの異なる昇順シーケンスが既にあることがわかります。 abは500個のリクエストを送信するため、それらの約半分は1つのuWSGIプロセスに、残りは2番目のuWSGIプロセスに分類されます。 curlによって返される期待値は、およそ"000220"および"000280"です。 Pythonインタプリタは、明らかにプロセスごとに1つであり、2つの独立した環境とリクエストの実際の並列処理（マルチコアプロセッサの場合）があります。



Pythonは、言語の一部としてスレッドをサポートしています。 従来の実装（CPython）はネイティブOSスレッドを使用しますが、 GILがあります-一度に実行されるスレッドは1つだけです。 この場合、n + = 1でさえアトミック操作ではないため、競合状態の問題が依然として発生する可能性があります。





HTTPリクエストハンドラのコードにIOの期待がないときにスレッドの数を増やしても、処理は高速になりません（ただし、スレッドはコンテキストを切り替えることで「プッシュ」できるため、速度が低下します）。 GILの制限により、スレッドは実際の並列処理を作成しませんが、グリーンスレッドではなく、実際のOSスレッドです。



別のテストを行ってみましょう。 1つのプロセスでuwsgiを実行しますが、その中に10個のハンドラースレッドがあります。

 uwsgi --socket 127.0.0.1:8080 --protocol http --single-interpreter --processes 1 --threads 10 -w app:app
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ab 5000アプリケーションリクエストを実行します。

 ab -n 5000 -c 50 http://127.0.0.1:8080/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

後続のcurlクエリ127.0.0.1：8080は、値が5000以下の昇順シーケンスが1つしかないことを示します（競合状態の場合は5000未満になります）。

アプリケーションアーキテクチャに対する言語の影響

各HTTP要求は個別のスレッドで処理されます（プロセスには少なくとも1つのスレッドがあるため、プロセスについても同様です）。 同時に、各スレッドは、そのライフタイム（理想的な条件下ではuwsgiアプリケーション全体のライフタイムと一致する）の間、多くのHTTPリクエストを処理し、リクエストからリクエストへの状態（モジュールレベル変数の値）を保存します。 これは、PHPでHTTPリクエストを処理するためのモデルとの主な違いです。PHPでは、各リクエストには新しく初期化されたばかりの環境があり、毎回アプリケーションを再度ロードする必要があります。



大規模なPHP Webアプリケーションでの一般的なアプローチは、 Dependency Injection Containerを使用して、初期化とアプリケーションサービスレベルへのアクセスを制御することです。 良い例がPimpleです。 各HTTPリクエストの最初の手順は、コンテナ内の利用可能なすべてのサービスを登録する初期化コードを実行することです。 さらに、必要に応じて、コントローラーのサービスオブジェクト（遅延）にアクセスします。 各サービスは他のサービスに依存する場合があり、依存関係はサービス集合体の初期化コード内のコンテナを通じて再び解決されます。

 //   $container['session_storage'] = function ($c) { return new SessionStorage('SESSION_ID'); }; $container['session'] = function ($c) { return new Session($c['session_storage']); }; //   class MyController { public function __construct() { // get the session object $this->session = $container['session']; // "" ,    } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテナのおかげで、オブジェクトの1回限りの作成と、サービスへの後続の呼び出しごとに既製のオブジェクトを返すことができます（必要な場合）。 ただし、この魔法は単一のHTTP要求のフレームワーク内でのみ機能するため、サービスは要求固有の値で簡単に初期化できます。 多くの場合、このような値は、現在の承認済みユーザー、現在のユーザーのセッション、実際のHTTPリクエストなどです。リクエストの終了時にサービスは破棄され、次のリクエストの処理の開始時に新しいサービスが作成および初期化されます。 さらに、1つのHTTPリクエストの処理がスクリプトに割り当てられた制限に収まる場合、メモリリークについて実質的に心配することはできません。



上記のPythonストリームモデルを考慮すると、Python Webアプリケーションで同様のアプローチを使用することは、追加の努力なしでは不可能であることがわかります。 コンテナがモジュールレベルの変数（非常に論理的に見える）である場合、サービスは複数のHTTPリクエストを処理する複数のスレッド間の共有リソースであるため、含まれるすべてのサービスを現在のリクエストに固有の値で初期化できません。並行して。 一見、この問題に対処するには2つの方法があります：現在のHTTPリクエストから独立したサービスオブジェクトを作成する（サービスメソッドへの呼び出しは依存したままで、メソッドで使用されるスタック変数は共有リソースではありません）、またはコンテナをストリームリソースにするプロセス（各スレッドは独立した一連のサービスとのみ通信し、一度に1つのスレッドは1つのHTTP要求のみを処理できます）。



最初のアプローチのプラスのように思えます-サービスはuwsgiプロセスの存続期間中に一度だけ初期化されます。 また、メモリを節約することもできます（すべてのスレッドに対して1セットのサービスしかないため）。 一方、特定のHTTPリクエストを処理するには、利用可能なすべてのサービスの一部（ほとんどの場合は小さい）のサブセットのみが必要です。 アプリケーションが十分に大きく、印象的な数のサービスを持っている場合、一定数のHTTP要求を処理した後、サービスの大部分が初期化され、プロセスメモリに格納されます。 これは深刻な問題になりそうです。



2番目のアプローチは、 threading.localを使用して実装できます。 したがって、たとえば、フラスコが到着します。 アプローチを説明するために、いくつかのイベントにローカルストリームストレージを実装できます。

 class EventsStore: def __init__(self): self._store = threading.local() def add(self, event): self.get_all().append(event) def clear(self): if self.has(): del self._store.events def get_all(self): if not self.has(): self._store.events = [] return self._store.events def has(self): return hasattr(self._store, 'events') def pop_event(self): return self._store.events.pop() if self.has() and self._store.events else None
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同様に、 scoped_sessionはSQLAlchemyに実装されています。これにより、各スレッドのデータベースに一意の接続を確立できます。



2番目のアプローチを使用する場合、各リクエストの最後にコンテナを破棄し、新しいリクエストを処理する前に新しいコンテナを作成することにより、メモリの問題を回避できます。 これは、PHPリクエスト処理モデルに非常に似ています。 マイナス-新しいリクエストごとにコンテナとサービスが初期化されます（同じコードが常に実行されます）。 Pythonスレッドを利用しない。

おわりに

異なる言語-異なるアプローチ。 Pythonには独自の特性があり、それらを正しく使用する方法はまだ明確ではありません。 Pythonは、アプリケーションの状態とマルチスレッドのリクエスト処理を行う機能を提供しますが、潜在的な可能性のある競合状態（n + = 1でもアトミック操作ではないという事実に照らして）およびおそらくより複雑なアプリケーションアーキテクチャで支払う必要があります。 Python開発者がひげを生やしたWebアプリケーションをどのように構築しているか聞いてみたい。