You could probably accomplish this with STunnel.  (run stunnel aside
pound to do the SSL communication, and use a 'cleartext' backend in
pound)

Joe
[...]
Pound[...]
pound(at)apsis.ch.[...]

Thanks, I've done in this way.


Joe Gooch wrote:
[...][...][...][...][...][...][...]

Am Donnerstag, 6. Oktober 2005 12:46 schrieb Mark Reynolds:[...]

I suggested something in that direction before, and as I was just hit by 
indifferently loaded server I would like to support your thoughts. I think it 
would be extremly helpful if pound could select the next backend also on 
dynamic information. Obviously, pound sees every incoming request, as well as 
every outgoing response of each backend. What if pound would count how many 
that is, and what the in/out ratio is? If the ratio of a backend gets worse, 
and/or the answering time goes down, reduce the sending of request to that 
one to one of the others with better numbers.

I also think that the ha_port check should not only test for "on" or "off", 
but also if there is a reaction in a certain amount of time. Typical problem 
on zope servers: they have their listen port open, but in some situations 
aren't able to answer a request/connection on their port (to be more precise, 
it might take very long). However, pound assumes such a backend to be in 
business, which slows the whole balenced system down (and visitors keep 
waiting for a response or get timeout errors eventually).


Cheers,

Sascha
[...]

We are planning to use pound in a much simpler manner, we will have all 
http requests from clients going first to pound, that will load balance 
between our two squid proxies which in turn are acting as proxies / load 
balancers for all our webervers.

Our pound instance is running on a HA cluster (live, and hot standby) so 
we can tolerate failure of the pound box, then either of the proxies and 
any number of webserver failures without any loss of service

Least that's the theory, will let your know in a few weeks how we got on
[...]

You don't mention what kind of session affinity you have configured... I
only mention this because your key problem seems to be with session affinity
- and pound offers several types...
 Personally I would think that a session type of "IP" (because a hashed
lookup should be the fastest) would be a reasonable compromise for high
performance against equal balance in order handle peak loads the best on a
modest server.
 The drawback is "if" you have lot of users from a single IP, then your
cluster will not be 'perfectly' balanced. i.e. some backend servers will
have to handle more load than others.
 We have 10 times your traffic _average_ by the way on a _very_ modest
(single CPU) server and no problems whatsover :-)
 /David

 On 10/28/05, Russell Valentine <russ(at)altec.org> wrote:[...]


--
Regards,
David Walters

Ohh sorry, yes I use session type of "IP". After I sent the email I
noticed I was reading the log files wrong and that the file descriptor
and thread count was not representative when we would see the problem.
So far I hadn't seen the problem since I've been keeping track of that
(two days). We get more load the beginning of the week, so I'll get new
numbers including request rate at that time.

Since you apparently seem to not have any problems if I don't find some
obvious solution then (like file descriptors) then I'll recheck the
application, however it was two separate applications that had been
observed to have this happening.

Thanks for your reply!


Russell Valentine

david walters said the following on 10/28/2005 12:52 PM:[...]

I would also check the syslog for any backends timing out on requests, that
would push users to another backend. Also, if you have run out of file
descriptors you would surely see "too many open files"
 By the way it's also worth mentioning that if you don't solve this problem
through pound, there is another solution which is to implement session
replication accross your backend - then you would also never lose a session
even if that backend timed out or went down.
 /David

 On 10/29/05, Russell Valentine <russ(at)altec.org> wrote:[...]


--
Regards,
David Walters