Poor Performance of Sun One Web Server 6.0 SP6

Question

We are running on an E450 with 2GB of memory, Solaris 8 2/02 with Recommended and Security Patch Cluster from 31 Jul 03, Sun One Web Server 6.0 SP6, Macromedia ColdFusion 5, JDK 1.4.1_02. We are seeing intermittent (three or four times a day) performance problems, extremely poor response time.
A vanilla, �test� iPlanet web server was put up on port 2443 with https turned on and off. Repeated control tests on file operations (�copy link as�) showed similar results as those described in High Impact above. Changes to add KeepAlive parameters (in magnus.conf) showed no noticeable improvement.
Tests were conducted -- on the test server -- accessing the same file from two clients, one a thin client (TC), the other a Unix workstation (UW).
Results:
1) Sometimes process TC was started first and continued normally while process UW hung up; when this happened, only one httpd process was building cpu time;
2) Sometimes process UW was started first and continued normally while process TC hung up; when this happened, only one httpd process was building cpu time;
3) Sometimes both process TC and process UW continued normally regardless of which was started first; when this happened, two different httpd processes were building cpu time together;
Speculation on Process Management - speculation is that, in the case of the 3rd bullet above, iPlanet assigned different httpd processes to the two requests. In the case of the first two bullets, however, the belief is that iPlanet actually assigned the second request to the same process it had previously assigned the first request. In this case, the second request was left to wait. It appears that most of the work done by httpd children is performed by only two or three children, even when there are 10 available.
Questions;
Why are the other httpd children are not more fully utilized?
What about changing the number of Acceptor Threads?
Could turning on Native Polling help (UseNativePoll in magnus.conf)?
Any other thoughts about what is going on or how to fix the issue?
Thanks for any assistance
Excerpt from /etc/system
* Web Server and ColdFusion Setting
set shmsys: shminfo_shmmax = 2147483647
set shmsys: shminfo_shmmin = 1
set shmsys: shminfo_shmmni = 100
set shmsys: shminfo_shmseg = 50
set semsys: seminfo_semmns = 1750
set semsys: seminfo_semmni = 70
set msgsys:msginfo_msgmax = 65535
set msgsys:msginfo_msgmnb = 65535
set msgsys:msginfo_msgseg = 8192
set msgsys:msginfo_msgssz = 16
* Default is 512, which handles several thousand connections
*set tcp:tcp_conn_hash_size=262144
* Do not set to 0 in solaris 8 on Production Systems
*set sq_max_size=0
set rlim_fd_max=8192
set rlim_fd_cur=8192
* END of Web / ColdFusion Settings
Excerpt from /etc/rc2.d/S69inet
## Web Server and ColdFusion Settings
# Comment out tcp_slow_start_initial, because default is 4
#ndd -set /dev/tcp tcp_slow_start_initial 2
ndd -set /dev/tcp tcp_xmit_hiwat 32768
ndd -set /dev/tcp tcp_recv_hiwat 32768
ndd -set /dev/tcp tcp_conn_req_max_q 1024
ndd -set /dev/tcp tcp_conn_req_max_q0 4096
ndd -set /dev/tcp tcp_time_wait_interval 60000
ndd -set /dev/tcp tcp_keepalive_interval 900000
# Comment out next 4 to accept default
# - change only if tcp longer than 10 seconds expected
#ndd -set /dev/tcp tcp_ip_abort_interval 60000
#ndd -set /dev/tcp tcp_rexmit_interval_max 10000
#ndd -set /dev/tcp tcp_rexmit_interval_initial 3000
#ndd -set /dev/tcp tcp_rexmit_interval_min 3000
# Left out changing ephemeral (short lived) port
#ndd -set /dev/tcp tcp_smallest_anon_port 1024
# Keep default of 1480576
#ndd -set /dev/tcp tcp_cwnd_max 65535
## End of Web / ColdFusion Settings
Excerpt from magnus.conf
RqThrottle 1
MaxProcs 10
StackSize 131072
## Added for lightly loaded systems
KeepAliveQueryMeanTime 1
KeepAliveQueryMaxSleepTime 0

Answer 1

Because the security context is set as a process context, the NSAPI thread locks the process prior to setting the security context. The older NASPI plugin that we are using is not reentrant, it will not work with the mulitthreading model. Under multithreading each thread would have access to the security context of each thread.