RE: JSTL startup times - is caching going on?
Henri, thanks for the response. Yes, Tomcat 4.1 will pool objects created by custom taglibs - so this could be it. But I would sure like to be able to adjust the time the objects are pooled, so they stick around a little longer. I am generating the SVG from our domain model (just summarized Java objects). Some of the charts we do are unlike any that I've seen in the frameworks. But I do not remember looking at Cewolf JFreeChart, I just located it on SourceForge. We rolled our own because the scatter diagrams and line charts are a little different that most charting packages support, but I would love to have a framework I did not have to maintain alone. Thanks again. -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Saturday, September 20, 2003 10:45 PM To: Tag Libraries Users List Subject: Re: JSTL startup times - is caching going on? The JSP spec for Tomcat 4.1 does say that a container may cache Tag objects between page runs. It sounds like this could be what's happening here. I've no idea whether it would cache across sessions etc. Up to the server and not the taglib. On the speed issue. What are you using to create the SVG? And where does it get the data? Off-topic: I've been having fun with the Cewolf JFreeChart library and it's pretty nifty. Hen On Sat, 20 Sep 2003, Richard Mixon (qwest) wrote: I am having an issue with large startup times the first time one of my pages runs that uses JSTL mostly the core library. Subsequent requests (even for different users on different data) take much, much less time. Here is a little more detail. Any ideas are much appreciated. My ISP is pretty irate because we suck up huge amounts of CPU each time it happens. We are using Tomcat 4.1.24, Java 1.4.1 and Struts 1.1. OK, the page uses a couple of nested foreach loops to generate a grid/chart of SVG markup language. It also uses a couple of small foreach loops to generate tick marks on an axis. It looks something like: Chart page embed tag include JSP/JSTL page to generate footer. include JSP/JSTL page to generate x and y axis JSTL markup to generate main body of chart include JSP/JSTL page to generate footer. The request takes a half second to build the Java objects that the JSTL code uses to render on the page. But the rendering takes 45 second on a 650MHZ Sun SPARC III machine and almost that long on a fast Windows machine (2500 MHZ). The second and subsequent times the chart rendering drops down to less than 200 milliseconds. Then about five minutes later, if the chart is requested again, it takes the 45 seconds to generate, then 200 milliseconds for subsequent requests. Thanks - Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSTL startup times - is caching going on?
I am having an issue with large startup times the first time one of my pages runs that uses JSTL mostly the core library. Subsequent requests (even for different users on different data) take much, much less time. Here is a little more detail. Any ideas are much appreciated. My ISP is pretty irate because we suck up huge amounts of CPU each time it happens. We are using Tomcat 4.1.24, Java 1.4.1 and Struts 1.1. OK, the page uses a couple of nested foreach loops to generate a grid/chart of SVG markup language. It also uses a couple of small foreach loops to generate tick marks on an axis. It looks something like: Chart page embed tag include JSP/JSTL page to generate footer. include JSP/JSTL page to generate x and y axis JSTL markup to generate main body of chart include JSP/JSTL page to generate footer. The request takes a half second to build the Java objects that the JSTL code uses to render on the page. But the rendering takes 45 second on a 650MHZ Sun SPARC III machine and almost that long on a fast Windows machine (2500 MHZ). The second and subsequent times the chart rendering drops down to less than 200 milliseconds. Then about five minutes later, if the chart is requested again, it takes the 45 seconds to generate, then 200 milliseconds for subsequent requests. Thanks - Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSTL startup times - is caching going on?
The JSP spec for Tomcat 4.1 does say that a container may cache Tag objects between page runs. It sounds like this could be what's happening here. I've no idea whether it would cache across sessions etc. Up to the server and not the taglib. On the speed issue. What are you using to create the SVG? And where does it get the data? Off-topic: I've been having fun with the Cewolf JFreeChart library and it's pretty nifty. Hen On Sat, 20 Sep 2003, Richard Mixon (qwest) wrote: I am having an issue with large startup times the first time one of my pages runs that uses JSTL mostly the core library. Subsequent requests (even for different users on different data) take much, much less time. Here is a little more detail. Any ideas are much appreciated. My ISP is pretty irate because we suck up huge amounts of CPU each time it happens. We are using Tomcat 4.1.24, Java 1.4.1 and Struts 1.1. OK, the page uses a couple of nested foreach loops to generate a grid/chart of SVG markup language. It also uses a couple of small foreach loops to generate tick marks on an axis. It looks something like: Chart page embed tag include JSP/JSTL page to generate footer. include JSP/JSTL page to generate x and y axis JSTL markup to generate main body of chart include JSP/JSTL page to generate footer. The request takes a half second to build the Java objects that the JSTL code uses to render on the page. But the rendering takes 45 second on a 650MHZ Sun SPARC III machine and almost that long on a fast Windows machine (2500 MHZ). The second and subsequent times the chart rendering drops down to less than 200 milliseconds. Then about five minutes later, if the chart is requested again, it takes the 45 seconds to generate, then 200 milliseconds for subsequent requests. Thanks - Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]