> its just a matter of numbers. If you use sticky sessions with round > robin > new session creation > it is very common that the load would be exactly the same over all the > servers. It's more common that it wouldn't. One group of 25 users probably has a very different level of activity than a different group of 25.
no this is not more common.. because the total of 50 users was round robin assigned to different servers (lets say 2). Then it is very unlikely that just that 25 users of that one server are very busy and the other 25 of that other server not that is just math.. for example 4 servers and we get 1000 session , every server gets 250 sessions to handle then if of those 1000 session 150 sessions are very busy. That it is very likely that those are evenly divided over the 4 servers (just calculate the probability!) How bigger the numbers of session and how more equally divided it will be. If after a while of those 1000 session 300 will be terminated again it is very likely that that is evenly divided over the 4 servers. So after 1000 new sessions round robin created over 4 servers then randomly 400 terminate then i think that in a small bandwidth all the servers would be around 150 active sessions. How many times will a well balanced coin fall on the head and how many times on the tail?
The memory advantage goes to non-sticky sessions because there is no session replication -- only a separate, central store. Each server only has the sessions in memory for the requests it is serving at a given moment. After the request, the session is eligible for GC.
yes but that has the overhead again of serialization every time. And syncing over servers (done through database) And you have a single point of failure.
A server that's waiting due to session locking can handle requests for any other session, so I don't think it makes a net difference. If it wasn't for Wicket requiring session locking (?), multiple servers could handle requests for the same session simultaneously.
no, wicket can handle many request at the same time Resource request for example where always already possible. In a none sticky in wont. And now we relaxed the syncing on the session. We only lock on the pagemap of a page. So a popup or another tab can do the same thing. So if you access the same page or another page in the same pagemap twice we will block the rest can go concurrently.
I think in all the web frameworks that are really session based. > none sticky sessions don't have any advantages only drawbacks. > At least i haven't heard any single advantages yet in the current > thread. > > johan Well you have to give me points for trying ;)
keep shooting :) johan
