Hi Willy.
First, thank you for your answer.
> I really don't know why you're limiting on the number of requests
> per second. It is not the proper way to do this at all. In fact,
> you should *only* need to play with the server's maxconn parameter,
> as there should be no reason your servers would be sensible to a
> number of requests per second.
I don't know why limiting number of requests per second wouldn't be
proper way to limit the traffic?
During high load, we can get few thousand requests per second. Servers
can't handle that. If I only set max connections for every server, they
won't even get there. With for example 50 new connections at the same
time per server, I think they will die before reaching the limit.
The thing is we usually have events that start at a certain time and
users know that. The event is also disabled until that time so sometimes
we really get huge amount of connections at the beginning.
If there is some mechanism inside HAProxy, that would help us survive
such cases, please let me know.
Besides, the contractor thinks that getting waiting room is better user
experience than waiting for site to open.
That is why I wished to let certain amount of people to site and show
everybody else waiting room.
> Well you could use cookies to know if a user has a sesion on the site or
> not, but it's still not the right solution.
>
> > Can someout with more experience than me advice what would be the best
> > way to handle this?
> >
> > I would like to limit number of current users on real servers and amount
> > of new connections that can be created per some time unit.
>
> This is the point I cannot agree with. I think you need to limit the
> amount of concurrent connections on your servers. Otherwise, your
> application is deadly broken, but that's not how you introduced it
> first :-)
If deadly broken means it does not take care of connection limiting,
then it is deadly broken.
Application does not do any limiting, servers do when they stop
responding :)
I would like HAProxy to help me with that as much as possible.
> This is precisely where the splitting of the backend helps. Assuming
> that your servers can handle, say, 200 concurrent connections, you
> split your backends either per application or per application group
> (you might want to guarantee a quality of service for a group of
> applications). Then you adjust each server's maxconn so that the
> total does not exceed the real server's maxconn (=MaxClients on
> apache). That way, even if an application takes a lot of resources,
> it will not saturate the server. Also, just enable health-checks
> in one backend and configure the other ones to track the first one,
> it will greatly reduce the number of health-checks sent to your
> servers.
If our servers handle can 200 concurrent connections and I limit all
sites so that the total doesn't exceed that, I have to limit each site
to about 5 concurrent connections (about 40 sites at the moment). That
means that instead of using as much resources as possible, the site with
the most traffic would be using 5 connections only.
Am I right?
I am thinking about fullconn option now and since we make sure that
there is only one site having high traffic at the moment, I might be
able to use that?
Thank you and best regards
Bostjan
