Tomcat vs Vert.x

[Ronald Randon]

For the past few days I have beed reading vert.x documents. I know that vert.x is polyglot, single threaded, non-blocking IO, modular architecture, high scalability.

Is there any other major differences between tomcat and vert.x?

Also when we should use tomcat and when to use vert.x?

[Pid]

On 29/05/2014 14:15, Ronald Randon wrote:
> For the past few days I have beed reading vert.x documents. I know that
> vert.x is polyglot, single threaded, non-blocking IO, modular
> architecture, high scalability.

It's not single threaded.

> Is there any other major differences between tomcat and vert.x?

Lots. You might as well compare apples and frogspawn (or vice-versa).

> Also when we should use tomcat and when to use vert.x?

Please rephrase the question, it's far too open.


s



> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to vertx+un...@googlegroups.com
> <mailto:vertx+un...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.


--

[key:62590808]

[Alexander Lehmann]

Tomcat, at least with the 2.x servlet version is using a thread per request model of execution. Basically each request that is received from a client uses and blocks a thread in your tomcat jvm as long as the request is being processed (same with e.g. apache with worker mpm model), so that the number of client connections is directly related to the number of used threads. Depending on the memory consumption of the servlet threads, you will usually have a rather limited number of threads available (e.g. 100 or 250), which limits the number of clients that can connect. This is not an issue when you have a "normal" web 1.0 application, plus you will usually move the static files to another server, either a cdn or at least an apache or nginx server that is running before the tomcat or is running on an alternate address on the same machine.

If you have an ajax type application that has at least one open connection from each client to the server, this seriously limits the number of active clients you can handle, assume for example that you have a chat application that is running on a single tomcat, each chat user will have an open connection waiting for the next interaction from the server. Now if you cut down on the memory consumption of each thread, you can increase the number of http threads, but this has its limits in any case. The odd thing is that none of these threads do anything most of the time so that the cpu of the machine is not loaded at all. To increase the number of connections you have to cluster the web app in some way, e.g. by introducing a memory replication or using something like xmpp or irc in the background, just to handle the overhead of not doing anything. (on the other hand writing a threaded web application is pretty easy, but it gets more complicated when you introduce clustering).

To handle more connections without the overhead, there a few solutions available, the most famous at this point is probably node.js, which basically implements a single-threaded application server in javascript so that you do not have to worry about scheduling and thread safety, you just write the server code in javascript and the node.js engine will handle the execution in a way that can accommodate many more client connections.

vert.x is sort-of an app server similar to node.js in the way that it doesn't use threads for the normal execution of web requests (though you can use some if you do things that cannot be run asynchronously), however this requires quite a different implementation of processing as opposed to servlets.

When to use tomcat and when to use vert.x is a bit of a difficult question, most java programmers (or companies employing java programmers) have invested substantial effort in know-how about servlet and generally how to write threaded applications (including issues of thread safety), so throwing all that out the window and starting with a quite different concept is a bit difficult (sortof like companies are conditioned to do everything with SQL and are reluctant to use non-SQL databases, since that questions their commitment on the "correct" technology), however if you need an application that can handle many connections without requiring "heavy" processing like any kind of proxy type application or an application that mostly waits to user or server anwers without any processing (chat, notification of new mails, new uploads, new ticket etc), that would be very well suited for a framework like vert.x. If you think for example about the dropbox application, that has at least one http connection for each client that is running (no idea how many users Dropbox has, but it has to be millions) just waiting for new uploads into the dropbox of that user, if you have to expend a tomcat for each 100 or 500 users that would be quite expensive, while it would be easier to have a framework that supports maybe 10000 connections per server process.

As far as I know, Tomcat also has improved their execution model and with servlet 3.0, it should be possible to reduce the number of threads as well, so maybe that would be a better choice for people used to implementing tomcat web apps.

[Web Dev]

Once you start using Vert.x you will be able to answer those questions yourself rather quickly. You say you've been reading the docs, and that is a good start, now try to build something :)

[Dean Pehrsson-Chapman]

vert has an event bus

[Pid]

On 29/05/2014 15:10, Alexander Lehmann wrote:
> Tomcat, at least with the 2.x servlet version is using a thread per
> request model of execution. Basically each request that is received from
> a client uses and blocks a thread in your tomcat jvm as long as the
> request is being processed (same with e.g. apache with worker mpm
> model), so that the number of client connections is directly related to
> the number of used threads. Depending on the memory consumption of the
> servlet threads, you will usually have a rather limited number of
> threads available (e.g. 100 or 250),

Only partially true, the Connector used is a choice and the NIO
connector is, well, non-blocking for IO.

Comparing threads is pointless when the number of threads in Tomcat is
end-user configurable and more importantly orientated towards an
entirely different application architecture.

By the above reasoning, one might infer that the rather limited number
of threads encouraged by vert.x is a less ideal solution, when in fact
it offers comparable (if not better) performance using an order of
magnitude less threads.

which limits the number of clients
> that can connect.

Using the NIO connector means being able to support 10000 connections
(configurable), (with the otherwise default settings) & just 200 threads
(configurable).

So most of the below is based on a false premise, unfortunately.

It's nothing to do with Tomcat's 'execution model'. The Servlet 3.x
specs offer more async features, but just throwing work over to another
thread pool doesn't guarantee better performance, unfortunately.


Tomcat is a Servlet Container with a long history and a bunch of spec
versions behind it and all of the compromises and iterations that
implies. Its design is based on a different way of thinking to vert.x's
design, which at /worst/ has the benefit of being able to start over
without all of that baggage.


s

> On Thursday, May 29, 2014 3:15:10 PM UTC+2, Ronald Randon wrote:
>
> For the past few days I have beed reading vert.x documents. I know
> that vert.x is polyglot, single threaded, non-blocking IO, modular
> architecture, high scalability.
>
> Is there any other major differences between tomcat and vert.x?
>
> Also when we should use tomcat and when to use vert.x?
>

[Jerome Doucet]

Vert.x has been design explicitly for distributed application, and (it's my opinion) can dramatically enhance your productivity and the performance of your app in this business.

It's for example very easy to create and to introduce new services with replicated instances in any app by using vert.x... Services that may be directly available from web client through SockJs !

There will be more thing to say, butI am still a beginner in vert.x, however, I really love what I discover and I am already fond of it.

J

[kim young ill]

always depends on what you want to do, tomcat is  servlet container, so if it's a webapp, in most cases you can drop it in any other container (jetty, jboss, .....) without any problem.

the advantage of it is also the tools for the jee-stack & maturity (orm, container-injection, security, session management,jms.., they are standards) which is also portable between containers.

if you go with vertx you might need to roll your own in many places.

but again, depends on the requirements.