2013-07-22 7 views
6

質問はトロールのように見えるかもしれませんが、verticle自体が専用スレッドで実行されるので、実際にはvert.xが並行性をどのように管理するかについてです。 Javaで書かれたこのシンプルなvert.xのhttpサーバでVert.xは単一の頂点に対して実際の並行性を持っていますか?

見てみましょう:

import org.vertx.java.core.Handler; 
import org.vertx.java.core.http.HttpServerRequest; 
import org.vertx.java.platform.Verticle; 

public class Server extends Verticle { 
    public void start() { 
     vertx.createHttpServer().requestHandler(new Handler<HttpServerRequest>() { 
      public void handle(HttpServerRequest req) { 
       req.response().end("Hello"); 
      } 
     }).listen(8080); 
    } 
} 

は、私の知る限り、ドキュメントを理解して、このファイル全体が垂直方向のを表しています。したがって、startメソッドは専用のverticleスレッド内で呼び出されます。しかし、requestHandlerはどこで呼び出されますか?このスレッドで呼び出された場合は、node.jsよりもどこが良いか分かりません。

私は、ネットワーク/並行性ライブラリvert.xに基づいているNettyにかなり精通しています。 すべての着信接続は、非常にうまくスケーリングする専用のスレッドにマップされます。それで、これは着信接続が同様に頂点を表すことを意味しますか?しかし、どのようにVerticleインスタンス "Server"はそれらのクライアントと通信できますか?実際、このコンセプトはNode.jsに限られていると私は言います。

正しい概念を理解するのを手伝ってください!

よろしく、 クリス

+0

nettyには、スレッドと接続の間に固定されたマッピングがありません。これは、従来のjava.io同期I/Oよりもはるかに優れています。スレッドは、実際の作業がある場合にのみ、スレッドプールから募集されます。 –

+1

私は、頂点の重要な原理は、すべてのイベントが単一のスレッドによって提供されるということです(または、少なくとも、特定の頂点のイベントはすべて順次実行されます)。したがって、Vert.xは単一の頂点に対して並行処理を行いません。それがその点です。 –

答えて

4

私はかなりvert.xに関与している誰かに話をしましたし、彼は私が「同時性」の問題についての基本的権利だと言ってくれました。

しかし、彼は「Scaling servers」について詳細に説明したところで私が完全に逃したセクションを私に教えてくれました。

基本的なコンセプトは、頂点を書くときには単なるコアのパフォーマンスがあるということです。しかし、指定された頂点のインスタンス数を定義する-instanceパラメータを使用して、vert.xプラットフォームを起動することは可能です。私のサーバーの10個のインスタンスが10個のサーバーソケットを開こうとせず、実際には1個のサーバーソケットを開くように、Vert.xは魔法のように少し魔法をかけます。この方法では、vert.xは単一の頂点に対しても水平方向にスケーラブルです。

これは本当に素晴らしいコンセプトであり、特に素晴らしいフレームワークです!

0

すべてのverticleはシングルスレッドです。起動時に、vertxサブシステムはイベントループをそのverticleに割り当てます。その頂点のすべてのコードはそのイベントループで実行されます。次回はhttp://groups.google.com/forum/#!forum/vertxで質問する必要があります。グループは非常に活発で、あなたの質問はすぐに回答される可能性が最も高いでしょう。

1

あなたが正しく答えると、頂点は実際には非同期非ブロックプログラミング(node.jsなど)を使用するため、ブロック動作を実行できません。

それぞれが同じTCP/HTTPポートでリッスンしようとするより多くの(n = CPUコア)verticleインスタンスを生成することで、正しく記述したとおりにサーバーを拡張できます。それはNode.jsのに比べて輝い

は、JVM自体がマルチスレッドされていることであるあなたに(ジャワなどなどの型の安全性を含まないビューの実行時の時点から、)多くの利点を与える:

  • マルチスレッド(クロス・バーチクル)通信は、スレッド・セーフなアクターのようなモデルに制約されていますが、IPC(Inter Process Communication)は頂点間でメッセージを渡す必要はありません。ノードより高速です。JS新しいシステム・プロセス内のすべてのフォークタスクを産卵し、計算-重鎖および/または同じJVMプロセス内でタスクを遮断を行うための
  • 能力の通信にIPCを使用して:V8に比べてのHotSpot JVMのhttp://vertx.io/docs/vertx-core/java/#blocking_codeまたはhttp://vertx.io/docs/vertx-core/java/#worker_verticles
  • スピード:)
+0

また、V8はサーバサイドでは使用されないことに注意してください。ノードJはある時点で発生しました.JavaScriptは未処理のパフォーマンスにとって非常に悪い出発点です。 JVMは常にパフォーマンスのためにC/C++と競合し、サーバーサイドの使用履歴が長いため、これは現在非常に高速です:https://www.cubrid.org/blog/inside-vertx-comparison-with -nodejs –

関連する問題