Using the Terminal api at scale

[russellgower]

Hi,
I'm looking at the feasibility of replacing our SSH clients with a web page containing an embedded terminal app, are there any know scalability constraints that would pose any issues with up to 1200 concurrent sessions?

Thanks
Russ

[martinpitt]

I am not aware of anyone ever having tried -- but given the general overhead (mostly memory for "quiet ssh", but also CPU still) of browsers, JS, networking, and channeling all of that through a single TCP connection to cockpit-ws, it would really surprise me if 1200 concurrent sessions was even remotely possible or useful.

[russellgower]

Thank you for your response. Currently 1200 Putty/ssh sessions work fine so the server can cope with the load.
I'm not sure I quite understand what you mean about a single TCP connection, these would be going from different browsers although each user does open multiple sessions so I would think there would be somewhere in the region of 500 TCP connections. But I get what you mean about a single cockpit-ws. Does the cockpit architecture allow for running multiple instance of cockpit-ws perhaps behind Nginx?

Otherwise I guess my other option is build my own solution with xterm.js and a javascript ssh client library.

[martinpitt]

You can run as many cockpit-ws instances as you like, either from the package or the container. But of course if you want all of them to appear on the same domain/port, you'll need some kind of reverse proxy/load balancer.

However, I initially misunderstood your question -- I thought you wanted to have one browser session with connections/terminals to 1200 servers -- that's the kind of scale that will just explode browsers/RAM/CPU. But it seems you want the other way around -- 1200 clients with a single terminal widget, all connecting to a single server.

That is much more realistic. Still, we haven't tested this scenario, but it does not seem out of the question that a single cockpit-ws could handle this, provided the server has enough RAM/CPU to actually sustain 1200 parallel user logind sessions. But ssh/putty create exactly the same sessions, so you already asserted that part.

[martinpitt]

Please note that there is an alternative solution: Your clients could use either the Cockpit Client flatpak app or cockpit-desktop (with a custom .desktop file to provide easy access from the desktop's menu). Then the web server would run on the client side, in a network sandbox; and the server only needs the normal SSH server, which you already have.

This is by far the most secure and scalable architecture. However, it only works for Linux clients, if you have Windows/MacOS clients then you need to run cockpit-ws somewhere else (on the server, or somewhere "in the middle").

[russellgower]

The solution needs to work with Windows clients, but It sounds like it's worth me investing the effort to do a proof of concept implementations.

Thanks
R.