The equivalent information as the Total Number of Threads is available through the Admin
Console from the Monitoring tab
⇒
Instances sub tab, under General Statistics. To see the
maximum threads allowed, see the Maximum Threads field on the configuration's Performance
tab
⇒
HTTP sub tab, under Thread Pool Settings.
To get the equivalent of the
perfdump Active Sessions
, you can subtract the Number of Idle
Threads from the Total Number of Threads.
Maximum Threads (Maximum Simultaneous Requests)
The maximum threads setting specifies the maximum number of simultaneous transactions
that the Web Server can handle. The default value is 128. Changes to this value can be used to
throttle the server, minimizing latencies for the transactions that are performed. The Maximum
Threads value acts across multiple virtual servers, but does not attempt to load balance. It is set
for each configuration.
Reaching the maximum number of configured threads is not necessarily undesirable, and you
do not need to automatically increase the number of threads in the server. Reaching this limit
means that the server needed this many threads at peak load, but as long as it was able to serve
requests in a timely manner, the server is adequately tuned. However, at this point connections
queue up in the connection queue, potentially overflowing it. If you monitor your server's
performance regularly and notice that total sessions created number is often near the maximum
number of threads, you should consider increasing your thread limits.
To compute the number of simultaneous requests, the server counts the number of active
requests, adding one to the number when a new request arrives, subtracting one when it finishes
the request. When a new request arrives, the server checks to see if it is already processing the
maximum number of requests. If it has reached the limit, it defers processing new requests until
the number of active requests drops below the maximum amount.
In theory, you could set the maximum threads to 1 and still have a functional server. Setting this
value to 1 would mean that the server could only handle one request at a time, but since HTTP
requests for static files generally have a very short duration (response time can be as low as 5
milliseconds), processing one request at a time would still allow you to process up to 200
requests per second.
However, in actuality, Internet clients frequently connect to the server and then do not
complete their requests. In these cases, the server waits 30 seconds or more for the data before
timing out. You can define this timeout period using the IO Timeout setting on the
configuration's Performance tab
⇒
HTTP Settings page. You can also use the command
wadm
set-http-prop
and set the
io-timeout
property. The default value is 30 seconds. By setting it
to less than the default you can free up threads sooner, but you might also disconnect users with
slower connections. Also, some sites perform heavyweight transactions that take minutes to
complete. Both of these factors add to the maximum simultaneous requests that are required. If
your site is processing many requests that take many seconds, you might need to increase the
number of maximum simultaneous requests.
Using Monitoring Data to Tune Your Server
Sun Java System Web Server 7.0 Update 1 Performance Tuning, Sizing, and Scaling Guide •
58
Summary of Contents for Sun Java System Web Server 7.0
Page 9: ...Figures FIGURE 2 1 Web Server Connection Handling 40 9 ...
Page 10: ...10 ...
Page 18: ...18 ...
Page 38: ...38 ...
Page 84: ...84 ...
Page 100: ...100 ...
