Vert.x— powerful and reactive
“I think fast, I talk fast and I need you guys to act fast” —— Winston Wolf
As humans evolved, programming also evolved from static pages to real-time applications. The need for faster response times applications is increasing day by day and we need to choose our frameworks judiciously keeping these in mind. There are some limitations with traditional programming like the Sync Paradigms:
- Blocking I/O calls, threads wait for the IO events, hence increasing the compute resources
- Blocking calls, uses a lot of system resources, which increases the cost
- Scaling challenges, the performance tuning is not very easy with sync programming.
To overcome these problems, we have adapted asynchronous and event-driven programming, which is event-driven and uses non-blocking I/O. Using Async Programming, we were able to optimize many critical areas like scaling, resource utilization, irrespective of load in the system. There are many frameworks/tools which will help us to write Asynchronous programs but we choose Vert.x based on benchmarking various frameworks and found its performance to be one of the best.
Vert.x is one of the reactive frameworks, which helped us build our core JVM based reactive system. Akiro MQTT leverages these advantages of Vert.x and is one of the high throughput systems which can handle over 10’s of millions of connections.
Vert.x Reactive
Vert.x — X represents polyglot, hereby it is Polyglot in nature. Vert.x is the toolkit for building the Reactive applications on the JVM. Reactive applications consist of components that send messages and events together. Vert.x operates on event loop based processing and also has the ability to have a thread pool. It is event-driven and non-blocking. This means you can handle a lot of concurrency in your applications using a small number of threads, it lets your applications scale with minimal hardware.
VX — Verticles
Vert.x has a processing component called a Verticle and it’s the smallest functional component in Vert.x architecture. It is typically a collection of code that serves a single purpose.
In one application we can have many verticles, for example, a verticle can expose the HTTP endpoints, others can handle the JDBC Connections or any other functional pieces. Verticle can be deployed and undeployed at runtime and can be network-wise distributed from one another and communicate over the Vert.x event bus.
We can tune the verticles independently, which gives the flexibility to independently tune, scale, or turn off individual functional units.
VX — Event Bus
As Vert.x is distributed in nature, it needs some mechanism to communicate with each other. This is where the event bus comes into play. The event bus is how Vert.x allows for simplified concurrency throughout the system. While Vert.x is multithreaded, each verticle runs in isolation without a shared state and they communicate via the Event bus. Event bus can do the following types of events.
- Pub/Sub
- Point to Point
- Request — Response Messaging
Event bus can also be distributed, it can connect multiple Vert.x JVM instances. This helps for modern real time web applications.
VX — Threading
First of all Vert.x is multi-threaded, unlike NodeJs. We can achieve this via the Multi-Reactor Pattern. Each verticle within a Vert.x application isolates its state, thus providing a thread-safe environment. Each verticle has a separate pool of threads namely the event loop and worker pool. Event loops are non-blocking threads where any thread can be activated upon the triggering of the event within the verticle
It is inherited from the Netty library on which Vert.x is based. “You should never block an Event Loop”. On the other hand, worker Pool threads are used for long-running or blocking tasks to overcome Event loop shortcomings. Both of these pools have a default size (Event loop: two times the cores of the machine, Worker pool: 20) but can be configured while deploying the verticle. Other threads are running within the verticle to help the functionality.
VX — Scalability
Vert.x can scale via Verticle. Verticles can scale both Horizontally and Vertically.
Vertical Scaling
Verticle can be scaled by adding the number of instances while we are setting the deployment options. Each Vert.x will have multiple event loops and each verticle instance will be bound to one event loop.
Horizontal Scaling
Verticle can be scaled horizontally also, by running the different JVMs across and connecting via the event bus. A cluster manager takes care of distributed management of the event bus and interaction with verticles. The default cluster manager of Vert.x is Hazelcast, we can change its configuration to Apache Ignite, Apache Zookeeper, etc. which are being currently supported.
Vert.x — MQTT
Vert.x MQTT is a set of MQTT APIs, through which we can handle connection requests, communication between remote clients. It exposes a lot of the handlers where we can write our own business logic.
MQTT is IO intensive and along with Vert.x’s event-driven IO, it makes Vert.x MQTT a great choice for MQTT implementations.
Akiro with MQTT
Akiro MQTT broker which leverages the Vert.x MQTT framework and is one of the High Scale Messaging and Connectivity throughput systems that can concurrently handle 10’s of Millions of connections in a single cluster deployment. Because of its reactive nature, it can handle parallel requests in a resource efficient way.
The platform is also equipped with an event processing engine to evaluate rules and receive instant alerts and notifications. The analytics capabilities of Akiro provide rich actionable insights to improve business efficiency. In our Subsequent blogs, we will speak about how Vert.x helped to create a High Performance Messaging and Connectivity System like Akiro-MQTT. To use our Akiro MQTT broker click on the Sign-Up.
Conclusion
Vert.x turned out to be a very good pick for us and we recommend it would be a good choice for event-driven and async architectures, which have high scalability requirements. Vert.x’s independently scalable verticles, the flexibility of tuning, and the different IO optimizations enabled Akiro to clock 1 Million requests per second.
From the implementation point of view as well, Vert.x gives us a good number of async libraries for JDBC, Kafka, Zookeeper, etc. connectivity which helped us. Due to its constructs and independent deployment and change management, which decouples the applications into smaller verticles, code maintainability has increased significantly.
Do try our free to use, Akiro-MQTT Broker, sign up here today: Sign-Up.
