CODEWITHSUNDEEP
javaperformancehttpservletsclient-server
Mr. Boy
Mr. Boy

Reputation: 63720

Does a servlet-based stack have significant overheads?

I don't know if it's simply because page-loads take a little time, or the way servlets have an abstraction framework above the 'bare metal' of HTTP, or just because of the "Enterprise" in Jave-EE, but in my head I have the notion that a servlet-based app is inherently adding overhead compared to a Java app which simply deals with sockets directly.

Forget web-pages, imagine instead a Java server app where you send it a question over an HTTP request and it looks up an answer from memory and returns the answer in the response. You can easily write a Java socket-based app which does this, you can also do a servlet approach and get away from the "bare metal" of sockets.

Is there any measurable performance impact to be expected implementing the same approach using Servlets rather than a custom socket-based HTTP listening app?

And yes, I am hazy on the exact data sent in HTTP requests and I know it's a vague question. It's really about whether servlet implementations have lots of layers of indirection or anything else that would add up to a significant overhead per call, where by significant I mean maybe an additional 0.1s or more.

Upvotes: 0

Views: 228

Answers (4)

p.marino
p.marino

Reputation: 6252

Of course there is some overhead. What it's hard to define is how much, not because it's hard to measure, but because it's hard to find an alternative which doesn't introduce the risk of being more fragile, bug ridden and poorly scalable.

In other words, supposing you are really dying for performance... will you roll out you own server? How will it deal with managing concurrent requests (all hitting the same port)? Will you write your own parser for the HTTP request? Will it be able to work correctly with all browsers? How will you recognize a session from a given client?

In other words your question is a bit like asking "do relational DBs introduce a significant overhead when measured against an imaginary custom datastore which nobody has written yet but that would cut out all the unecessary features in favour of raw speed?"

My answer: yes, of course. I would still use a DB, because it works now, and has been tuned for lots of things developers take for granted, but are horribly inefficient to reinvent every time you discover you need them for your application.

I strongly suggest, in case you haven't already, to have a look at Jetty, and specifically at the WebSockets implementation.

Upvotes: 1

Michael
Michael

Reputation: 35341

There is some overhead in terms of what has to be done to initialize a servlet. Although this only happens once when the servlet receives its first request.

Upvotes: 0

irreputable
irreputable

Reputation: 45433

I don't think there will be too much overhead. HTTP messages are very tiny, and very simple to parse. Servlet architecture doesn't have a lot of abstraction over bare bone http messages.

Even a naive servlet implementation should only cost a fraction of time it takes for a client to send the http request message to the server. That is, the overhead is unnoticeable.

Upvotes: 0

Bozho
Bozho

Reputation: 597036

Of course every abstraction adds overhead.

Judging by the fact that many java based web-applications exist - it's perfectly fine in terms of performance.

So in short - don't worry about it. Chances are that you will create a less optimal solution than javax.servlet. Performance problems come mostly from poor code.

Upvotes: 2

Related Questions