Webサービスの構造

アンドレイ・スミルノフ

Webサービスのバックエンドの「ガッツ」と「ガッツ」に入り、この内部デバイスがサービスの効率にどのように影響するか、製品、その特性、およびアプリケーションが重い負荷に耐えられるようにする方法を説明します。より速く動作します。

Webサービス、バックエンド、アプリケーションサーバーをどの部分と呼びますか？ 古典的なアーキテクチャでは、これがhttpリバースプロキシまたはロードバランサの背後にありますが、一方でデータベース、memcachedなどがあります。これがまさにこのバックエンドです。

バックエンドは何をしていますか？

プロセッサ速度とネットワーク接続の比率を見ると、違いは数桁です。 たとえば、このスライドでは、1 KBのデータの圧縮には3μsかかりますが、同じデータセンター内であっても、一方向への往復はすでに0.5ミリ秒です。 バックエンドが必要とするネットワーク相互作用（たとえば、データベースへの要求の送信）には少なくとも2回のラウンドトリップが必要です。これは、データの処理に費やされるプロセッサー時間と比較するとまったく重要ではありません。 ほとんどの場合、リクエストは処理され、バックエンドは何もせずに待機します。 なぜ彼は待っていますか？ 比較的複雑な作業の大部分は、リバースプロキシまたはそれに直面しているロードバランサーによって行われます。 このバッファリング要求と応答、および検証http、低速クライアントとの「戦い」、暗号化https。 文字通り一対のtcpパケットで既にバッファリングされている純粋なhttp-validリクエストがバックエンドに届きます。 プロキシ応答もバックエンド用にバッファリングする準備ができており、これを行う必要はありません。

バックエンドは、Webアーキテクチャの最大のローファーの1つです。 彼には2つのタスクしかありません。

1. ネットワークI / O-これは一方でプロキシとの通信です-HTTPリクエストを受信して​​それに応答し、他方でデータを保存するあらゆる種類のサービスと通信します-これらはデータベース、キュー、memcachedなどです
2. 文字列の接着-データをJSONでシリアル化し、htmlに基づいてテンプレートを作成し、sh1またはmd5を計算しますか？ データ圧縮を実行します。

そして、バックエンドのビジネスロジックとは何ですか？ これらは、「変数の値が3を超える場合、実行します」、「ユーザーがログインしている場合は1つを表示し、ログインしていない場合は別の表示をする」などのチェックです。 もちろん、画像のサイズの変更、ビデオの変換など、特定のタスクがありますが、ほとんどの場合、このようなタスクはキュー、ワーカーなどを使用してバックエンドの外部で解決されます。

クエリの同時実行性

バックエンドについて話し、そのパフォーマンスが製品の全体的なパフォーマンスを大きく左右する場合、2つの最適化目標を設定できます。

1. 1秒あたりのリクエスト数を「ダイジェスト」にする、つまり 生産性を向上させ、
2. 2番目の目標-製品-は、応答時間を短縮することです。つまり、各要求がはるかに速く実行され、ユーザーにとって結果がより速く表示されるようになります。

バックエンドがアイドラーであり、ほとんどの時間待機することを思い出すと、バックエンドが可能な限り多くの負荷に耐えることができるという観点から、1つのリクエストではなく、複数のリクエストを同じプロセッサコア内で処理する必要があることは完全に論理的ですに。 CPU時間は非常に短く、それらの間に待機間隔があります。同じコアで複数のリクエストを処理し、ある種のネットワークI / Oを待って処理がブロックされるとそれらを切り替えます。

一方、応答時間を最適化する場合、応答時間に影響を与えるものは何ですか？ これは、バックエンドが行うことです-ストリング化とネットワークI / O。 ネットワークI / Oは1桁長い時間がかかるため、最適化する必要があります。 これを行うには、すべての待機時間を並列化することができます-すべての要求を同時に送信し、すべての回答を待機し、クライアントのブロックを形成して返信します。 もちろん、ビジネスロジックによっていくつかの要求を同時に送信できる場合は、応答時間が大幅に短縮されます。

ネットワーク入出力

ネットワークI / Oから始めましょう。 I / Oの編成には、ブロッキング、非ブロッキング、非同期の3つのオプションがあります。 後者はネットワークのものでは動作しません。2つのオプションがあります-ブロック、非ブロック。

APIソケット、BSDソケットの例を使用してそれらを見てみましょう。これらはUNIX-e上、Windows上ではすべて同じです-呼び出しは異なる方法で呼び出されますが、ロジックは同じです。 低レベルtcpソケットAPIはどのようなものですか？ これは一連の課題です。 サーバーについて話している場合は、ソケットを作成し、リッスンしている特定のアドレスにバインドし、リッスンし、着信接続を待機することを報告する必要があります。 次に、accept呼び出しがあります。これは、新しいソケット、特定のクライアントとの新しい接続を提供します。この接続内で、このソケットからデータを読み書きできます。 リクエストを受信し、レスポンスを送信し、最後にこのソケットを閉じます。

I / Oがブロックされている場合、データ、新しい接続、またはシステムネットワークバッファーが自由に書き込まれるまで、ほとんどの重要な操作がブロックされます。 実行スレッドは、何らかの操作の完了を待ちます。 これから最も単純な結論が得られます。単一のスレッド内では、複数の接続を提供することはできません。

一方、このオプションは開発の観点から最も単純です。

しかし、2番目のオプション-ノンブロッキングI / Oがあります。 表面的には、違いは基本的なものです-ブロックされる代わりに、すべての操作はすぐに完了します。 データの準備ができていない場合は、特別なエラーコードが返されます。これにより、後で呼び出しを試みる必要があることが明確になります。 このオプションを使用すると、同じスレッドから複数のネットワーク操作を同時に実行できます。 しかし、なぜなら ソケットがI / Oの準備ができているかどうかは不明であるため、対応する要求で各ソケットを順番に回す必要があり、実際には、永続的なサイクルでスピンしますが、これは非効率的です。 すべてのソケットを実行できる準備ポーリングメカニズムが必要です。彼は、どのソケットがI / Oに対応しているかを教えてくれます。 準備ができたら、必要なすべての操作を実行します。その後、ブロックしてソケットを待機し、再びI / Oの準備ができます。 このような準備調査メカニズムはいくつかありますが、詳細はパフォーマンスが異なりますが、通常は「ボンネットの下」にあり、私たちには見えません。

ノンブロッキング入出力を作成する方法は？ 準備調査とI / O操作を、今日準備が整っているソケットのみと組み合わせます。 準備調査は、少なくとも1つのソケットにデータが表示されるまでブロックされます。

「ボンネットの下」にあるものについての2番目の質問は、マルチタスクの問題です。 複数のリクエストの同時処理をどのように保証できますか（これが必要であることに同意しました）？

3つの基本オプションがあります。

個々のプロセス

最も簡単で歴史的に最初の方法は、各リクエストを処理することです。個別のプロセスを開始します。 ブロッキングI / Oを使用できるため、これは良いことです。 プロセスが突然クラッシュした場合、処理されたリクエストのみに影響し、他のリクエストには影響しません。

マイナスの-かなり複雑なコミュニケーション。 正式には、プロセス間に正式なものはほとんどありません。整理したい重要な通信メカニズムには、アクセスを同期するなどの追加の努力が必要です。 このスキームの外観-いくつかのオプションがありますが、通常は最初のプロセスが開始され、たとえばリッスンします。その後、ワーカー用のプロセスセットを生成します。各プロセスは同じソケットで受け入れ、着信接続を予期します。

着信接続が表示されるとすぐに、プロセスの1つがブロック解除され、この接続を受信し、最初から最後まで処理し、ソケットを閉じて、次の要求を再度実行する準備が整います。 さまざまなバリエーションが可能です-着信接続ごとにプロセスを生成するか、すべてを事前に開始するなど これはパフォーマンス特性に影響を与える可能性がありますが、私たちにとってそれほど重要ではありません。

そのようなシステムの例：PHPを最も頻繁に実行する人のためのFastCGI、データベースから「レール」に書き込む人のためのPhusion Passenger-これはPostgresSQLです。 接続ごとに個別のプロセスが割り当てられます。

オペレーティングシステムのスレッド

1つのプロセスの一部として、複数のスレッドを生成します。1つのスレッドのみがブロックされるため、I / Oのブロックも使用できます。 OSはスレッドについて知っており、スレッドをプロセッサ間で分散させる方法を知っています。 スレッドはプロセスよりも軽量です。 本質的に、これは同じシステムでより多くのスレッドを生成できることを意味します。 1万個のプロセスを開始できる可能性は低いですが、1万個のスレッドを開始できます。 それが1万個で効果的であるという事実ではありませんが、それでも、それらはいくらか軽量です。

一方、断熱材はありません。 何らかのクラッシュが発生した場合、個別のスレッドではなく、プロセス全体をペイントします。 そして最大の難点は、バックエンドで処理されるプロセスにまだ一般的なデータがある場合、スレッド間の分離がないことです。 共有メモリ。つまり、共有メモリへのアクセスを同期する必要があります。 共有メモリへのアクセスを同期する問題は最も単純な場合です。たとえば、データベースへの接続、またはデータベースへの接続のプールがあり、これは着信接続を処理するバックエンド内のすべてのスレッドに共通です。 アクセス同期を正しく行うことは困難です。

難易度には2つのクラスがあります。

1. 潜在的な問題が同期プロセス中のデッドロックである場合、私たちの一部がしっかりとロックし、実行を継続できない場合。

2. 共有データへの競争力のあるアクセスと、大まかに言うと2つのストリームがある場合、同期が不十分であり、これらのデータは同時に変化し、それらを損ないます。 そのようなプログラムをデバッグすることはより難しく、すべてのバグがすぐに現れるわけではありません。 たとえば、有名なGIL（Global Interpreter Lock）は、マルチスレッドアプリケーションを作成する最も簡単な方法の1つです。 すべてのデータ構造、すべてのメモリは、プロセス全体で1つのロックだけで保護されていると言います。 これは、1つのスレッドしか実行できず、ロックが1つしかなく、誰かがそれをつかんで、他のすべてが機能しないため、マルチスレッド実行が不可能であることを意味すると思われます。 はい、それは事実ですが、ほとんどの場合プロセスで作業するのではなく、ネットワークI / O操作を待つため、ブロックされたI / O操作の呼び出しが発生すると、GILが低下し、スレッドがリセットされます。実行準備ができている別のスレッドに切り替わります。 したがって、バックエンドの観点から見ると、GILの使用はそれほど怖くないかもしれません。

   
   
   
   
   

   複数のスレッドで行列を乗算しようとすると、GILを使用するのは怖いです-一度に1つのスレッドしか実行されないため、これは無意味です。

   
   
   
   
   

   例。 これはデータベースからのMySQLであり、リクエストの処理用に別のスレッドが割り当てられています。 別のニスHTTPキャッシュ。ワーカーは個々のリクエストを処理するスレッドです。

   
   
   
   
   

協調マルチタスク

3番目のオプションは最も困難です。 ここで言うOSはもちろんクールで、そこにシェダーがあり、プロセス、スレッド、それらの間の冒険を整理、ロックを処理することができますが、それについてはさらに悪いことを知っています私たちが知っているよりも、アプリケーションの配置方法。 プロセッサ上でいくつかの操作が実行される瞬間があり、ほとんどの場合ネットワークI / Oが予想されるため、個々の要求の処理をいつ切り替えるかがわかります。

OSの観点からすると、協調マルチタスクは実行の1つのスレッドにすぎませんが、その内部では、アプリケーション自体が個々の要求の処理を切り替えます。 データが到着するとすぐに、それを読んでhttpリクエストを解析し、何をする必要があるかを考え、memcachedリクエストを送信しましたが、これはブロッキング操作であり、レスポンスがmemcachedから来るまで待機し、待機する代わりに、別のリクエストの処理を開始しています。

そのようなプログラムを書くことの複雑さは、私が現在特定の要求ごとに行っている切り替え、コンテキストの維持のプロセスが開発者にあるという事実にあります。 一方、不必要なスイッチがなく、スレッドとプロセスを切り替える際のプロセッサコンテキストなどの切り替えに問題がないため、効率が向上します。

協調マルチタスクを実装するには2つの方法があります。

1つは明示的なメソッドであり、多数のコールバックによって区別されます。 アクションがいつか発生し、いつかは結果があるときにコントロールが返されるという事実につながるすべてのブロック操作があるため、コールバックを常に登録する必要があります-リクエストが実行されると、それが実行され、成功しない場合は実行されます。 コールバックは明白なオプションであり、実際には非常に困難な場合があるため、多くの人はそれを恐れています。

2番目のオプションは、協調的なマルチタスクが存在しないようにプログラムを記述する場合に暗黙的です。 ブロッキング操作を行いましたが、結果はここで期待しています。 実際、どこかに「フードの下のブラックマジック」があります。この時点で、ブロッキング操作を非ブロッキングに変換し、OSスレッドの意味ではなく論理スレッドに制御を転送するプログラミング言語のランタイムフレームワークを既に見つけました。内部にあるパフォーマンス。 このオプションは、グリーンスレッドと呼ばれます。

協調マルチタスクの内部には、すべてのI / O処理を担当する中央リンクが常にあります。 それはリアクターと呼ばれます。 これは一種の開発パターンです。 リアクターのインターフェイスは次のとおりです。「ソケットとコールバックの束をください。このソケットがI / Oの準備ができたら、電話します。」

リアクターが提供する2番目のサービスはタイマーです-「非常に多くのミリ秒後に変更する呼び出し、ここに呼び出す必要があるコールバックがあります」。 このことは、明示的または暗黙的に協調マルチタスクが行われる場所であればどこでも見つかります。

通常、リアクター内は非常にシンプルに配置されています。 タイマーでソートされたタイマーのリストがあります。 したがって、彼は与えられたソケットのリストを取得し、準備ポーリングメカニズムに送信します。 また、準備ポーリングメカニズムには常にもう1つのパラメーターがあります。ネットワークアクティビティがない場合にブロックできる時間を示します。 ブロック時間として、最も近いタイマーの応答時間を示します。 したがって、何らかのネットワークアクティビティがあるか、ソケットの1つがI / Oの準備ができているか、最も近いタイマーが起動し、ロックを解除して、実際に実行の論理フローへの制御を1つまたは別のコールバックに転送するのを待ちます。

これは、明示的なコールバックを使用した協調マルチタスクの外観です。

ある種のブロッキング操作を実行するnode.jsの例-実際にはnet.connect。 「フードの下」、それはノンブロッキングであり、すべてが正常であり、コールバックを登録します。 すべてが成功した場合はそれを行い、失敗した場合はそれを行います。

コールバックの問題は、最終的に「ヌードル」に変わることですが、この問題に戻ります。

2番目の例。

ここでも、協調型マルチタスクがプログラムに表示されていませんが。

ここで、複数のスレッドが起動され、それらが同時に並行しているのがわかりますか？ 実際、協調マルチタスクは次々にブロッキング操作を実行しますが、いくつかのURLをダウンロードします。 このurlopen関数は実際にブロックしますが、geventはいくつかの「ブラックマジック」を行い、これらのすべてのブロックネットワーク操作は非ブロッキング、協調マルチタスク、コンテキストの切り替えになります-これはすべて表示されず、通常の完全にシーケンシャルなコードですが、すべての内部非常に効率的に機能します。

協調型マルチタスクを使用したシステムの例：Redis、memcached（完全に協調型のマルチタスクではありませんが、多くの人がそうだと考えています）。 彼らの特徴は何ですか、なぜ彼らはこれを行う余裕がありますか？ これはデータストレージですが、すべての操作、すべてのデータはメモリ内にあるため、バックエンドと同様に、単一のリクエストの処理に費やすプロセッサ時間は非常に小さくなります。 つまり 最も単純なケースでは、getリクエストを処理するには、内部ハッシュのキーを見つけ、データブロックを見つけてそれを返す必要があります。答えとしてソケットに書き込むだけです。 したがって、協力的なマルチタスクは彼らにとって効果的です。

RedisまたはmemcachedがI / Oにディスクを使用した場合、すべてが実行されていたはずですが、I / Oで唯一のスレッドがブロックされた場合、これはすべてのクライアントからのリクエストの処理を停止するため、単純に機能しませんでした。 実行のスレッドは1つだけであり、どこでもブロックする余裕はありません。すべての操作を迅速に実行する必要があります。

おそらく数年前の3〜4年前に誰かがRedisを思い出すと、ある種の仮想メモリ（データの一部をディスクに保存する機能）を作成しようとする著者の試みがありました。 これは仮想メモリと呼ばれていました。 彼はこれを実行しようとしましたが、ディスクI / Oが開始されるとすぐにRedisの応答時間が数桁も短くなり、その意味が失われたことを意味するため、これが機能しないことにすぐに気付きました。

しかし、実際には、これら3つのオプションはどれも理想的ではありません。 特に、接続が長時間ハングする状況では、協調型マルチタスクが通常勝つため、組み合わせたバージョンが最適に機能します。 たとえば、Webソケットは長期間存続する接続であり、1時間存続できます。 1つのプロセスまたは1つのスレッドを選択して1つのWebソケットを処理すると、一度に1つのバックエンドで保持できる接続の数が大幅に制限されます。 また、接続は長期間存続するため、多くの同時接続を維持することが重要です。一方、各接続にはほとんど作業がありません。

協調マルチタスクの欠点は、そのようなプログラムが1つのプロセッサコアしか使用できないことです。 もちろん、同じマシン上でバックエンドの複数のインスタンスを実行できますが、必ずしも便利ではなく、欠点もあるため、複数のプロセスまたは複数のスレッドを実行し、各プロセスまたはスレッド内で協調マルチタスクを使用することをお勧めします。 このような組み合わせにより、一方ではシステムで利用可能なすべてのプロセッサコアを使用でき、他方では、個々の接続を処理するために大きなリソースを割り当てることなく、各コア内で効率的に作業できます。

2つの典型的な例はnginxで、ワーカーの数を設定します。ワーカーの数をシステム内のカーネルの数まで増やすのは理にかなっています。これらは別個のプロセスです。 ワーカー内では、各ワーカーはノンブロッキングI / Oと協調マルチタスクを使用して、多数の同時接続を処理します。 ワーカーは、個々のプロセッサ間で並列化するためにのみ必要です。

2番目の例はmemcachedで、これについては既に引用しました。 彼には、複数のスレッド、いくつかのOSスレッドで起動するオプションがあります。 次に、複数のスレッドを開始し、それぞれの内部でリアクターが回転します。これにより、ノンブロッキング入出力と協調マルチタスクが提供され、複数のスレッドにより複数のプロセッサコアを効率的に使用できます。 さて、memcachedの共有メモリはキャッシュであり、実際にキャッシュを提供します。 これらのスレッドはすべて、同じキャッシュから読み取りおよび書き込みを行います。

もう一つ質問。 私たちは、バックエンドがどのように処理するかについて常に話し合ってきました。ほとんどの場合、少なくとも、着信するリクエストへの着信HTTP接続についてです。 しかし、バックエンドは発信リクエストを作成し、HTTPを介した他のサービス、データベース、Redis、memcached、キューなどのサービス指向アーキテクチャでは、このようなリクエストが多数発生する可能性があります。これは同じネットワークI / Oです。最初にこれに同意したように、バックエンドの特性に影響を与えます。

データベースのこのドライバーを（条件付きで）配置する方法と、それをより効率的にする方法を見てみましょう。 まず、そのようなアーキテクチャの概要を説明します。

複数のサーバーがあり、各サーバーがバックエンドの1つ以上のコピーを実行し、アプリケーションサーバーからの接続先である、ここでは条件付きでDBと呼ばれるデータストレージが存在すると仮定します。 最初の質問は、1つのリクエストで接続を使用するかどうか、つまり 1回の着信HTTPリクエストで、データベースへの接続などを開くと、膨大な時間が失われます。

個々のフェーズに対応する正方形を以下に示します。 それらは縮尺どおりに描かれておらず、ネットワークアクティビティはプロセッサ上のアクティビティよりも時間がかかります。 つまり 1つの要求で接続を行う場合、最初に接続を確立する際、接続を閉じる際に膨大な時間を失います。たとえば、データベースで他のアクセス許可が必要な場合、さらに多くの時間を失います。 同時に天文学的であり、接続が一定であれば、毎回確立される接続で行ったよりも2つの要求に対する応答を送受信できます。 永続的な接続を維持する方がはるかに効率的です。

2番目の質問は、次のリクエストを送信する前に、リクエストに対する応答を待つ必要があるのはなぜですか？ リクエスト間に論理的な接続がなく、実際、リクエストストリームが個別の無関係なリクエストで構成されている場合、回答を待たずにすぐに送信してから、すべての回答を待ってみませんか？

もちろんできます。 これはパイプラインと呼ばれます。

たとえば、PostgreSQLはパイプライン処理を実行できます。

データベースからの応答時間を大幅に短縮できるため、バックエンド全体の応答時間を短縮できます。

もう一つ。 バックエンドとデータベースの間にプロキシを配置できます。

このようなわずかに誇張された状況がここに描かれています。途中に2つのプロキシがあります。1つはアプリケーションサーバーのあるホストにあり、もう1つはデータベースの前にあります。 これは必ずしもそうではありません。1つの絵に2つのケースを描いてみました。

一般的に、プロキシが必要なのはなぜですか？ 優れたデータベースドライバーがある場合、つまり、すべてを効率的に実行し、一定の接続、パイプラインなどがある場合、一般的に言えば、パフォーマンスの観点からプロキシは必要ありません。さらに、パフォーマンスの観点からは有害です。応答時間が低下します。

一方、貧弱なデータベースドライバーを使用している場合、より賢く、たとえばパイプライン処理や永続的な接続を行うプロキシを使用すると、応答時間を短縮できます。

第三に、プロキシは他の多くの用途にも使用できます。たとえば、memcachedでデータベースへの単一のエントリポイントを作成できるプロキシを使用すると、シャーディング、再構成、アプリケーションなしで切り替えることができます。 アプリケーションはプロキシサーバーで動作し、その背後にあるものを認識せず、プロキシを任意に再構成できます。

ただし、必要なプロキシサーバーがあります。 たとえば、PostgreSQLを使用している場合、PgBouncerを実行する前に必要なすべての箇所を読むことで、あなたの人生はずっと良くなります。 なんで？ その理由は簡単です-すでに述べたように、PostgreSQLは各接続を処理するための別個のプロセスを起動します。フォークは非常に高価な操作です。 多くのプロセス、各接続の多くのインスタンスも保持するのに不利で不便です。また、PostgreSQLの前にあるプロキシにより、このビジネスを最適化できます。 アプリケーションサーバーの数に関係なく、必要な数の接続を使用し、それらをPostgreSQLへのより少ない接続（約100）にマップします。

サービス指向のアーキテクチャを使用している場合、これまでに説明したすべての問題に特定の係数Kが掛けられ、より多くのネットワークへの希望があり、同じクライアントリクエストに答えるためにさらにリクエストを行う必要があります。このビジネスをより効率的に実装できるほど、最終的にバックエンドの効果が高まります。

実世界

報告書の私が恐れている部分に近づいているので、腐ったトマトや他の悪い果物が私の中に飛び込まないようにヘルメットを着用します。

お気に入りのプログラミング言語、マルチタスク、ネットワークI / Oがどのように配置されているか、それらから何を得ることができるかについてお話します。

したがって、 JavaScriptで記述している場合 。 JavaScriptは、Webワーカーを除いてシングルスレッドですが、孤立したエンティティです。 計算モデルの観点からはシングルスレッドであり、ブロックされない非同期I / Oがあり、コールバックなどでタイマーを登録する特定のリアクターがあります。 何をするにしても、JavaScriptコードを書くだけでは、コールバックから麺ができてしまいます。 幸いなことに、最近JavaScriptの世界はDeferredやPromiseなどのことを学び、これがクールであり、積極的に実装されていることを発見しました。 これは一種の抽象化であり、コールバックと明示的に協調マルチタスクを行うプログラミング言語で役立ちます。これにより、この「麺」を解き放ち、一貫性を高めることができます。 遅延または約束は、遅延結果の概念です。 結果が到着したときに結果を空のブロックに戻すことが約束されています。 この空のブロックで、エラーまたは成功した状況のハンドラーを登録し、チェーンに配置し、Promiseを別のPromiseに接続し、実際、通常の同期的なものとまったく同じプログラミングパターンをシミュレートし、人生を大幅に簡素化できます。

PHP マルチスレッド実行モードを正式にサポートしていますが、実際にはいくつかの歴史的な理由により機能しません。 ほとんどの場合、PHPを実行している場合の重大な欠点は、着信要求ごとにすべてをクリアし、最初からやり直すことです。 したがって、あらゆる種類のPHPアクセラレータ、キャッシュなどがあります。 など ほとんどの場合、それぞれ、ブロックされたI / O内でのマルチプロセスクエリの実行、たとえば個別の「ブロット」の形でのデータベースへの永続的な接続など、個々のリクエストの処理間で持続できる一種の状態などです。 など

Ruby on Railsは、世界により大きな影響を与えるものです。 Ruby 1.9以前では、私が間違っていなければ、Ruby内のスレッドはグリーンスレッドでした。 実際には協調的なマルチタスクでした。 これらは正直なOSスレッドです。 さまざまなオプションがあります。 最も基本的なのは、マルチプロセスと入出力のブロックです。 Twisted Pythonフレームワークから廃止されたEventMachineフレームワークは、協調的なマルチタスクを可能にします。 長所と短所があり、EventMachineを使用する実装があります。

Pythonがあります。 Pythonは、あらゆるオプションを記述できることを嬉しく思います。 マルチプロセスサーバーを作成したり、マルチスレッド化したりできます。協調マルチタスク、コールバック、またはグリーンスレッドを使用できます。 すべてがさまざまなオプションと組み合わせで利用できますが、原則としてすべてが再び退屈で、すべてが同じです。

Javaには独自の仮想マシンがあり、それに応じて、JVM上で実行されるすべての言語、OSスレッドが長い間使用されていました。 ブロッキングおよびノンブロッキングI / Oを実行する機能があり、他の企業の世界のように、途中で固執できるフレームワークがあり、私にとってはこの全体を抽象化します。 私は気にしません、私は彼に何をすべきかを言っただけで、私の仕事は何かを一番上に書くことです。

.NETがあります 。これはすべて同じです-OSスレッドなど、特定の余談ですが、何らかの方法でDeferredまたはPromiseに似た非同期/待機言語構造があります。 なぜ軽いのですか？ その前に、すべてが非常に同じで悲しいです。

比較的最近登場したGoがあるので、最初は追跡者から離れてすぐに面白いことをすることができました。 Goにはゴルーチンがあります。これは本質的に緑のスレッドです。 これらはOSスレッドではありませんが、一方で、内部実行メカニズムは、ゴルーチンがさまよう複数のOSスレッドを開始できるという事実に基づいています。 協調的なマルチタスクとマルチスレッドの組み合わせです。 「ボンネットの下」には、常にノンブロッキングI / Oがあります。 私のゴルチンから、まるでそれらがブロックされているかのように操作しますが、実際にはゴルーチン間に切り替えがあり、ブロックされるとすぐに別のゴルチンが実行されます。 Goには他にも多くの興味深いものがあります。チャネル、競合プログラミングの独自の概念がありますが、それについては話していません。

Goよりも古いErlangがあります。また、Erlangプロセスにはそれぞれ競合プログラミングの独自のモデルがあり、GoルーチンGoとは異なり、論理的には実際のプロセスに似ているという点でも興味深いです。つまり それらは互いに完全に分離されており、ゴルーチンは共通のアドレス空間で動作し、すべてのメモリを参照します。 実装に関しては、これらは同じノンブロッキングI / O、協調マルチタスク、および利用可能なすべてのプロセッサコアを使用するためのOSスレッドの使用です。

GoとErlangを最後に付けたのはなぜですか。なぜもっと面白いのですか？ 基本的に、効率的なネットワークI / Oと効率的なマルチタスクを行うために、フレームワーク全体がすでに言語に組み込まれているためです。 , , , . , http- Go, Go, . , , , .

— , - , .

: libevent. , ? , - , ?

: - . , — . , , , . libevent libev, . - — . , libevent- - , libev-e — , « » - . - , .

: PHP : , , 2 -. , -, , , , «» — , , , ?

: , , , PHP? , - . - , . , - ..

: : , , , - , . - , ? . ? … proxy - , ?

: Proxy . , . — , . framework , . , . — . — , , . , . , - , , , . .