一般的に使用されるいくつかの Python Web フレームワークについて深く理解する

Pylons を選択することは、おそらくその自由を選択していることを意味します:

· 悪夢を学習する Pylons は、Pylons が作成したものではない多くのサードパーティ ライブラリに依存しています。これらのライブラリの使用方法を学ぶために重要なのは、何を学びたいのかわからない場合があるということです。 Pylons の学習曲線は Django よりも相対的に高く、Pylons の以前の公式ドキュメントは批判の対象となっていましたが、幸いなことに、後に The Definitive Guide to Pylons という本が出版され、この状況は変わりました。このため、Pylons はかつては専門家のみに適した Python フレームワークとして知られていました。

· デバッグは悪夢です。多くのモジュールが関係しており、一度エラーが発生すると、問題を特定するのが困難です。あなたが書いたプログラムのせいかもしれないし、Pylons が間違っているかもしれないし、SQLAlchemy が間違っているかもしれないし、あるいは formencode にバグがあるかもしれません。とにかく、非常に厄介です。この問題は、それに精通している場合にのみ解決できます。

· Pylons をインストールするには、それぞれ独自のバージョン番号を持つ 20 個近くの Python モジュールをインストールする必要があり、どのモジュールでも互換性の問題が発生する可能性があります。難しい。これまでのところ、reddit の Pylons はまだ

antique バージョン 0.9.6 のままで、SQLAlchemy はまだバージョン 0.5.3 のままですが、これはこれと関係があるはずです。

Pylons と repoze.bfg の統合により、Django の地位に挑戦できる次のフレームワークが誕生する可能性があります。

Tornado ( http://www.tornadoweb.org ) は Facebook のオープンソース フレームワークであり、その哲学は Django の両極端に近いものです。 Tornado は Web サーバー (この記事では詳しく説明しません) であり、web.py に似たマイクロ フレームワークでもあります。 Tornado は、より正確ですが、テンプレート機能も提供します。推奨されていませんが、作成者はテンプレートに少量のコーディングを許可できます (py コードを 1 行直接埋め込みます)。

asp.net と比較すると、Tornado は少し似ていて、AsyncHttpHandler のみを実装しているため、すべてを自分で実装する必要があります。

実際には、テンプレート、国際化サポート、さらにはサードパーティのログインを容易にする組み込みの OAuth/OpenID モジュールがあり、実際には HTTP サーバーを直接実装しています。

しかし、ORM はなく (mysql の非常に単純なカプセル化だけ)、Django のような自動化されたバックエンドはおろか、セッションのサポートさえありません。

大規模な Web サイトでは、高いパフォーマンス要件の下で、フレームワークの各部分をカスタマイズする必要があることが多く、Django で開発された Web サイトの場合、各部分が継続的にカスタマイズされているとします。はい、これが最初に Tornado が提供できるものである可能性が非常に高いです。

異なる道は同じ目的地につながります。

Comet/バックエンドの非同期呼び出しを HTTP インターフェースに効率的に実装するために、Tornado は HTTP サーバーを直接埋め込みます。

フロントエンドは、apache/lighttpd/nginx などを追加しなくてもブラウザからアクセスできますが、HTTP 1.1 プロトコルを完全には実装していないため、公式ドキュメントではフロントエンドで nginx を使用することをユーザーに推奨しています。運用環境、および複数の Tornado インスタンスへのバックエンド リバース プロキシ。 Tornado 自体はシングルスレッドの非同期ネットワーク プログラムであり、デフォルトで起動すると、マルチコア CPU を最大限に活用して、CPU の数に応じて複数のインスタンスを実行します。

ウェブサイトは基本的にデータベース操作を行いますが、Tornado はシングルスレッドです。つまり、データベース クエリの戻りが遅すぎると、サーバーの応答全体がブロックされます。

データベース クエリは本質的にリモート ネットワーク呼び出しであり、理想的にはこれらの操作は非同期としてカプセル化されますが、Tornado はこれをサポートしていません。 システムが高トラフィックに対応するには、データベースのクエリ速度の問題を解決する必要があります。

データベースにクエリのパフォーマンスの問題がある場合、システム全体がどれほど最適化されていても、データベースがボトルネックとなり、システム全体の速度が低下します。

非同期は **本質的に** システムのパフォーマンスを向上させません。ネットワーク応答の不要な待機とスイッチング スレッドの CPU 消費を回避するだけです。

データベース クエリの応答が遅すぎる場合、解決する必要があるのは、データベースを呼び出すフロントエンド Web アプリケーションではなく、データベースのパフォーマンスの問題です。

リアルタイムで返されるデータ クエリの場合、理想的には、すべてのデータがメモリ内にあることを確認する必要があり、データベース ハード ディスク IO が 0 である必要があります。データベース クエリが十分に高速であれば、フロントエンド Web アプリケーションはデータを保存できません。クエリを非同期としてカプセル化する必要があります

。

コルーチンを使用する場合でも、非同期プログラムは常に同期プログラムの複雑さを増大させます。測定する必要があるのは、追加の複雑さに対処する価値があるかどうかです。

バックエンドにバイパスするには遅すぎるクエリがある場合、Tornado の提案は、これらのクエリをバックエンドで独立して HTTP インターフェイスにカプセル化し、Tornado の組み込み非同期 HTTP クライアントを使用してそれらを呼び出すことです。