[prasadw 96/06/13]

When ask Jeeves (the Java server) to do 120 HTTPops/sec on an Ultra 140, it
delivers 120 HTTPops/sec. But when we ask it to do 150 HTTPops/sec the
performance degrades drastically to 60 HTTPops/sec. The syscall rate (per sec)
as shown by vmstat is 15000 (normally each HTTPop requires 100 syscalls,
so the rate should be 6000). Truss output reveals that most of the system calls
are of the form getcontext and setcontext.

We need to see if this problem is Solaris green thread specific.

I observed similar problems on the client side. Please see message below.

From prasadw Sat Jun 8 18:04:13 1996
To: pavani, dac, brown, lindholm
Subject: java.net client side performance
X-Sun-Charset: US-ASCII
Content-Length: 873

I have been trying to port webperf to java. The directory is:
/net/haven/prasadw/serverperf

With the C version my system (Ultra 170) can generate > 200 ops/sec.
With the Java code my system (Ultra 170) could not generate > 50
ops/sec. The CPU on my system (the client) was the bottleneck. The
server CPU wasn't the bottleneck. Is there some overhead we can avoid
or is JIT the only solution?

Also once I asked the client to generate 60 ops/sec, the java process
freaked out and started executing an inordinate no of calls of the form:
getcontext(0xEE361E28)
setcontext(0xEE2D1E28)
This behavior is observed in the server as well when it is overloaded.
This may be a problem with green threads. We need a working version of
Solaris native threads to see if this solves the problem.