asyncore.dispatcher を使用して HTTP クライアントを実行する「標準」またはよく知られているクラスはありますか?
私はそれを行うことができますが、車輪を再び発明したくない:)
1 に答える
2
簡単に言えば、いいえ、少なくとも使いたいものは何もありません。
ほとんどの人は、これasyncoreは に基づくイベント ループの記述方法に関する「サンプル コード」としてはある程度役立つと考えていselectますが、些細な複雑さを超える実際のプロジェクトのフレームワークとしては役に立ちません。
asyncore少なくとも 1 つの Webサーバーを含むの上に本格的なものを構築するプロジェクトが過去にいくつかありましたが、Webクライアントについては知りません。それは、そのようなものが存在しないという意味ではありません…しかし、私はそれがよく維持されたり、頻繁に使用されたりするとは思わないでしょう.
の上に高レベルのフレームワークを構築する代わりにasyncore、人々は主に新しいフレームワークをゼロから構築することに集中してきました。最も人気があるのはおそらくtwisted(アーキテクチャは と漠然と似ていますasyncoreが、はるかに強力で柔軟です) とgevent(これは非常に異なります。同期/マルチスレッド スタイルでコードを記述でき、グリーンレットを介してシングル スレッドで魔法のように実行されます) です。イベントループ)。
一方、Guido とその友人たちは、おそらく3.4 で登場し、 .tulipasyncore
したがって、選択肢は次のとおりです。
httplibとから自分で構築しますasyncore。- 古い、部分的に完成した実装を検索して完成させます。
twisted、gevent、tulipなどを使用します。pycurl(またはラップする他のライブラリlibcurlとそのcurl_multiAPI) またはgrequests(を使用して非常に高レベルのrequestsHTTP クライアント ライブラリを非同期化する) のような別の高レベルの抽象化を使用しgeventます。
もちろん、シングルスレッドのイベント ループが本当に必要かどうかも検討する価値があります。ほとんどのクライアント側アプリは、十数個以上の接続を処理する必要はなく、ソケットごとのスレッドは、どのプラットフォームでも簡単に処理できます。(もちろん、CPU バウンドのコードがある場合、Python スレッドは最悪ですが、シングル スレッドのイベント ループ ベースのコードはさらにひどいので、問題にはならないと思います。)
まず、あなたのコメントに対するいくつかの一般的なコメント:
「パフォーマンス」の意味がわかりません。通常、ネットワーキング アプリでは、スケーラビリティについて心配します。処理できる同時接続の数、1 秒あたりに作成できる新しい接続の数、維持できるスループットなどです。パフォーマンス— 通常、CPU/電力の量で測定されます。 -定常状態のワークフローで使用している描画/熱放散 - 通常、必要なすべてのスケーラビリティが得られた場合にのみ使用されます。その場合でも、ボックスが積み重ねられた数十の部屋を実行することを計画している場合にのみ使用されます。サーバーを実行しています。
いずれにせよ、あなたが何をテストしているのかはわかりませんが、これらのオプションはすべて、Linux と Mac OS X/*BSD で明らかに優れasyncoreており、Windows では完全に吹き飛ばされています。の代わりに、 IOCP、、、epollまたはを使用します。そのうちのいくつかは、中心となるコードを C で記述しています。それらはすべて、10 年以上前にサポートが追加されて以来、何の改善もされていませんが、実際の厳しい使用状況の下で広範囲にテストおよび調整されています。(それは、すでに十分に優れているからではなく、改善する価値があるほど良くないからです。)kqueuepollasyncorepollasyncore
ただし、クライアント側アプリの場合、通常、スケーラビリティもパフォーマンスも問題になりません。通常、数十のサイトから並行してダウンロードを行うだけで、FTTH/ケーブル/DSL などを飽和状態にするのに十分すぎるほどです。帯域幅、それ以上に何が必要ですか?
したがって、私がこれらの代替手段を提案した理由は、パフォーマンスやスケーラビリティのためではなく、単純さと完全性のためです。Twisted の HTTP クライアントまたはgrequestsは、たった 5 行のコードを書くだけでよいことを意味し、何かが機能し、難しい部分はすべて熟考され、十分にテストされています。自分で構築したとしても、ソケットをブロックするのではなく、バラバラにして再構築するよりもhttplib/ urllib2/whatever 上で実行するほうが、はるかに少ない作業で済みます (そして、バグが発生する可能性もはるかに少なくなります)。geventsasyncore
ねじれた-私は初心者であり、少なくとも現時点では、投資する時間があまりありません.
twistedは明らかに巨大なプロジェクトですが、すべてを習得する必要はありませんasyncore。以前に提供したリンクの HTTP クライアントの例を見てください。httplibこれを、とで同じことを行うのに必要なコード量と比較してくださいasyncore。
gevent - パフォーマンスは asyncore に似ていますが、サーバーの負荷が高すぎます。
サーバーの負荷が高すぎる場合は、クライアントの実行速度が速すぎることを意味するだけです。これは良い問題です。速すぎるクライアントはいつでも調整できますが、一般的に遅すぎるクライアントでは、全体を書き直す以外に多くのことを行うことはできません。
于 2013-04-10T08:03:30.090 に答える