Filter
Top Products
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 eld on the conguration'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 species 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 conguration.
Reaching the maximum number of congured 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 overowing 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 nishes
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 les 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 dene this timeout period using the IO Timeout setting on the
conguration'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.
UsingMonitoringDatatoTuneYour Server
SunJavaSystemWebServer7.0Update1 PerformanceTuning,Sizing,and ScalingGuide •58