Recently I was in Jakarta on a client visit. While having breakfast at Century Park Hotel alone, I let me imagination wander. Breakfast there is buffet system, where guest can have multiple rounds of food items in fresh plates. Waiters clear up tables quickly after a guest has left to take another round. Next time guest may sit on the same table or in another free table.
One day it was peak time for breakfast and I was not getting a free table to occupy.I realized the situation is very similar to having a sticky versus non-sticky servers. I drew a comparison between a typical web application deployment and breakfast lounge. A hotel guest is same as the user of web app. Tables are like system memory. It gets fragmented when no. of guests occupying a table is less than it’s maximum capacity. It becomes sticky when guest wants to return to the same seat after taking next round of food. An abandoned session is similar to a guest going for next round and leaving used plat on previous used table. Waiters were no less than CPU doing garbage collection, clearing abandoned session to make room for new guests. User think time is comparable to time taken by a guest to think about next round, get it prepared and be ready to submit request i.e. find a table.
May be I was thinking too much, but I found tuning the application for peak loads is also comparable to how to deal with peak hour situations in this scenario. If you have limited memory(tables) then at the cost of frequent garbage collection(waiters clearing up tables), situation can be very well managed.
On the other hand, for non-peak hours, a sticky server(dedicated table for each guest) would be better. You can reduce the frequency of clearing up tables, and still sustain without any impact to end user experience. Though I have not seen a real application which can learn and adjust itself based on load, but wouldn’t it be nice to have such things in place?