The architecture I have is that clients receive events from a service through websockets. We are building another service which also needs to communicate it's events to the clients. We are faced with a design decision - whether to change existing service or just add another websocket connection from client to new service.
It is technically complex and expensive to change the other service as it's not maintained by us, but at the end of the day, if necessary, it is possbile. Adding another connection to new service would be cheap and no redesign would be needed, but it would imply that there would be two connections in parallel.
Other questions i've looked at often get answers from server perspective, where TCP connections are limited and thus it's important to reduce the amount of connections, but it's obviously not applicable here, since it's two separate services. What i'm asking is that how big of a difference it is from a client perspective that instead of a single websocket connection there would be multiple connections? My view on this has been that our goal should be to use the same connection as each connection reduces performance, but to be honest it's just an opinion and not a proven fact.
Since it's enterprise setting, backwards compatibility and performance is highly important, but at the same time, development cost is way higher if we'd choose to go with one connection instead of two. So.. is there a real difference or it's something I should not worry about?
From a client perspective, on any modern platform, the difference in cost of managing one vs two sockets in an application or browser should be negligible. It sounds to me like simplifying development and maintenance effort should dominate your decision.
Related
This is a "design" or a "best-practices" theoretical question.
Most commonly web apps that use websocket connections use at most one websocket connection. However, there are no limitations for a web app to use more e.g. 10. More websocket connections might be chosen for data separation or clean code use cases (obviously there's more).
My question is - Is there a significant difference (in terms of performance, uptime, etc.) between having a one open websocket and having, let's say, ten open websockets in your webapp?
Also, imagine these two architectures. In the upper one the webapp opens as many websocket connections as it needs. In the lower one the webapp has always only one websocket connection to a "proxy" server and that "proxy" server opens websocket connections to as many endpoints as needed.
Question - Could you point some theoretical (practical) insights of why would one choose one architecture over the other? P.S. the lower one seems to be over-complicated.
Thank you!
When using websocket, we need a dedicated connection for bidirectionnel communication. If we use http/2 we have a second connection maintained by the server.
In that case, using websocket seems to introduce an unecessary overhead because with SSE and regular http request we can have the advantage of bidirectionnal communication over a single HTTP/2 connection.
What do you think?
Using 2 streams in one multiplexed HTTP/2 TCP connection (one stream for server-to-client communication - Server Sent Events (SSE), and one stream for client-to-server communication and normal HTTP communication) versus using 2 TCP connections (one for normal HTTP communication and one for WebSocket) is not easy to compare.
Probably the mileage will vary depending on applications.
Overhead ? Well, certainly the number of connections doubles up.
However, WebSocket can compress messages, while SSE cannot.
Flexibility ? If the connections are separated, they can use different encryptions. HTTP/2 typically requires very strong encryption, which may limit performance.
On the other hand, WebSocket does not require TLS.
Does clear-text WebSocket work in mobile networks ? In the experience I have, it depends. Antiviruses, application firewalls, mobile operators may limit WebSocket traffic, or make it less reliable, depending on the country you operate.
API availability ? WebSocket is a wider deployed and recognized standard; for example in Java there is an official API (javax.websocket) and another is coming up (java.net.websocket).
I think SSE is a technically inferior solution for bidirectional web communication and as a technology it did not become very popular (no standard APIs, no books, etc - in comparison with WebSocket).
I would not be surprised if it gets dropped from HTML5, and I would not miss it, despite being one of the first to implement it in Jetty.
Depending on what you are interested in, you have to do your benchmarks or evaluate the technology for your particular case.
From the perspective of a web developer, the difference between Websockets and a REST interface is semantics. REST uses a request/response model where every message from the server is the response to a message from the client. WebSockets, on the other hand, allow both the server and the client to push messages at any time without any relation to a previous request.
Which technique to use depends on what makes more sense in the context of your application. Sure, you can use some tricks to simulate the behavior of one technology with the other, but it is usually preferably to use the one which fits your communication model better when used by-the-book.
Server-sent events are a rather new technology which isn't yet supported by all major browsers, so it is not yet an option for a serious web application.
It depends a lot on what kind of application you want to implement. WebSocket is more suitable if you really need a bidirectional communication between server and client, but you will have to implement all the communication protocol and it might not be well supported by all IT infrastructures (some firewall, proxy or load balancers may not support WebSockets). So if you do not need a 100% bidirectional link, I would advise to use SSE with REST requests for additional information from client to server.
But on the other hand, SSE comes with certain caveats, like for instance in Javascript implementation, you can not overwrite headers. The only solution is to pass query parameters, but then you can face an issue with the query string size limit.
So, again, choosing between SSE and WebSockets really depends on the kind of application you need to implement.
A few months ago, I had written a blog post that may give you some information: http://streamdata.io/blog/push-sse-vs-websockets/. Although at that time we didn't consider HTTP2, this can help know what question you need to ask yourself.
I'm evaluating the substitution of some http pooling features of my production application with the new JEE7 supported Websocket feature. I'm planning to use Wildfly 8 as my next production server environment and I've migrated some of my websockets compatible modules with good results on development time; but I have the doubt about how it will work on production and what performance will have the websockets implementation on a a high load enviroment.
I´ve been searching documentation about the most used JEE servers but the main manufacturers haven´t yet a production JEE7 enviroment and when they have a JEE7 version, they haven´t enought documentation about how the implementation works or some values of maximum concurrency users. In addition, some not official comments says websocket connections are associated "with a server socket" but this seems to be not very efficient.
We might assume the Websocket is used only for receive data from the client point of view and we assume each user will receive, for example, an average of 10 messages per minute with a little json serialized object (a typical model data class). My requirement is more like a stock market than a chat application, for example.
What´s the real performance can I expect for a Websockets use on production enviroment in Wildfly 8 Server, for example? Also I´m interested about some comparision with another JEE7 implementations you are acquainted with.
Web sockets are TCP/IP based, no matter the implementation they will always use a socket (and hence an open file).
Performance wise it really depends on what you are doing, basically how many clients, how many requests/sec per client, and obviously on how big your hardware is. Undertow is based on non-blocking IO and is generally pretty fast, so it should be enough for what you need.
If you are testing lots of clients just be aware that you will hit OS based limits (definitely open files, and maybe available ports depending on your test).
If my web application has a number of regular AJAX methods in it, but I've introduced an always-on SignalR connection, is it worth refactoring to make the regular AJAX methods be hub methods instead? Would it be faster since it's using the already-there connection?
IMHO this would be a misuse of SignalR.
Would it be faster? It really depends on several factors. The first of which is which transport ends up being used. If it's Web Sockets, then, yes, because a message will be sent over a connection that's guaranteed to already be established, but if it's SSE or LongPolling you're still doing a plain old HTTP POST every time to send messages. Second factor is that if the server is allowing Keep-Alive connections, then browsers will keep open TCP connections to the server for some period of time between requests anyway so there would be no overhead in terms of establishing a connection anyway.
Also, let's not forget our powerful friend the GET verb and all the goodness it brings in terms of one of the most important features of the web: caching. If you have a lot of cacheable data, you wouldn't want to be sending real-time messages over web sockets to fetch and retrieve that because you're basically throw out the entire infrastructure of the web if you do. The browsers can't help you any more, you'd have to build all the intelligence yourself with local storage and custom messages which would be, for lack of a better word, insane. :) You also give up the power of proxies caching public data entirely as well which is extremely underrated in terms of how much it can help performance.
My guidance is that you leave what can be simple request/response exactly the way it is today leveraging AJAX and only use a technology like SignalR for what it's intended to be: real-time communications.
Many of us have web and application servers that use plain TCP.
Some of us have web and other servers that use a secure layer such as SSL.
My understanding of SSL is that the handshaking is very computationally intensive, and the encryption of an ongoing connection is (relatively) cheap.
My assumption for you to correct: an average hosting box (and info on what is average at cloud hosting would be cool too) might easy be expected to be able to saturate its network connections with AES-encrypted packets, but have difficulty doing a thousand RSA handshakes per second. Client authentication with certificates is substantially more expensive for the server than anonymous clients too.
What kind of rules of thumb for the number of session setups per second for SSL are there?
Why not just measure? It will give you real numbers on the exact software and hardware that you are using. You'll also be able to measure the impact of changes in the server infrastructure (adding more boxes, SSL accelerators, tweaking parameters, what have you).
You are correct that you would be hard pressed to get to a thousand SSL handshakes per second on a single box. In fact, I'd say it's probably impossible. A few dozen per second, not a problem. A thousand, not without a lot of $$$.
It's also likely that you don't really need 1000 handshakes per second. That's quite a lot, and you'd already need quite a lot of traffic to need something like that: See this: What do I need in SSL TPS Performance?
Remember that normally you won't be doing new SSL handshakes all the time. Browsers do the handshake once, and keep the connection open over a number of requests and/or page views, so your needs for handshakes per second may be much lower than you think.
As Ville said there is no real option then to try it out on your configuration. But don't underestimated the symmetric encryption of data after establishing a link. It might be less expensive but if you are going to download a lot of data over the encrypted channel than it might cost a lot more than the initial negotiation.
So for this you have to build a common scenario for the usage of your site and then stress test.