In SSL there are connections, and there are sessions.
A connection starts with a handshake, and ends when either party states it by sending a
close_notify alert message. Typical Web browsers and servers will maintain connections open for some time, closing them after one or two minutes of inactivity; one or several HTTP requests and responses are sent over that connection. In normal HTTPS contexts, there is a one-to-one mapping between the SSL connections and the underlying TCP connections: for each TCP connection (to port 443), there will be a single SSL connection, and when the SSL connection ends, the underlying TCP connection is closed.
A session relates to the asymmetric cryptography which occurs in a "full handshake". The handshake process, which occurs at the beginning of a connection, is about establishing the cryptographic algorithms and keys which will be used to protect the data for that connection. There are two sorts of handshakes:
The full handshake is what a client and server do when they don't know each other (they have not talked previously, or that was long ago). In the full handshake, certificates are sent, and asymmetric cryptography (RSA, Diffie-Hellman...) occurs.
The abbreviated handshake is what a client and server remember each other; more accurately, they remember the algorithms and keys that they established in a previous full handshake, and agree to reuse them (technically, they reuse the "master secret" and derive from it fresh encryption keys for this connection).
A connection with a full handshake, and the set of connections with abbreviated handshake who reuse that full handshake, constitute together the session.
The abbreviated handshake is more efficient than the full handshake, because it implies one less network round-trips, smaller handshake messages, and no asymmetric cryptography at all.
For performance, in all generality, you want the following:
Keep connections open as much as possible. An "open connection" uses a few memory resources (both parties must remember the keys) and system resources (for the underlying TCP connection, which is kept open). However, there is no network traffic involved in keeping a connection alive, except possibly the optional "TCP keepalive".
When connections cannot be kept open (e.g. to free system resources), it is best if the client and server remember sessions so that they may do abbreviated handshakes if they reconnect. Web servers have various default and configurable policies. For instance, Apache (with
mod_ssl) uses a cache which is defined both for size and for duration; the server "forgets" a session when either its cache is full and it needs some extra room, or when the timeout has been reached, whichever condition occurs first.
If you have control over the servers' configuration, then you may want to increase the "inactivity timeout" for connection termination, and also to increase the session cache size and duration. If you do not have control over the servers, then your question is somewhat moot: whatever you do, it will have to be compatible with what the servers offer. You can somehow force a server not to forget a session by regularly opening a new connection with an abbreviated handshake, but that is not necessarily a good idea (usually, when a server forgets sessions, it is for a more-or-less good reason).
Anyway, you shall make measures. This is a question about performance; abstract reasoning cannot give definitive answers. The usual rule of thumb is that performance issues do not exist until they have been duly measured in real life, or at least in a reasonably representative prototype system.
In any case, it is hard to obtain the same security functionalities of SSL with a smaller cost. Replacing SSL with "something custom" is unlikely to provide much improvement performance-wise without sacrificing security in some way.
For a walk-through of SSL, see this answer. Having some knowledge of the SSL internals really helps a lot in thinking about any design involving SSL.