Why not try a connection pool, where a number of connections are kept open to hosts up to a certain limit. If a new connection is needed for a host then an existing connection is closed and re-used. Use a simple LRU policy. The number of connections to pool should be configurable, as different environments will have different requirements. Cheers CM Gustavo Rahal wrote:
Hi All
I did a small xmlrpc webservice that basicly expose some methods to interact (run commands, for example) with a lists of UNIX servers. At startup, the webservice connects via ssh to all the UNIX servers (currently 16) and leave the connections open waiting for requests from clients. The app was designed mostly as a way of learninig how to use twisted ssh modules, deferreds etc...
Some questions (I'll try to be brief):
1) At startup, the ssh connections to the UNIX servers goes as far as the client connection step ( connection.SSHConnection) and are kept open. So, each time a client requests (via xmlrpc) a shell command to run, the webservice opens a channel to this server (channel.SSHChannel) runs the command, gets the output and closes the channel.
Would it be better to leave a channel open so there is no overhead of openning a channel each time there is a command to run? What are the pros and cons?
2) Supposing that the number of servers grow, how many simultaneous ssh connections is a reasonable amount?
Let's say a Pentium III 500MHz with 1 GB RAM and a 4 Mbits link. What is a reasonable amont? 0-50, 50-100, 100-150?