On Fri, May 12, 2017 at 10:46 AM, Willy Tarreau <w...@1wt.eu> wrote: > On Fri, May 12, 2017 at 10:20:02AM -0700, redundantl y wrote: > > As I've said before, the issue here is these objects aren't hosted on the > > same server that they're being called from. > > > > "A separately hosted application will generate HTML with several (20-30) > > elements that will be loaded simultaneously by the end user's browser." > > > > So a user might go to www.example.com and that page will load the > objects > > from assets.example.com, which is a wholly separate server. > > OK but *normally* if there's parallelism when downloading objects from > assets.example.com, then there's no dependency between them. > > > > The principle of stickiness is to ensure that subsequent requests will > go > > > to the same server that served the previous ones. The main goal is to > > > ensure that all requests carrying a session cookie will end up on the > > > server which holds this session. > > > > > > Here as Lukas explained, you're simulating a browser sending many > totally > > > independant requests in parallel. There's no reason (nor any way) that > > > any equipment in the chain would guess they are related since they > could > > > arrive in any order, and even end up on multiple nodes. > > > > > > > > Well, all of these requests will have the url_param email=, so the load > > balancer has the ability to know they are related. The issue here, at > > least how it appears to me, is since they come in so fast the stick-table > > entry doesn't get generated quickly enough and the requests get > distributed > > to multiple backend servers and eventually stick to just one. > > It's not fast WRT the stick table but WRT the time to connect to the > server. > As I mentionned, the principle of stickiness is to send subsequent requests > to the same server which *served* the previous ones. So if the first > request > is sent to server 1, the connection fails several times, then it's > redispathed > to server 2 and succeeds, it will be server 2 which will be put into the > table > so that next connections will go there as well. > > In your workload, there isn't even the time to validate the connection to > the > server, and *this* is what causes the problem you're seeing. > > Thank you for explaining what I'm seeing. This makes a lot of sense.
> > Since changing to load balancing on the url_param our issue has been > > resolved. > > So indeed you're facing the type of workloads requiring a hash. > > > > Also, most people prefer not to apply stickiness for static objects so > that > > > they can be retrieved in parallel from all static servers instead of > all > > > hammering the same server. It might possibly not be your case based on > your > > > explanation, but this is what people usually do for a better user > > > experience. > > > > > > > > The objects aren't static. When they're loaded the application makes > some > > calls to external services (3rd party application, database server) to > > produce the desired objects and links. > > OK I see. Then better stick to the hash using url_param. You can improve > this by combining it with stick anyway if your url_params are frequently > reused (eg: many requests per client). This will avoid redistributing > innocent connections in the event a server is added or removed due to > the hash being recomputed. That can be especially true of your 3rd party > application sometimes has long response times and the probability of a > server outage between the first and the last request for a client becomes > high. > > Thank you for pointing this out, we hadn't considered this scenario. > > > In conclusion, your expected use case still seem quite obscure to me > :-/ > > > > > > Willy > > > > > > > I agree, our use case is fairly unique. > > It looks so :-) > > Willy > Thanks for taking the time to read and respond. It was very informative and helpful.
