Today I've been message by my campus friend, asking an advice for tuning a SJAS. How many threads should he have for servlets, how many MDBs, and how many database connection in the pool.
He set the number for 1024, 128. Hmm. Very big. I asked him, how much memory and processor resources and app server instances do you have. The answer was shocking:
1 processor, 1 gigabyte, 1 instance
As far as I can remember, on a WebLogic they recommend to use less than that number of threads for best practices on each instances. Wow, and we were talking about WebLogic 8.1 instance in a UltraSPARC-IIIi Solaris 9 boxes with 8 gigs of memory!
I thought there must be something else happening. For just 1 processor, processing many threads is actually a waste of time in the context switching. I think it should not be like that. There something wrong when the system. It is already out of resource and the queue piles up. It must be some kind of resource starvation. Some resource may not be released during the process. Some resources are held for longer than it should be.
Then I remembered that I have had encountered some problems here.
The HTTP/1.1 Protocol has been there for such a long time. But there are some behavior most programmers still don't know.
The HTTP/1.1 differs from HTTP/1.0 that it implements persistent connection by default. The HTTP/1.1 will not be closing its connection after your client application exits. Your browser or client application by default will maintain HTTP connection until time out period elapsed. Before time out period, the connection is still up, and whenever you need to make more requests your browser or your HTTP client application will reuse the HTTP connection when possible, thus eliminating the overhead needed to setup such connections. The browser application makers have been doing their job very well it is transparent for us to such happenings in the protocol.
Remember I said 'by default', because you can explicitly asks the server (by adding a header field) to close the connection once the request has been fulfilled.
This is the thing that you need in your HTTP header.
Connection-Close: close
He set the number for 1024, 128. Hmm. Very big. I asked him, how much memory and processor resources and app server instances do you have. The answer was shocking:
1 processor, 1 gigabyte, 1 instance
As far as I can remember, on a WebLogic they recommend to use less than that number of threads for best practices on each instances. Wow, and we were talking about WebLogic 8.1 instance in a UltraSPARC-IIIi Solaris 9 boxes with 8 gigs of memory!
I thought there must be something else happening. For just 1 processor, processing many threads is actually a waste of time in the context switching. I think it should not be like that. There something wrong when the system. It is already out of resource and the queue piles up. It must be some kind of resource starvation. Some resource may not be released during the process. Some resources are held for longer than it should be.
Then I remembered that I have had encountered some problems here.
The HTTP/1.1 Protocol has been there for such a long time. But there are some behavior most programmers still don't know.
The HTTP/1.1 differs from HTTP/1.0 that it implements persistent connection by default. The HTTP/1.1 will not be closing its connection after your client application exits. Your browser or client application by default will maintain HTTP connection until time out period elapsed. Before time out period, the connection is still up, and whenever you need to make more requests your browser or your HTTP client application will reuse the HTTP connection when possible, thus eliminating the overhead needed to setup such connections. The browser application makers have been doing their job very well it is transparent for us to such happenings in the protocol.
Remember I said 'by default', because you can explicitly asks the server (by adding a header field) to close the connection once the request has been fulfilled.
This is the thing that you need in your HTTP header.
Connection-Close: close
No comments:
Post a Comment