2 つの Python Web フレームワーク: Django と Tornado の比較

さまざまな言語プラットフォームの中で、おそらく Python が最も多くの Web フレームワークを生み出しています。その理由は、Python でフレームワークを構築するのが非常に簡単であるため、常に車輪が発明されているからだと思います。

ここでは、私が学んだ 2 つの py Web フレームワークについて説明します。他の人の参考になれば幸いです。

Django

Django は最も有名な py フレームワークであるはずで、Erlang にも影響を受けるフレームワークがあります。

Django は、大規模で包括的な方向を向いています。完全に自動化された管理バックエンドで最も有名です。ORM を使用して簡単なオブジェクト定義を行うだけで、データベース構造とフル機能のデータベースを自動的に生成できます。 . 経営背景。

Django によって提供される利便性は、Django の組み込み ORM がフレームワーク内の他のモジュールと高度に結合されていることも意味します。

アプリケーションは Django の組み込み ORM を使用する必要があります。そうしないと、フレームワークで提供されるさまざまな ORM ベースの利便性を享受できなくなります。理論的には、その ORM モジュールを切り替えることができますが、これは次のことと同等です。装飾された家を改修する 解体して改修するには、最初からラフな部屋に行って新しい装飾を行う方が良いです。

Django のセールスポイントは非常に高い開発効率ですが、パフォーマンスの拡張には限界があり、トラフィックが一定の規模に達した後、パフォーマンス要件を満たすために Django を使用するプロジェクトを再構築する必要があります。

この分野の経験については、http://www.slideshare.net/zeeg/djangocon-2010-scaling-disqus

Ruby の Rails にも同様の問題があります。たとえば、push 今日の規模では、Rails は言うまでもなく、Ruby ですら放棄して最初からやり直す必要があります。

私の意見では、Django は中小規模の Web サイト、または大規模な Web サイトが製品のプロトタイプを迅速に実装するためのツールとして適しています。

製品を迅速にリリースすることが重要です:

信じられないかもしれませんが、より大きな問題はスケーリングではなく、最初の問題がなければ 2 番目の問題は発生しません。 http://gettingreal.37signals.com/ch04_Scale_Later.php

====== Django テンプレート=====

Django のテンプレート システム設計は非常に興味深いものであり、最も影響力があり、最も影響力のあるものになるはずです。そのフレームワーク部分では物議を醸しています。

Django テンプレートの設計理念は、コードとスタイルを完全に分離することです。asp.net はコードとテンプレートを分離することを推奨していますが、技術的には依然として混合することができますが、Django はテンプレート内のコーディングとスタイルを根本的に排除します。 。

たとえば、asp.net テンプレートでは次のように記述できます:

int i;

for(i==0;i

....

}

%>

Django は上記のようなコードの埋め込みをまったくサポートしておらず、テンプレートに組み込まれた関数のみを使用できます。これにより、実際にはテンプレート用の「新しい言語」が構築されます。 new Language」は非常にシンプルなので、そのテンプレートをさまざまなプラットフォームに移植できます。

ほとんどの場合、Django のテンプレート機能で十分ですが、特別な状況 (「特別」がそれほど特別ではない場合もあります) では、テンプレートにコードを埋め込む必要があり、そのテンプレート システムのルールに従って埋め込む必要があります。テンプレートの展開を行います。場合によっては、テンプレートに直接 1 行のコードを記述することで解決できる問題が、テンプレート拡張機能を使用して実装すると数十行以上のコードになる場合があります。

テンプレートでのプログラミングが許容されるかどうかは、Django テンプレートの最も物議を醸す側面です。

Tornado

Tornado ( http://www.tornadoweb.org ) は、Facebook のオープンソース フレームワークであり、その哲学は Django のほぼ対極にあります。

Tornado は、より正確ではありますが、テンプレート機能も提供します。推奨されていませんが、作成者はテンプレートに少量のコーディングを許可できます (py コードを 1 行直接埋め込みます)。 。

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

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

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

高いパフォーマンスが要求されるため、フレームワークの各部分をカスタマイズする必要があることが多く、Django で開発された Web サイトでは各部分を再利用できるモジュールがほとんどないとします。継続的にカスタマイズされており、Django フレームワークの残りの部分は、おそらく tornado が最初に提供できるものです。

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

====== HTTP サーバー =====

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

フロントエンドは、apache/lighttpd/nginx などを追加しなくてもブラウザからアクセスできますが、HTTP 1.1 プロトコルを完全には実装していないため、公式ドキュメントではユーザーにフロントで nginx を使用することを推奨しています。実稼働環境で終了し、バックエンドは複数の Tornado インスタンスへのプロキシになります。

Tornado 自体は、デフォルトで起動されると、マルチコア CPU を最大限に活用して複数のインスタンスを実行します。

===== シングルスレッド非同期 =====

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

データベース クエリは本質的にリモート ネットワーク呼び出しであり、理想的にはこれらの操作は非同期としてカプセル化されますが、Tornado はこれをサポートしません。

これは Tornado の **デザイン** であり、欠陥ではありません。

システムが高トラフィックに対応するには、データベースのクエリ速度の問題を解決する必要があります。

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

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

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

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

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

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