Sunday, September 25, 2005

Compression in Tomcat works well

...but my hopes to slow down my server by forcing it to compress the content were shattered again. My old rusty Athlon 1600+ based notebook is just tooo weak to generate enough load. So, from now on I have to tweak the load. BTW, compression impact: on a 50k html file, bandwidth savings are approximately 4-fold, and so are extra expenses in terms of CPU utilization. To enable compression JMeter needs to supply the usual header "Accept: gzip, deflate" in HTTP Header Manager.

JMeter, Another lesson (cookie manager)

So, I haven't given up on load-testing Tomcat on my hardware (w1100z). It just moves quite slowly. If a small detour is allowed here... a-ah, what the heck! Installed Windows XP Pro 64 bit edition, with 64 bit JRE to match. Win keeps on loosing keyboard and mouse. My current workaround is to boot machine with mouse and keyboard unplugged, and only plug when login screen is seen. Another thing I learned today was that I unnecessarily been stressing Tomcat and JVM it's running on by not having Cookie Manager in my test plan. The result was that for every request to the server a new session would be created. These sessions would, ultimately, flood the memory and adversely and unrealistically decrease performance, especially when throughput is high. Sigh... good thing or two is learned every time, but no solid results produced yet.

Tuesday, September 20, 2005

Apology: did not get the irony

Yep, must admit i misunderstood the situation that I'd described before. Those posters were simply expressing their dissapointment with authors who had them lose some of their precious time, albeit expressed that in an unusual and intriguing way. Another example that made me change my mind: an article about Intel's breakthrough in containing current leakage. Someone by nickname "harbi" posted just as considerate and thoughtful comment. I'd quote it, even: "Excellent article and a job well done." Who are these posters?

Monday, September 12, 2005

First results: puzzling

Guess my JSP is built extremely unfairly as far as our production servers are concerned. I'll just put it right here, for future reference.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<%@ page import="java.io.IOException,
java.text.NumberFormat,
java.text.DecimalFormat"
contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head><title>Simple jsp page</title></head>
<body>
<%!
int delay = 300;
int size = 100/* 4 * 256 */;
int load = 100; /* number of heavy operations
taking significant CPU and
some time to execute */
long tempLoadVar;
static int LOAD_ITERATIONS = 1000000;
%>

<%
if (request.getParameter("delay") != null) {
delay = Integer.parseInt(request.getParameter("delay"));
}

if (request.getParameter("size") != null) {
size = Integer.parseInt(request.getParameter("size"));
}

if (request.getParameter("load") != null) {
load = Integer.parseInt(request.getParameter("load"));
}
%>

<%
outputSome(out);
sleepAbit();
workSome();

outputSome(out);
sleepAbit();
workSome();

outputSome(out);
sleepAbit();

outputSome(out);
sleepAbit();
%>

</body>
</html>
<%!
/** Sleep for just a bit.
* Expect to sleep 4 times while page executes. */
private void sleepAbit() {
try {
if (delay != 0) {
Thread.sleep(delay/4);
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}

/** Output part of the content. 4 chunks per page. */
private void outputSome(JspWriter out) throws IOException {
NumberFormat format36 = new DecimalFormat();
format36.setMinimumIntegerDigits(36);
format36.setMaximumFractionDigits(0);
format36.setGroupingUsed(false);
NumberFormat format10 = new DecimalFormat();
format10.setMinimumIntegerDigits(10);
format10.setMaximumFractionDigits(0);
format10.setGroupingUsed(false);
NumberFormat format3 = new DecimalFormat();
format3.setMinimumIntegerDigits(3);
format3.setMaximumFractionDigits(0);
for (int i = 0; i < size; i++) {
out.write("<p><div><pre>\n"); // 14
out.write("\t\r\n"); // 3
out.write(format36.format(tempLoadVar)); // 36
out.write(" : "); // 3
out.write(format10.format(i)); // 10
out.write(": blah\n"); // 7
for (int j = 0; j < 4; j++) {
for (int k = 0; k < 4; k++) {
out.write("\t\t" + format3.format(j)
+ " " + format3.format(k) + "\n"); // 10
}
}
out.write("</pre></div></p>\n<br />"); // 23
}
}

/** Use up some CPU. Do that twice. */
private void workSome() {
for (int i = 0; i < load; i++) {
for (int j = 0; j < LOAD_ITERATIONS; j++) {
tempLoadVar = tempLoadVar + 1;
}
}
}
%>

So, yesterday I was complaining how Opteron workstation handles 500 threads without breaking a sweat. Today I tried the same test on dual-Xeon box and results are much worse. 300 threads load this one to 50% CPU idle. 500 make it eventually to time out, as it gets extremely busy. Wonder what's the major issue here. The differences between the two solutions are numerous.
My workstation is an Opteron uniprocessor (1MB L2 cache) with 1GB of memory running Solaris and 64-bit JDK 1.5.
Production server uses 2 Xeon processors with 512 kB L2 cache and 2GB of memory; it runs not very modern, (but not too old either) version of RedHat Workstation, and uses 32-bit JDK 1.5.
Apriori, the results should have been quite different. I'm begging for an explanation! Is it that threading in Java running on RedHat is so much worse than in Solaris? Are too many (500, how's that too many?!) open network sockets overload TCP/IP stack? Does the fact that while generating this page I put its thread to sleep 4 times put *ell server at a disadvantage?
Note that in that particular test I was using this query string: "?load=0&size=200&delay=30000". This at least shows that the need to add long integers is out of the picture.

Sunday, September 11, 2005

Load testing Tomcat with JMeter, Part I

A collegue of mine (likely annoyed by my bragging about my w1100z) challenged me to compare performance of my Opteron workstation to dual-Xeon *ell servers our company uses in production. Problem is, in many scenarios I simply fail to generate significant load to saturate CPU. Like this one: I try to see how many concurrent sockets can Tomcat tolerate under 64-bit JVM on Solaris 10. And what I see is, JMeter would simply die with no explanation if I set number of parallel threads to number greater than 500. At the same time, Tomcat continues running happily, using ~20% CPU at most. Guess I will have to dump this particular test.

Friday, September 02, 2005

Is InfoSys the most ruthless consultancy?

Noticed a pattern, and not a very pleasing one. Whenever a bunch InfoSys employees post an article somewhere on the web (could be in JavaPro, JavaWorld, TheServerSide, or, most recently, JavaLobby), regardless how crappy it would be, there will be a meaningless post or two in the discussion that follows, praising the genius of the authors. Fortunately, this scam is pretty much a see-through, as these comments are written in the same English that almost makes it possible to hear all-too-familiar accent. Pretty often the names of those making comment are telling, too. Now, I have no doubt that fellow Indians making those comments are well-meaning. They might not even be employed with InfoSys themselves, they're just trying to help what became a pillar of Indian software consulting. After all, several realtives of theirs are sure to be employed with InfoSsys. And when their H-1 expires, where will they seek employment first when back to Bangalore or Mumbai?

It goes without saying that this is standard means of bringing attention by consultants, to publish something. There are a number of crappy books out there that serve no purpose other than to make name for its author.

And I have to be frank, I'm partly bitter because there is no company of my ex-patriates I could root for :( But still, this practice remains just bad. False praises not based on merits of the work... just bad.