SpringMVC vs. Vert.x

What is Vert.x?

Vert.x is an event-driven, non-blocking reactive application framework running on the JVM. Vert.x is polyglot, which means that it supports many different programming languages. Currently are supported: Java, JavaScript, Ruby, Python, Groovy, Scala and more. Vert.x is known for its easy scalability and lightweight architecture which results in very good performance. Vert.x uses Netty for all IO-related processes.

What is special about Vert.x?

When you deal with web applications, you usually handle every single request in its own thread. This results in a lot of threads, most of them blocked, which can create much overhead. Vert.x approaches this problem by creating a fixed number of threads (event loops, mostly equivalent to the number of available CPU cores) which handle the requests using an event-based system. This means, everything works with event handlers and callbacks and you are not supposed to do any thread-blocking work directly in those threads. Instead you register a callback to be called after the task has finished.

How does it work?

You can create so-called „verticles“ which contain your application’s main entry point. Your application can consist of multiple verticles. These verticles are executed within a Vert.x instance and managed by an event loop. The Vert.x instance is running directly on the JVM. Now let us assume that the verticle registered a listener to wait for requests.


At every loop the event loop checks if there are requests available for the verticle. If so, the event loop calls the verticle’s event handler synchronously. The event loops are managed by the Vert.x instance. Usually, you have one event loop running for each processor core with one verticle running on each event loop. But you are free to start more event loops or assign more verticles to one loop. The verticles are connected by an event bus, which they use to send and receive their data. The bus also provides an interface to communicate with each other, even across multiple Vert.x instances or in a cluster. For most usually blocking tasks you can install special busmods (e.g. a MongoDB Persistor) instead of using the usual (blocking) database connectors. If there is no busmod available, you can start worker threads which work asynchronously to the event loops. But if you have to start a worker thread for every request, you should probably use a different framework. You are not supposed to run blocking tasks synchronously, because they would slow down or even block the entire event loop.

How does it look like?

This is how Vert.x looks like with Java:

public class Demo {
  public static void main(String... args) {
    Vertx vertx = Vertx.vertx();
    vertx.createHttpServer().requestHandler(req -> {
      if (req.method() == HttpMethod.GET) {
        if (req.path().equals("/hello")) {
          req.response().end("Hello world.");

As you can see, you add a request handler to your verticle. Then this handler will be invoked by the event loop for every request. After that you filter the requests (e.g. by HttpMethod and path) and respond. You also have to start your HTTP server.

This is how Spring MVC and Spring Boot looks like:

public class Demo {
  public static void main(String... args) {
    SpringApplication.run(Demo.class, args);

  @RequestMapping(value = "/hello", method = RequestMethod.GET)
  public String helloworld() {
    return "Hello world.";

With Spring, you register your request handler by creating a method and annotate it the way you want it to work. The requests are automatically filtered for you. Spring Boot also does the server setup per default on port 8080 for you. Of course you can customize this behavior.

The difference is here that Spring Boot provides defaults which allow you an easy start and get fast results. Spring MVC combined with Spring Boot has a higher usability and an easier readability in general. Also, you do not have to understand all that is going on in the background to create your Hello World application.

What should I use?

That depends on your use case and your personal preferences. If you like annotations and are familiar with Spring, you might not need to learn Vert.x. If you need some exorbitant performance, you should consider Vert.x. Spring Boot handles every request in its own thread which might be appropriate, if you have to handle complex business logic at many requests. In Vert.x you would have to start worker threads for all this which would nullify the performance benefit. But if most of your requests are just requesting semi-dynamic or static web pages anyway, you might be better off with Vert.x performancewise. On the other hand, if you have many shared resources, you could have a very bad time synchronizing them across all your parallel processes in Spring, while Vert.x makes them easier to manage.

SpringMVC is focused on enterprise processes and enterprise applications with lower user counts. Vert.x on the other hand is designed to build your large-scale, super-scalable and distributable web applications which might have less complex business logic in them, but need to perform reliably under massive load. In Vert.x you can deploy or remove verticles dynamically at runtime from your own code to easily adjust your capacity.

If you absolutely want to use Vert.x but do not want to give up on Spring in general, there is always the possibility to integrate Vert.x with your Spring stack, so you can use all the other modules Spring provides.

Short URL for this post: https://blog.oio.de/z0Cyg

About Steffen Jacobs

Java Consultant & Developer at Orientation in Objects GmbH. Follow me on Twitter and find me on LinkedIn and Xing. Some of the source code associated with the blog articles can be found on GitHub.
This entry was posted in Java Web Frameworks, Spring Universe and tagged , , , , , . Bookmark the permalink.

6 Responses to SpringMVC vs. Vert.x

  1. Pingback: HTTP/2 Client – Java 9 | techscouting through the java news

  2. Pingback: We are mildly flattered to present a pingback by a plagiarist: HTTP/2 Client – Java 9 – Narasimha Chinimilly

  3. Thanks, nice post. Nice comparison

  4. mthakare says:

    I compared Spring MVC application and Vertx application. Both application exposed an API that would fetch all records from DB (Select *). Record set was kept heavy, (20k records returned per API call)
    In Spring MVC application, an API would make a DB connection, fetch records, sends it via response.
    In Vertx. I created 2 verticles, HTTP Vertical that handles requests and responses, and a DB Verticle that talks with Database via vertx PostGres client. Verticles communicate to each other via event bus. (This is the typical flow demonstrated on vertx.io )
    I used Apache Bench as performance testing tool. Bombarded 2000 requests with concurrency set to 50.
    Initially with no memory restriction, vertx was marginally faster. (Spring : 9.11 per second, Vertx (5 instances of both verticals each) : 11.06 requests per second)

    But when memory restrictions were applied, vertx performance and relibility went down.
    After many event queue timeouts and testing with lot of different values of verticle instances following were the results

    Memory restriction 1024m
    Spring MVC : 8.41 request per seconds
    Vertx App (2 instances of each verticle) : 5.6 request per second
    This inreased marginally when instance was reduced to 1 for each verticle
    Vertx App (1 instance of each verticle) : 5.7 request per second

    When memory was restricted even further to 512m, it was disaster for vertx
    After lot of tries (each failing with ThreadBlock, OutOfMemory errors), I could get one complete result for vertx app
    However Spring MVC app never complained.
    Following are the results

    Spring MVC : 7.8 request per seconds
    Vertx App (1 instance each of HTTP and DB verticle) : 2.22 requests per second. With 33 out of 2000 failing.

    My observation is vertx application is not suitable for application that involve DB CRUD usecases.

  5. Khurram says:

    I would agree with mthakare , plus one thing that I can tell you that you are comparing very simple service and that too using non reactive spring. You should look at Project reactor and consider comparing slightly heavier work.

Leave a Reply to Khurram Cancel reply

Your email address will not be published. Required fields are marked *