Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by Jasper2
On Mon, 29 Apr 2002, Remy Maucherat wrote: This looks like a good idea to me (Kin-Man is not there this week, so it's not an expert opinion). I would see that kind of change going into Jasper 2, though. Do you think you can prepare a patch against that version ? Remy Thanks! We've done some benchmarks with JMeter, even though the case we tested is pathologic, the JSP contained 100 tags! The results were impressive. The Jasper version included with the pre-beta 4.1 tomcat averaged 20 seconds/hit, with the patch, the CVS version of jasper2 average 0.8 second/hit. If there is less try/finally nesting in the java code of the page, the difference is less impressive of course. The test setup, the test page and the detail of the results can be found: http://www3.sympatico.ca/benoitde/ NOTE my sunday patch contained one bug, this one has been more tested. I've applied the patch. Watchdog is fine, so I committed it. The admin webapp appeared slow before the patch (esp when using a context page), and that was with an Athlon 1700 as the server with one user (me). I'm not happy in general when a request uses 100% of the CPU for 1 full second ;-) I couldn't figure out why it was so slow, and the other runtime optimizations didn't help at all. It turns out it was caused by this JVM bug ... With the patch, it's become quite fast. Very impressive, and since IMO it is quite representative of a Struts based application which would have complex pages, it's really awesome. I suppose the fast JSP compilers (Resin, Orion) use similar tricks in the code generation. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by Jasper2
I just ran a quick test using the test pages I used earlier for benchmarking, and the results are very positive. Thanks to Denis for patch. The following data might bring a smile. Here is a link to the previous benchmarks I posted. http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg49733.html The benchmark was performed on System II mentioned in the previous post in tomcat-user list. Another system was used to send requests. New Results with Denis Patch - 1 thread 1000 --- ave - 46 cpu usage - 35-50% 2 threads 500 --- ave - 73 cpu usage - 40-80% 4 threads 250 --- ave - 133 cpu usage - 50-80% 8 threads 125 --- ave - 235 cpu usage - 60-85% 16 threads 65 --- ave - 479 cpu usage - 60-95% 32 threads 63 --- ave - 1157 cpu usage - 80-95% Remy Maucherat wrote: I've applied the patch. Watchdog is fine, so I committed it. The admin webapp appeared slow before the patch (esp when using a context page), and that was with an Athlon 1700 as the server with one user (me). I'm not happy in general when a request uses 100% of the CPU for 1 full second ;-) I couldn't figure out why it was so slow, and the other runtime optimizations didn't help at all. It turns out it was caused by this JVM bug ... With the patch, it's become quite fast. Very impressive, and since IMO it is quite representative of a Struts based application which would have complex pages, it's really awesome. I suppose the fast JSP compilers (Resin, Orion) use similar tricks in the code generation. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] peter lin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by Jasper2
I just ran a quick test using the test pages I used earlier for benchmarking, and the results are very positive. Thanks to Denis for patch. The following data might bring a smile. Here is a link to the previous benchmarks I posted. http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg49733.html The benchmark was performed on System II mentioned in the previous post in tomcat-user list. Another system was used to send requests. I don't remember what your test page was (and I can't find which series of tests I should compare to also ;-)), but you have to remember that the bug is that the time needed by the JVM is non linear to the number of tags. So if you use 10 tags in the page, it should help a bit. If you use 100 tags, it will help a LOT. If you use more tags, the page will likely not work at all without the patch. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by Jasper2
Here is a bit more information on the test pages I have. total tags used: 172 main page: 105 header page: 65 footer page: 2 Actually there the main page includes a few other pages using c:import in JSTL. The total count on the tags used is over 200, but the other files are smaller, using a dozen or so tags. I will do more tests using coyote a later in the week. Once I have that data, I will post it. peter lin Remy Maucherat wrote: I just ran a quick test using the test pages I used earlier for benchmarking, and the results are very positive. Thanks to Denis for patch. The following data might bring a smile. Here is a link to the previous benchmarks I posted. http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg49733.html The benchmark was performed on System II mentioned in the previous post in tomcat-user list. Another system was used to send requests. I don't remember what your test page was (and I can't find which series of tests I should compare to also ;-)), but you have to remember that the bug is that the time needed by the JVM is non linear to the number of tags. So if you use 10 tags in the page, it should help a bit. If you use 100 tags, it will help a LOT. If you use more tags, the page will likely not work at all without the patch. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Re: [PROPOSAL] Modification of the code generated by Jasper2
On Mon, 29 Apr 2002, Remy Maucherat wrote:
This looks like a good idea to me (Kin-Man is not there this week, so it's
not an expert opinion). I would see that kind of change going into Jasper 2,
though. Do you think you can prepare a patch against that version ?
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Thanks!
We've done some benchmarks with JMeter, even though the case we tested is pathologic,
the JSP contained 100 tags! The results were impressive. The Jasper version included
with the pre-beta 4.1 tomcat averaged 20 seconds/hit, with the patch, the CVS
version of jasper2 average 0.8 second/hit. If there is less try/finally nesting
in the java code of the page, the difference is less impressive of course.
The test setup, the test page and the detail of the results can be found:
http://www3.sympatico.ca/benoitde/
NOTE my sunday patch contained one bug, this one has been more tested.
The patch against the CVS jasper2 is:
Index:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.6
diff -u -r1.6 Generator.java
--- jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
25 Apr 2002 18:16:06 - 1.6
+++ jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
+ 30 Apr 2002 00:23:19 -
@@ -63,6 +63,8 @@
import java.util.*;
import java.beans.*;
import java.net.URLEncoder;
+import java.io.ByteArrayOutputStream;
+import java.io.PrintStream;
import java.lang.reflect.Method;
import javax.servlet.jsp.tagext.*;
import org.xml.sax.Attributes;
@@ -91,6 +93,9 @@
private JspCompilationContext ctxt;
private boolean breakAtLF;
private PageInfo pageInfo;
+private FinallyApplyer finallies;
+private int tryBit;
+private Stack tryStack;
/**
* @param s the input string
@@ -176,6 +181,8 @@
out.print ((String)iter.next());
out.println(;);
}
+ out.printil(import java.util.Vector;);
+ out.printil(import java.util.BitSet;);
out.println();
// Generate class declaration
@@ -199,6 +206,17 @@
// Constructor (empty so far) here
// Other methods here
+ out.printil(private void addTagToVector(Vector tags, int index,
+javax.servlet.jsp.tagext.Tag tag) {);
+ out.pushIndent();
+ out.printil(if (index + 1 tags.size()));
+ out.pushIndent();
+ out.printil(tags.setSize(index + 1););
+ out.popIndent();
+ out.printil(tags.setElementAt(tag, index););
+ out.popIndent();
+ out.printil(});
+ out.println();
+ out.println();
// Now the service method
out.printin(public void );
@@ -222,6 +240,8 @@
out.printil(ServletConfig config = null;);
out.printil(JspWriter out = null;);
out.printil(Object page = this;);
+ out.printil(BitSet bitmask = new BitSet(););
+ out.printil(Vector tags = new Vector(););
out.printil(try {);
out.pushIndent();
@@ -882,6 +902,10 @@
out.println( */);
Class tagHandlerClass = handlerInfo.getTagHandlerClass();
+
+ boolean implementsTryCatchFinally =
+ TryCatchFinally.class.isAssignableFrom(tagHandlerClass);
+
out.printin(tagHandlerClass.getName());
out.print( );
out.print(tagHandlerVar);
@@ -895,8 +919,22 @@
declareTagVariableInfos(tagVarInfos, n.getTagData(),
VariableInfo.AT_BEGIN);
- out.printil(try {);
- out.pushIndent();
+ if (implementsTryCatchFinally) {
+ out.printil(try {);
+ out.pushIndent();
+ } else {
+ out.printil(// try {);
+ out.printin(bitmask.set();
+ Integer tryBitVal = new Integer(tryBit++);
+ tryStack.push(tryBitVal);
+ out.print(tryBitVal.toString());
+ out.println(););
+ out.printin(addTagToVector(tags, );
+ out.print(tryBitVal.toString());
+ out.print(, );
+ out.print(tagHandlerVar);
+ out.println(););
+ }
out.printin(int );
out.print(tagEvalVar);
out.print( = );
@@ -918,8 +956,17 @@
out.pushIndent();
if (isBodyTag) {
- out.printil(try {);
- out.pushIndent();
+ out.printil(// try {);
+ out.printin(bitmask.set();
+ Integer tryBitVal = new Integer(tryBit++);
+
