Vert.x is a server framework which is rapidly arising. Each server framework claims its strong points are high performance with a variety of protocols supported. Vert.x takes a step forward from that. Vert.x considers the environment of establishing and operating the server network environment. In other words, Vert.x includes careful consideration in producing several 'server process DAEMONs' that run on the clustering environment, as well as producing one server process DAEMON.
Therefore, it is important to review Vert.x: which network environment it considers as well as how it delivers high performance. So, I think it will be valuable to pay sufficient time examining Vert.x structure.
Philosophy of Vert.x
Vert.x is a project affected by Node.js. Like Node.js, Vert.x is a server framework providing an event-based programming model. Therefore, Vert.x API is very similar to that of Node.js. That's because both of these models provide asynchronous API.
The most typical design philosophy of Vert.x is summarized as follows:
- Polyglot - supports several languages
Vert.x itself is built in Java. However, Java is not required to use Vert.x.
- Super Simple Concurrency model
When building a server application by using Vert.x, users can write code as a single thread application. That means that the multi-thread programming effect can be achieved without synchronization, lock, or volatility.
However, Vert.x allows to create multiple threads based on the number of CPU cores whlie only one process is executed. It handle the multi-threading so users can focus on implementing business logic.
- Provides Event Bus
As described in the introduction, the goal of Vert.x is not only to produce a ‘one server process DAEMON'. Vert.x aims to make a variety of Vert.x-built server programs communicate well with each other. For this, Vert.x provides Event Bus. Therefore, MQ functions such as Point to Point or Pub/Sub can be used (to provide Event Bus function, Vert.x uses Hazelcastm, an In-Memory Data Grid).
With this Event Bus, a server application built with different languages can easily communicate with each other.
- Module System & Public Module Repository
Vert.x has a module system. This module system can be understood as a type of component. That means the Vert.x-built server application project itself is modularized. It aims at reusability. This module can be registered to Public Module Repository. Through the Public Module Repository, the module can be shared.
What is the relationship and defference between Netty and Vert.x?
Before discussing the Vert.x performance, we should summarize the relationship between Netty and Vert.x. Vert.x uses Netty. In other words, it processes all IOs by using Netty. Therefore, it is meaningless to verify differences of the performance between Vert.x and Netty.
Vert.x is a server framework that provides API and functions different and independent from Netty, designed with different purpose from Netty.
Netty is a framework that can process the low-level IO and Vert.x can process the higher-level IO than Netty.
Comparison of Performance with Node.js
Even if functions provided by Vert.x are different from those of Node.js, comparing the performance between them is a significant matter. Figure 1 and Figure 2 below show the performance of Vert.x (Java, Ruby, Groovy) and Node.js. (Source: http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple-http-benchmarks/).
Figure 1 shows a comparison of performance when an HTTP server is built and only a 200/OK response has been returned. Figure 2 shows the comparison of performance when a 72-byte static HTML file is returned as a response.
Figure 1: Comparison of Performance When Only 200/OK Response Has Been Returned.
Figure 2: Comparison of Performance When a 72-byte Static HTML File is Returned.
This performance is proclaimed by Vert.x developers but the test has not been made under a strict environment. Just look the relative differences in performance.
Vert.x defines its unique terms and redefines general terms for Vert.x itself. Therefore, to understand Vert.x, it is necessary to understand the Vert.x-defined terms. The followings are popular terms used in Vert.x:
For Java, it is the class with a main method. Verticle can also include other scripts referred to by the main method. It can also include the jars files or resources. An application may consist of one Verticle or several Verticles, which communicate through Event Bus. Alongside Java, it can be understood as an independently executable class or a jar file.
A Verticle is executed within a Vert.x instance and the Vert.x instance is executed in its JVM instance. So there will be a lot of Verticles which are simultaneously executed in a single Vert.x instance. Each Verticle can have its own unique class loader. In this manner, direct interactions between Verticles, made through static members and global variables, can be prevented. A lot of Verticles can be simultaneously executed in several hosts on the network and the Vert.x instances can be clustered through Event Bus.
The Verticle instance guarantees it is always executed on an identical thread. As all codes can be developed as a single thread operation type, developers who use environment where Vert.x can be easily developed. In addition, race condition or deadlock can be prevented.
Event-based Programming Model
Like the Node.js framework, Vert.x provides an event-based programming model. When programming a server by using Vert.x, most codes for development are related to event handlers. For example, an event handler should be set to receive data from a TCP socket or an event handler, which will be called when data is received, should be created. In addition, event handlers should be created to receive alarms 'when Event Bus receives a message,' 'when HTTP messages are received,' 'when a connection has been disconnected,' and 'when a timer is timeout.'
Vert.x instance internally manages the thread pool. Vert.x matches the number of thread pools to the number of CPU cores as closely as possible.
Each thread executes Event Loop. Event Loop verifies the events as rounding the loop. For example, verifying whether there is data to read in the socket or on which timer an event has occurred. If there is an event to process on the loop, Vert.x calls the corresponding handler (of course, additional work is necessary if the handler-processing period is too long or there is a blocking I/O).
Verticles use Event Bus for communication. If a Verticle is assumed as an actor, Message Passing is similar to an actor model, which was famous in Erlang programming languages. The Vert.x server instance has a lot of Verticle instances and allows message passing among the instances. Therefore, the system can be extended according to the usable cores without executing the Verticle code through multi-thread.
Message passing is very useful. However, it is not always the best approach in all types of application concurrency situations. Cache is one of the most popular examples. If only one vertical has a certain cache, it is very inefficient. If other Verticles need the cache, each Verticle should manage the same cache data.
Therefore, Vert.x provides a method for global access. It is the Shared Map. Verticles share immutable data only.
As named, this is the core function of Vert.x. Functions that the Verticle can directly call are included in the core. Therefore, the core can be accessed by each programming language API supported by Vert.x.
The simple architecture of Vert.x is shown in the following Figure 3.
Figure 3: Vert.x Architecture (source: http://www.javacodegeeks.com/2012/07/osgi-case-study-modular-vertx.html)
The default execution unit of Vert.x is Verticle and several Verticles can be simultaneously executed on one Vert.x instance. The Verticles are executed on the event-loop thread. Several Vert.x instances can be executed on several hosts, as well as on one host on the network. At this time, the Verticles or modules communicate by using the event bus.
To sum up, the vert.x application consists of combinations of Verticles or modules and communication among those is made by using Event Bus.
vert.x Project Source Code
The source code for Vert.x project can be cloned from the Vert.x Github page.
Installing Vert.x and Executing Simple Examples
To use Vert.x, JDK7 is required because Vert.x uses the invokeDynamic in JDK7.
Vert.x can easily be installed.
- Download the compressed installation file from http://vertx.io/downloads.html to a desired location.
- Decompress the file and add the bin directory to the PATH environment variables.
This is all about the installation of Vert.x. In the command window, execute the
vertx version. If the version information successfully prints out, the installation is completed.
Execute the created server.js application by using the vertx command as follows:
Open a browser and connect to http://localhost:8080. If you can see the 'Hello World!' message, you have succeeded.
Let's see another example built other languages. The following code is written in Java. It shows a Web server that reads a static file and returns it as an HTTP response.
The following code is written in Groovy and provide the same functionality:
Future of Vert.x and NHN
At NHN we have been observing Vert.x development since its preofficial release. We think highly of Vert.x. We have been communicating with the main developer, Tim Fox, since June 2012 to discuss ways to improve Vert.x. For example, Socket.io on Vert.x. Socket.io is available on Node.js only. So we have ported it to Java and sent a Pull Request https://github.com/vert-x/vert.x/pull/320 to Vert.x repository on Gitub. It's now merged to Vert.x-mod project.
Our effort, socket.io vert.x module, will be used for RTCS 2.0 version (vert.x + Socket.io) which is under-developing in NHN.
Node.js could remain very popular because of Socket.io. If Vert.x can use Socket.io, Vert.x may have many use cases. Furthermore, if this socket.io vertx module is used as an embedded library, it will be meaningful to use socket.io in Java based applications.
What is RTCS?
RTCS (Real Time Communication System) is a Real Time Web Development Platform created by NHN. It helps to transfer messages between a Browser and a Server in real time. RTCS has been deployed for NHN Web services such as Baseball 9, Me2Day Chatting, BAND Chatting and so on.
The first version of Vert.x was released in May 2012. Compared to Node.js where the first version was released in 2009, the history of Vert.x is very short. Therefore, Vert.x does not have many references yet. However, Vert.x is supported by VMware and can run on CloudFoundry. So, we expect that many references will soon be obtained.