A telephone session lasts as long as a phone conversation, and so if you have a Java app behind the SIP, it's going to have a lot of objects who lifecycle is tied to the length of a phone conversation. Thus these objects will survive a lot of minor collections in a generational collector and be promoted to an old(er) generation.
This causes two big problems. First, most collectors are copy collectors, so they copy the survivors of the collection. If you have a lot of survivors, then you have a lot of copying and this is really slow. The next problem is even more insidious. Lots of objects wind up in older generations that are collected infrequently. So you run out of space, wind up with failed minor collections, and trigger full stop-the-world collections.
So generational collectors are poor choices for SIP systems, so what? Well the S in SIP is for session, and their concept of sessions is quite similar to a web session. So you could see the same behavior in a web application that stores a lot of data in a session. Anything that lives in "human" time is going to considered long lived in JVM time. So if you have a web application with a lot of data in session, it could be a pretty poor fit to a generational collector.
Now there are a lot of truly short lived objects in a web application as well. A lot of things are only around for the duration of a request. So that would make a web application a much better fit for a generational collector. Basically the less you keep in session, then your web app will be an even better fit for a generational collector.
No comments:
Post a Comment