Description
There is an Application Server which apparently dies with OutOfMemory Exception. It has been determined that App Server is not scalable at all because it needs one thread per user so that means 1000 user sessions will consume 1000 threads, holding on to 1GB of virtual memory with 30% cpu spent in Interrupt so yeah you hear the story right.
I came across this issue and the adopted solution which I think is worth mentioning.
The next thing I heard App Server has been split into 2 Application Server and the 2nd process contains user’s session consuming all the threading resources. One of the idea behind this architecture was to give each process 2GB of virtual address space. And on top of that, both the app servers need to be up and running in order to serve a request. And on top of that, no client is consuming services from the 2nd app server. Another point to note is, application server in question is a very simple application server with no algorithmic complexities, but rather act as a middle man processing the request with some caching and data manipulation.
Really ?? We all know that process isolation provides stability and reliability with fault tolerant architecture but at the same time they don’t depend on each other.
With the above architecture they didn’t only introduce latency because of inter process communication but the real issue which is one thread per user with user mode default stack size consuming 1 MB of virtual memory never got resolved.
If you are implementing process isolation because of the above reason, just don’t do it. This is the time to rethink and redesign your application server to make sure that your application server is scalable to support 1000 users without consuming 1000+ threads
