2

In choosing to adopt Websocket as the real-time technology behind a web application for my company, I'm trying to determine what the server workload will be.

So far as I understand Apache internals, I believe an Apache process or thread will be kept alive during an entire Websocket session proxying the connection with mod_proxy_wstunnel; Will that same process also handle the traditional client http requests? Or will another process be 'wasted' fielding those requests as they arrive?

Some Dude
  • 83
  • 2

1 Answers1

2

It all depends on how your web application is designed. You can indeed pass "traditional http requests" through an established websocket... or you can process the request in the more traditional method. Unfortunately (from a sys-engineer's perspective) developers are lazy... and rarely go through the effort necessary to pass the bulk of traffic through an established websocket. It is more typically used to announce "updates" to various bits on the page... and the work of pulling image-data and whatever else is left to the more typical GETs and POSTs.

In short... yes... you'll tie up 1 process during the lifetime of each websocket... and 1 connection for each request. You can, however, make use of connection keep-alives to recycle the same connection over & over... but this may affect the overall page load time, as you must wait for each item to be sent serially instead of in parallel.

This is where the rubber-meets-the-road when it comes to Apache. You can change the Multi-Processing Module (MPM) to change how those keep-alive connections are handled... as well as a lot of other things to tweak the overall performance.

Despite all the fine-tuning you can do to Apache... sometimes it is not the perfect-tool for the job. Apache is the swiss-army knife in the toolbox. It is designed to be the most dynamic tool in the toolbox. Nginx is more streamlined, and doesn't include the tweezers or scissors options that you'll find in the apache-knife... and nodejs is just a butter-knife. Sometimes (when the environment allows) it is best to mix & match to get the benefits of all of them.

TheCompWiz
  • 7,349
  • 16
  • 23
  • You're super close to answering my question. Does the same process handling the Websocket proxy also handle the traditional content requests from the client, or the GETs and POSTs as you put it? I might also be missing a point in my mind regarding the mechanics of Websockets and browsers, i.e., a web page transition necessarily kills any javascript execution in the previous page, and I assume kills the Websocket too. Maybe I'm overthinking – Some Dude Sep 01 '16 at 05:46
  • Yes... websockets get the same treatment as any other connection as far as apache is handling it. There are some optimizations that can be applied... but essentially... it's the same. Ideally... when using websockets... you wouldn't have page-transitions per-se... You would dynamically update the current page... keeping the connection open the whole time. IF you transition to a different page... yes... that would kill the connections. – TheCompWiz Sep 01 '16 at 17:13
  • Sounds good. Thank You. Generally, my web app uses AJAX for same-page content loading, and 'shall' use WebSocket for pushed content (superior option to AJAX long-polling even if a contrived solution on the server-side). Bottom line: AJAX for user requested content, WS for pushed content. – Some Dude Sep 01 '16 at 18:29