You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Kurtis Williams <kw...@mshare.net> on 2005/01/14 19:28:41 UTC
Development mode with LESS PAIN????
[Cue desperate wail for help]
I run Tapestry in "development mode" with the command line switch
"-Dorg.apache.tapestry.disable-caching=true" on my Tomcat app server. I
do this because I want to view changes to my templates and specification
files when I hit the refresh button on my browser.
But (and this is a BIG but) this mode is so utterly painful to work with
that it almost eliminates the productivity gains I've made by switching
to Tapestry in the first place (OK, that's an exaggeration, but as we
established before, I'm desperate!)
[Cue second pathetic cry for help]
Is there any way to do this without paying such an enormous penalty for
working in "development mode?" I've tried enabling caching and then
just depending on Tomcat to reload using the reloadable="true" in the
context, but that carries it's own set of side-effects.
Has anybody found a good way to rapidly develop Tapestry sites without
the painful lag time between clicks? (Other than buying a quad
processing 5Ghz development box with a hardware XML accelerator?)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Tapestry HiveMind migration path
Posted by kranga <kr...@k2d2.org>.
Talking about hivemind inclusion in Tapestry 3.1, will it be strictly for
the internal workings of Tapestry? In other words -
a) If I don't care about IoC controllers for my application, and I am using
only standard Tapestry interfaces/classes, do I need to do anything special
to use 3.1?
b) Will it preclude the use of a different IoC framework such as Spring?
c) Do I have to make changes to my .jwc file as a result of the hivemind
use?
d) What is the increase in memory footprint?
----- Original Message -----
From: "Michael Henderson" <mh...@mac.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Friday, January 14, 2005 1:43 PM
Subject: Re: Development mode with LESS PAIN????
> Hi,
>
> A while back I looked at the Tapestry source to see if I could patch it
> to reload templates and specifications if they have changed
> since they were last loaded and cached. This would probably work for
> development since the only files to be reloaded would be the changed
> file, the one you are editing.
>
> The cache/pool of components is partitioned so well from the loading of
> templates and specifications that I could not see a quick way of doing it.
>
> One way would be to use a custom specification resolver delegate and
> template resolver delegate, move all your components out of the standard
> locations and let the delegates load them. The delegates can cache the
> items (Tapestry does not cache specifications or templates provided by
> the delegate), but check the source file's last-modified date on each
> request and reload if the file has changed.
>
> You would have to live with all of the Spindle errors as well.
>
> Tapestry 3.1 with integrated config via HiveMind will probably make ths
> sort of thing a lot easier to do.
>
> Mike
>
>
> Kurtis Williams wrote:
>
> >[Cue desperate wail for help]
> >
> >I run Tapestry in "development mode" with the command line switch
> >"-Dorg.apache.tapestry.disable-caching=true" on my Tomcat app server. I
> >do this because I want to view changes to my templates and specification
> >files when I hit the refresh button on my browser.
> >
> >But (and this is a BIG but) this mode is so utterly painful to work with
> >that it almost eliminates the productivity gains I've made by switching
> >to Tapestry in the first place (OK, that's an exaggeration, but as we
> >established before, I'm desperate!)
> >
> >[Cue second pathetic cry for help]
> >
> >Is there any way to do this without paying such an enormous penalty for
> >working in "development mode?" I've tried enabling caching and then
> >just depending on Tomcat to reload using the reloadable="true" in the
> >context, but that carries it's own set of side-effects.
> >
> >Has anybody found a good way to rapidly develop Tapestry sites without
> >the painful lag time between clicks? (Other than buying a quad
> >processing 5Ghz development box with a hardware XML accelerator?)
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN????
Posted by Michael Henderson <mh...@mac.com>.
Hi,
A while back I looked at the Tapestry source to see if I could patch it
to reload templates and specifications if they have changed
since they were last loaded and cached. This would probably work for
development since the only files to be reloaded would be the changed
file, the one you are editing.
The cache/pool of components is partitioned so well from the loading of
templates and specifications that I could not see a quick way of doing it.
One way would be to use a custom specification resolver delegate and
template resolver delegate, move all your components out of the standard
locations and let the delegates load them. The delegates can cache the
items (Tapestry does not cache specifications or templates provided by
the delegate), but check the source file's last-modified date on each
request and reload if the file has changed.
You would have to live with all of the Spindle errors as well.
Tapestry 3.1 with integrated config via HiveMind will probably make ths
sort of thing a lot easier to do.
Mike
Kurtis Williams wrote:
>[Cue desperate wail for help]
>
>I run Tapestry in "development mode" with the command line switch
>"-Dorg.apache.tapestry.disable-caching=true" on my Tomcat app server. I
>do this because I want to view changes to my templates and specification
>files when I hit the refresh button on my browser.
>
>But (and this is a BIG but) this mode is so utterly painful to work with
>that it almost eliminates the productivity gains I've made by switching
>to Tapestry in the first place (OK, that's an exaggeration, but as we
>established before, I'm desperate!)
>
>[Cue second pathetic cry for help]
>
>Is there any way to do this without paying such an enormous penalty for
>working in "development mode?" I've tried enabling caching and then
>just depending on Tomcat to reload using the reloadable="true" in the
>context, but that carries it's own set of side-effects.
>
>Has anybody found a good way to rapidly develop Tapestry sites without
>the painful lag time between clicks? (Other than buying a quad
>processing 5Ghz development box with a hardware XML accelerator?)
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN????
Posted by Luc Peerdeman <lj...@xs4all.nl>.
Hi Richard,
Richard Lewis-Shell wrote:
> link. I've found this easier than dealing with the inspector as Luc
> suggests... (one click vs two :-)
Good suggestion :-).
> This way you don't get any performance penalty for pages/components you
> aren't changing, and it's quite common when developing to be navigating
> between pages you are and aren't developing.
Exactly. I am not sure why Tapestry would have to do this automatically,
as some suggest. The existing mechanism to me seems efficient (no
up-to-date checking overhead) and still allows for quick feedback to
changes via the reset service. Not much to be gained by changing this, I
wreckon.
Cheers, Luc.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN???? - pain measurements
Posted by Vjeran Marcinko <vj...@tis.hr>.
----- Original Message -----
From: "Konstantin Iignatyev" <kg...@yahoo.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Monday, January 17, 2005 5:37 AM
Subject: Re: Development mode with LESS PAIN???? - pain measurements
> Well, it is almost order of magnitude far from real response time, so I
> suggest removing the measurement as misleading. Simplest filter like one
> I used produces far more accurate results and extremely easy to use for
> rough (but accurate) performance measures. I bet there is a place in the
> Tapestry where entire FW response time could be measured without of
> filter use.
+1 from me for rendering complete request time, because I was also the one
who was mislead by this time some months ago, though it was obvious by eye
that my page took much longer to render itself. Never asked on this mailing
list why it was though (now I can see it isn't real processing time).
Just my 2 cents.
-Vjeran
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.12 - Release Date: 14.1.2005
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN???? - pain measurements
Posted by Konstantin Iignatyev <kg...@yahoo.com>.
Howard Lewis Ship wrote:
>The time is inaccurate because the Java clock is inaccurate.
>
C'mon, Java clock is inaccuracy could be in 1-5 ms range, it could not
explain 80 and 602 ms difference
> The time
>measured is the time to render the Shell component ... not the time it
>takes to process the entire response.
>
>The point of it is to allow you to see orders-of-magnitude differences
>between pages.
>
>
Well, it is almost order of magnitude far from real response time, so I
suggest removing the measurement as misleading. Simplest filter like one
I used produces far more accurate results and extremely easy to use for
rough (but accurate) performance measures. I bet there is a place in the
Tapestry where entire FW response time could be measured without of
filter use.
>Can't think of a security issue. What could you possibly do with the time?
>
>
Security is not related to time at all, before in the tread somebody
asked how to remove Rendering time mark from final HTML because it
indicates Tapestry as a framework and his boss considers that as a
security weakness. I simply referred to that question.
>On Sun, 16 Jan 2005 19:14:23 -0800 (PST), Konstantin Ignatyev
><kg...@yahoo.com> wrote:
>
>
>>That is a nice workaround for a thing that should be
>>done automatically at framework level. Someone earlier
>>suggested removing Render time from Tapestry produced
>>HTML by security reasons, I suggest removing it
>>because it provides false information about render
>>time, I did quick and dirty performance estimation
>>with HttpUnit and filter in front of Tapestry
>>application:
>>Request took = 2970 ms at client side, page reports
>>Render time: ~ 279 ms -->
>>Request took = 810 ms at client side, page reports
>>Render time: ~ 112 ms -->
>>Request took = 726 ms at client side, page reports
>>Render time: ~ 98 ms -->
>>Request took = 753 ms at client side, page reports
>>Render time: ~ 107 ms -->
>>Request took = 527 ms at client side, page reports
>>Render time: ~ 95 ms -->
>>Request took = 668 ms at client side, page reports
>>Render time: ~ 83 ms -->
>>Request took = 489 ms at client side, page reports
>>Render time: ~ 75 ms -->
>>Request took = 611 ms at client side, page reports
>>Render time: ~ 79 ms -->
>>Request took = 490 ms at client side, page reports
>>Render time: ~ 80 ms -->
>>Request took = 631 ms at client side, page reports
>>Render time: ~ 80 ms -->
>>for the same request server side filter reports:
>>2381 ms -service=external/PhotoCollection&sp=Sbatik
>>747 ms -service=external/PhotoCollection&sp=Sbatik
>>663 ms -service=external/PhotoCollection&sp=Sbatik
>>681 ms -service=external/PhotoCollection&sp=Sbatik
>>483 ms -service=external/PhotoCollection&sp=Sbatik
>>593 ms -service=external/PhotoCollection&sp=Sbatik
>>435 ms -service=external/PhotoCollection&sp=Sbatik
>>580 ms -service=external/PhotoCollection&sp=Sbatik
>>466 ms -service=external/PhotoCollection&sp=Sbatik
>>602 ms -service=external/PhotoCollection&sp=Sbatik
>>
>>As we can see Shell reports 8 times smaller rendering
>>time than it really is.
>>There is negligible client side processing time:
>>server side filter reports 602 ms rendering time,
>>client says 631 ms.
>>
>>Those measurements are for HTML production only,
>>getting all the page artifacts like images and css may
>>take much longer...
>>
>>client:
>>public class SitePerformanceTest {
>>
>> public static void main(String[] args) {
>> try {
>> WebConversation wc = new WebConversation();
>> WebRequest req = new
>>GetMethodWebRequest("http://localhost:8080/mmerk/app?service=external/PhotoCollection&sp=Sbatik");
>> long startTime = 0;
>> WebResponse resp = null;
>> long end = 0;
>> for (int i = 0; i < 10; i++) {
>> startTime = System.currentTimeMillis();
>> resp = wc.getResponse(req);
>> end = System.currentTimeMillis();
>> System.out.println("Request took = " + (end -
>>startTime) + " ms at client side, page reports " +
>>getRendering(resp.getText()) );
>> }
>> } catch (Exception e) {
>> e.printStackTrace();
>> }
>> }
>>
>> private static String getRendering(String text) {
>> RE re = new RE("(Render time:.+)");
>> re.match(text);
>> return re.getParen(0);
>> }
>>}
>>
>>server side filter:
>>public class PerfFilter implements Filter{
>> public void init(FilterConfig filterConfig) throws
>>ServletException {
>>
>> }
>>
>> public void doFilter(ServletRequest servletRequest,
>>ServletResponse servletResponse, FilterChain
>>filterChain) throws IOException, ServletException {
>> long start = System.currentTimeMillis();
>> filterChain.doFilter(servletRequest,
>>servletResponse);
>> if( servletRequest instanceof HttpServletRequest){
>> HttpServletRequest r = (HttpServletRequest)
>>servletRequest;
>> System.out.println( (
>>System.currentTimeMillis() - start ) + " ms -" +
>>r.getQueryString() );
>> }
>> }
>>
>> public void destroy() {
>>
>> }
>>}
>>
>> <filter>
>> <filter-name>p</filter-name>
>>
>><filter-class>com.kgionline.mmerkulova.site.PerfFilter</filter-class>
>> </filter>
>>
>> <filter-mapping>
>> <filter-name>p</filter-name>
>> <url-pattern>/app</url-pattern>
>> </filter-mapping>
>>
>>Suse 9.2 AMD 64 3500+ java 1.4.2_06
>>
>>--- Richard Lewis-Shell <rl...@mac.com> wrote:
>>
>>
>>
>>>I never develop Tapestry apps with caching disabled.
>>> But in every app I
>>>develop I put a link to trigger the reset service.
>>>Typically the app
>>>has a logo, or something common on every page so
>>>that logo/whatever
>>>becomes a development-time reset (ie. reload) link.
>>>
>>>
>>>
>>>
>>=====
>>Konstantin Ignatyev
>>
>>PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
>>
>>Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>
>
--
Thanks,
Konstantin Ignatyev
http://www.kgionline.com
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
Bowers, C.A. The Culture of Denial:
Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN???? - pain measurements
Posted by Howard Lewis Ship <hl...@gmail.com>.
The time is inaccurate because the Java clock is inaccurate. The time
measured is the time to render the Shell component ... not the time it
takes to process the entire response.
The point of it is to allow you to see orders-of-magnitude differences
between pages.
Can't think of a security issue. What could you possibly do with the time?
On Sun, 16 Jan 2005 19:14:23 -0800 (PST), Konstantin Ignatyev
<kg...@yahoo.com> wrote:
> That is a nice workaround for a thing that should be
> done automatically at framework level. Someone earlier
> suggested removing Render time from Tapestry produced
> HTML by security reasons, I suggest removing it
> because it provides false information about render
> time, I did quick and dirty performance estimation
> with HttpUnit and filter in front of Tapestry
> application:
> Request took = 2970 ms at client side, page reports
> Render time: ~ 279 ms -->
> Request took = 810 ms at client side, page reports
> Render time: ~ 112 ms -->
> Request took = 726 ms at client side, page reports
> Render time: ~ 98 ms -->
> Request took = 753 ms at client side, page reports
> Render time: ~ 107 ms -->
> Request took = 527 ms at client side, page reports
> Render time: ~ 95 ms -->
> Request took = 668 ms at client side, page reports
> Render time: ~ 83 ms -->
> Request took = 489 ms at client side, page reports
> Render time: ~ 75 ms -->
> Request took = 611 ms at client side, page reports
> Render time: ~ 79 ms -->
> Request took = 490 ms at client side, page reports
> Render time: ~ 80 ms -->
> Request took = 631 ms at client side, page reports
> Render time: ~ 80 ms -->
> for the same request server side filter reports:
> 2381 ms -service=external/PhotoCollection&sp=Sbatik
> 747 ms -service=external/PhotoCollection&sp=Sbatik
> 663 ms -service=external/PhotoCollection&sp=Sbatik
> 681 ms -service=external/PhotoCollection&sp=Sbatik
> 483 ms -service=external/PhotoCollection&sp=Sbatik
> 593 ms -service=external/PhotoCollection&sp=Sbatik
> 435 ms -service=external/PhotoCollection&sp=Sbatik
> 580 ms -service=external/PhotoCollection&sp=Sbatik
> 466 ms -service=external/PhotoCollection&sp=Sbatik
> 602 ms -service=external/PhotoCollection&sp=Sbatik
>
> As we can see Shell reports 8 times smaller rendering
> time than it really is.
> There is negligible client side processing time:
> server side filter reports 602 ms rendering time,
> client says 631 ms.
>
> Those measurements are for HTML production only,
> getting all the page artifacts like images and css may
> take much longer...
>
> client:
> public class SitePerformanceTest {
>
> public static void main(String[] args) {
> try {
> WebConversation wc = new WebConversation();
> WebRequest req = new
> GetMethodWebRequest("http://localhost:8080/mmerk/app?service=external/PhotoCollection&sp=Sbatik");
> long startTime = 0;
> WebResponse resp = null;
> long end = 0;
> for (int i = 0; i < 10; i++) {
> startTime = System.currentTimeMillis();
> resp = wc.getResponse(req);
> end = System.currentTimeMillis();
> System.out.println("Request took = " + (end -
> startTime) + " ms at client side, page reports " +
> getRendering(resp.getText()) );
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
>
> private static String getRendering(String text) {
> RE re = new RE("(Render time:.+)");
> re.match(text);
> return re.getParen(0);
> }
> }
>
> server side filter:
> public class PerfFilter implements Filter{
> public void init(FilterConfig filterConfig) throws
> ServletException {
>
> }
>
> public void doFilter(ServletRequest servletRequest,
> ServletResponse servletResponse, FilterChain
> filterChain) throws IOException, ServletException {
> long start = System.currentTimeMillis();
> filterChain.doFilter(servletRequest,
> servletResponse);
> if( servletRequest instanceof HttpServletRequest){
> HttpServletRequest r = (HttpServletRequest)
> servletRequest;
> System.out.println( (
> System.currentTimeMillis() - start ) + " ms -" +
> r.getQueryString() );
> }
> }
>
> public void destroy() {
>
> }
> }
>
> <filter>
> <filter-name>p</filter-name>
>
> <filter-class>com.kgionline.mmerkulova.site.PerfFilter</filter-class>
> </filter>
>
> <filter-mapping>
> <filter-name>p</filter-name>
> <url-pattern>/app</url-pattern>
> </filter-mapping>
>
> Suse 9.2 AMD 64 3500+ java 1.4.2_06
>
> --- Richard Lewis-Shell <rl...@mac.com> wrote:
>
> > I never develop Tapestry apps with caching disabled.
> > But in every app I
> > develop I put a link to trigger the reset service.
> > Typically the app
> > has a logo, or something common on every page so
> > that logo/whatever
> > becomes a development-time reset (ie. reload) link.
>
> >
> >
>
> =====
> Konstantin Ignatyev
>
> PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
>
> Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN???? - pain measurements
Posted by kranga <kr...@k2d2.org>.
I always suspected that the time reported by the shell component is
incorrect. In fact, I put a timer code in pageBegin- and pageEnd- render and
saw the same time as what Shell reports. My suspicion therefore is that the
process from when the page finished with the markup writer to when it is
streamed out is slow - something going on there... Howard?
----- Original Message -----
From: "Konstantin Ignatyev" <kg...@yahoo.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Sunday, January 16, 2005 10:14 PM
Subject: Development mode with LESS PAIN???? - pain measurements
> That is a nice workaround for a thing that should be
> done automatically at framework level. Someone earlier
> suggested removing Render time from Tapestry produced
> HTML by security reasons, I suggest removing it
> because it provides false information about render
> time, I did quick and dirty performance estimation
> with HttpUnit and filter in front of Tapestry
> application:
> Request took = 2970 ms at client side, page reports
> Render time: ~ 279 ms -->
> Request took = 810 ms at client side, page reports
> Render time: ~ 112 ms -->
> Request took = 726 ms at client side, page reports
> Render time: ~ 98 ms -->
> Request took = 753 ms at client side, page reports
> Render time: ~ 107 ms -->
> Request took = 527 ms at client side, page reports
> Render time: ~ 95 ms -->
> Request took = 668 ms at client side, page reports
> Render time: ~ 83 ms -->
> Request took = 489 ms at client side, page reports
> Render time: ~ 75 ms -->
> Request took = 611 ms at client side, page reports
> Render time: ~ 79 ms -->
> Request took = 490 ms at client side, page reports
> Render time: ~ 80 ms -->
> Request took = 631 ms at client side, page reports
> Render time: ~ 80 ms -->
> for the same request server side filter reports:
> 2381 ms -service=external/PhotoCollection&sp=Sbatik
> 747 ms -service=external/PhotoCollection&sp=Sbatik
> 663 ms -service=external/PhotoCollection&sp=Sbatik
> 681 ms -service=external/PhotoCollection&sp=Sbatik
> 483 ms -service=external/PhotoCollection&sp=Sbatik
> 593 ms -service=external/PhotoCollection&sp=Sbatik
> 435 ms -service=external/PhotoCollection&sp=Sbatik
> 580 ms -service=external/PhotoCollection&sp=Sbatik
> 466 ms -service=external/PhotoCollection&sp=Sbatik
> 602 ms -service=external/PhotoCollection&sp=Sbatik
>
> As we can see Shell reports 8 times smaller rendering
> time than it really is.
> There is negligible client side processing time:
> server side filter reports 602 ms rendering time,
> client says 631 ms.
>
> Those measurements are for HTML production only,
> getting all the page artifacts like images and css may
> take much longer...
>
> client:
> public class SitePerformanceTest {
>
> public static void main(String[] args) {
> try {
> WebConversation wc = new WebConversation();
> WebRequest req = new
>
GetMethodWebRequest("http://localhost:8080/mmerk/app?service=external/PhotoC
ollection&sp=Sbatik");
> long startTime = 0;
> WebResponse resp = null;
> long end = 0;
> for (int i = 0; i < 10; i++) {
> startTime = System.currentTimeMillis();
> resp = wc.getResponse(req);
> end = System.currentTimeMillis();
> System.out.println("Request took = " + (end -
> startTime) + " ms at client side, page reports " +
> getRendering(resp.getText()) );
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
>
> private static String getRendering(String text) {
> RE re = new RE("(Render time:.+)");
> re.match(text);
> return re.getParen(0);
> }
> }
>
>
> server side filter:
> public class PerfFilter implements Filter{
> public void init(FilterConfig filterConfig) throws
> ServletException {
>
> }
>
> public void doFilter(ServletRequest servletRequest,
> ServletResponse servletResponse, FilterChain
> filterChain) throws IOException, ServletException {
> long start = System.currentTimeMillis();
> filterChain.doFilter(servletRequest,
> servletResponse);
> if( servletRequest instanceof HttpServletRequest){
> HttpServletRequest r = (HttpServletRequest)
> servletRequest;
> System.out.println( (
> System.currentTimeMillis() - start ) + " ms -" +
> r.getQueryString() );
> }
> }
>
> public void destroy() {
>
> }
> }
>
> <filter>
> <filter-name>p</filter-name>
>
> <filter-class>com.kgionline.mmerkulova.site.PerfFilter</filter-class>
> </filter>
>
>
> <filter-mapping>
> <filter-name>p</filter-name>
> <url-pattern>/app</url-pattern>
> </filter-mapping>
>
> Suse 9.2 AMD 64 3500+ java 1.4.2_06
>
> --- Richard Lewis-Shell <rl...@mac.com> wrote:
>
> > I never develop Tapestry apps with caching disabled.
> > But in every app I
> > develop I put a link to trigger the reset service.
> > Typically the app
> > has a logo, or something common on every page so
> > that logo/whatever
> > becomes a development-time reset (ie. reload) link.
>
> >
> >
>
>
> =====
> Konstantin Ignatyev
>
>
>
>
> PS: If this is a typical day on planet earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil, add
2,700 tons of CFCs to the stratosphere, and increase their population by
263,000
>
> Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs
a Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Development mode with LESS PAIN???? - pain measurements
Posted by Konstantin Ignatyev <kg...@yahoo.com>.
That is a nice workaround for a thing that should be
done automatically at framework level. Someone earlier
suggested removing Render time from Tapestry produced
HTML by security reasons, I suggest removing it
because it provides false information about render
time, I did quick and dirty performance estimation
with HttpUnit and filter in front of Tapestry
application:
Request took = 2970 ms at client side, page reports
Render time: ~ 279 ms -->
Request took = 810 ms at client side, page reports
Render time: ~ 112 ms -->
Request took = 726 ms at client side, page reports
Render time: ~ 98 ms -->
Request took = 753 ms at client side, page reports
Render time: ~ 107 ms -->
Request took = 527 ms at client side, page reports
Render time: ~ 95 ms -->
Request took = 668 ms at client side, page reports
Render time: ~ 83 ms -->
Request took = 489 ms at client side, page reports
Render time: ~ 75 ms -->
Request took = 611 ms at client side, page reports
Render time: ~ 79 ms -->
Request took = 490 ms at client side, page reports
Render time: ~ 80 ms -->
Request took = 631 ms at client side, page reports
Render time: ~ 80 ms -->
for the same request server side filter reports:
2381 ms -service=external/PhotoCollection&sp=Sbatik
747 ms -service=external/PhotoCollection&sp=Sbatik
663 ms -service=external/PhotoCollection&sp=Sbatik
681 ms -service=external/PhotoCollection&sp=Sbatik
483 ms -service=external/PhotoCollection&sp=Sbatik
593 ms -service=external/PhotoCollection&sp=Sbatik
435 ms -service=external/PhotoCollection&sp=Sbatik
580 ms -service=external/PhotoCollection&sp=Sbatik
466 ms -service=external/PhotoCollection&sp=Sbatik
602 ms -service=external/PhotoCollection&sp=Sbatik
As we can see Shell reports 8 times smaller rendering
time than it really is.
There is negligible client side processing time:
server side filter reports 602 ms rendering time,
client says 631 ms.
Those measurements are for HTML production only,
getting all the page artifacts like images and css may
take much longer...
client:
public class SitePerformanceTest {
public static void main(String[] args) {
try {
WebConversation wc = new WebConversation();
WebRequest req = new
GetMethodWebRequest("http://localhost:8080/mmerk/app?service=external/PhotoCollection&sp=Sbatik");
long startTime = 0;
WebResponse resp = null;
long end = 0;
for (int i = 0; i < 10; i++) {
startTime = System.currentTimeMillis();
resp = wc.getResponse(req);
end = System.currentTimeMillis();
System.out.println("Request took = " + (end -
startTime) + " ms at client side, page reports " +
getRendering(resp.getText()) );
}
} catch (Exception e) {
e.printStackTrace();
}
}
private static String getRendering(String text) {
RE re = new RE("(Render time:.+)");
re.match(text);
return re.getParen(0);
}
}
server side filter:
public class PerfFilter implements Filter{
public void init(FilterConfig filterConfig) throws
ServletException {
}
public void doFilter(ServletRequest servletRequest,
ServletResponse servletResponse, FilterChain
filterChain) throws IOException, ServletException {
long start = System.currentTimeMillis();
filterChain.doFilter(servletRequest,
servletResponse);
if( servletRequest instanceof HttpServletRequest){
HttpServletRequest r = (HttpServletRequest)
servletRequest;
System.out.println( (
System.currentTimeMillis() - start ) + " ms -" +
r.getQueryString() );
}
}
public void destroy() {
}
}
<filter>
<filter-name>p</filter-name>
<filter-class>com.kgionline.mmerkulova.site.PerfFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>p</filter-name>
<url-pattern>/app</url-pattern>
</filter-mapping>
Suse 9.2 AMD 64 3500+ java 1.4.2_06
--- Richard Lewis-Shell <rl...@mac.com> wrote:
> I never develop Tapestry apps with caching disabled.
> But in every app I
> develop I put a link to trigger the reset service.
> Typically the app
> has a logo, or something common on every page so
> that logo/whatever
> becomes a development-time reset (ie. reload) link.
>
>
=====
Konstantin Ignatyev
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN????
Posted by Richard Lewis-Shell <rl...@mac.com>.
I never develop Tapestry apps with caching disabled. But in every app I
develop I put a link to trigger the reset service. Typically the app
has a logo, or something common on every page so that logo/whatever
becomes a development-time reset (ie. reload) link. You can
enable/disable it based on whether the reset service is enabled (there's
a method in the Engine) - we'd never leave the reset service enabled in
production so each developer enables the service, which enables the
link. I've found this easier than dealing with the inspector as Luc
suggests... (one click vs two :-)
This way you don't get any performance penalty for pages/components you
aren't changing, and it's quite common when developing to be navigating
between pages you are and aren't developing.
Richard
Kurtis Williams wrote:
> [Cue desperate wail for help]
>
> I run Tapestry in "development mode" with the command line switch
> "-Dorg.apache.tapestry.disable-caching=true" on my Tomcat app server. I
> do this because I want to view changes to my templates and specification
> files when I hit the refresh button on my browser.
>
> But (and this is a BIG but) this mode is so utterly painful to work with
> that it almost eliminates the productivity gains I've made by switching
> to Tapestry in the first place (OK, that's an exaggeration, but as we
> established before, I'm desperate!)
>
> [Cue second pathetic cry for help]
>
> Is there any way to do this without paying such an enormous penalty for
> working in "development mode?" I've tried enabling caching and then
> just depending on Tomcat to reload using the reloadable="true" in the
> context, but that carries it's own set of side-effects.
>
> Has anybody found a good way to rapidly develop Tapestry sites without
> the painful lag time between clicks? (Other than buying a quad
> processing 5Ghz development box with a hardware XML accelerator?)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Solution (Re: Development mode with LESS PAIN????)
Posted by Luc Peerdeman <lj...@xs4all.nl>.
Hi Kurtis,
Kurtis Williams wrote:
> I run Tapestry in "development mode" with the command line switch
> "-Dorg.apache.tapestry.disable-caching=true" on my Tomcat app server. I
> do this because I want to view changes to my templates and specification
> files when I hit the refresh button on my browser.
I assume you hit the refresh button on your browser after making changes
to your app.
> Has anybody found a good way to rapidly develop Tapestry sites without
> the painful lag time between clicks? (Other than buying a quad
> processing 5Ghz development box with a hardware XML accelerator?)
Yes, it actually is quite simple. Don't disable caching, do enable
reset-service, and insert the Tapestry inspector in your page
(preferably in a shell component included in every page). After you make
a change, open the inspector and clear the cache manually by calling the
(Tapestry built in) reset service. Then refresh your browser page.
It is two mouse clicks more per refresh action, but the good thing is
your pages work as fast as they would in production. Especially for
pages or page flows that are a little bit more complex this is a great
advantage.
Another possibility to call the reset service is to try to load a url
like this one in your browser:
http://localhost:9080/myapp/app?service=reset/nonexistingpage
I was quite annoyed (with myself) that I only found out about this last
month after having spent far too much 'waiting time' when testing part
of our Tapestry app.
Btw, a feature request has been made for Spindle to have it do all this
automatically after a save action in Eclipse. This will save you the
extra mouse clicks. See
http://sourceforge.net/tracker/index.php?func=detail&aid=1083383&group_id=50321&atid=459331
Cheers, Luc.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN????
Posted by Jamie Orchard-Hays <ja...@dang.com>.
How much lag are you experiencing? I develop on a gigahertz Pentium Thinkpad
(not a Centrino, either) and I don't have a long lag with caching disabled.
Jamie
----- Original Message -----
From: "Kurtis Williams" <kw...@mshare.net>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Friday, January 14, 2005 1:28 PM
Subject: Development mode with LESS PAIN????
[Cue desperate wail for help]
I run Tapestry in "development mode" with the command line switch
"-Dorg.apache.tapestry.disable-caching=true" on my Tomcat app server. I
do this because I want to view changes to my templates and specification
files when I hit the refresh button on my browser.
But (and this is a BIG but) this mode is so utterly painful to work with
that it almost eliminates the productivity gains I've made by switching
to Tapestry in the first place (OK, that's an exaggeration, but as we
established before, I'm desperate!)
[Cue second pathetic cry for help]
Is there any way to do this without paying such an enormous penalty for
working in "development mode?" I've tried enabling caching and then
just depending on Tomcat to reload using the reloadable="true" in the
context, but that carries it's own set of side-effects.
Has anybody found a good way to rapidly develop Tapestry sites without
the painful lag time between clicks? (Other than buying a quad
processing 5Ghz development box with a hardware XML accelerator?)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN????
Posted by Luc Peerdeman <lj...@xs4all.nl>.
Hi Kurtis,
Kurtis Williams wrote:
> Has anybody found a good way to rapidly develop Tapestry sites without
> the painful lag time between clicks? (Other than buying a quad
> processing 5Ghz development box with a hardware XML accelerator?)
Yes, and it actually is quite simple. Don't disable caching, do enable
reset-service, and insert the Tapestry inspector in your page
(preferably in a shell component included in every page). After you make
a change, open the inspector and clear the cache manually by calling the
(Tapestry built in) reset service. Then refresh your browser page.
It is two mouse clicks more per refresh action, but the good thing is
your pages work as fast as they would in production. Especially for
pages or page flows that are a little bit more complex this is a great
advantage.
Another possibility to call the reset service is to try to load a url
like this one in your browser:
http://localhost:9080/myapp/app?service=reset/nonexistingpage
I was quite annoyed (with myself) that I only found out about this last
month after having spent far too much 'waiting time' when testing part
of our Tapestry app.
Btw, a feature request has been made for Spindle to have it do all this
automatically after a save action in Eclipse. This will save you the
extra mouse clicks. See
http://sourceforge.net/tracker/index.php?func=detail&aid=1083383&group_id=50321&atid=459331
Cheers, Luc.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN????
Posted by Marcus Brito <mb...@gmail.com>.
Sure, developing with caching disable is slower that doing that with
caching enabled -- but nothing as unsustainable as you mentioned, just
a couple of seconds to load a page.
Not to mention that JSP pages perform WAY slower after a modification.
It's just not fair to compare Tapestry and JSP's.
-- Marcus Brito
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN????
Posted by Bruno Sanguinetti <ke...@sussex.ac.uk>.
I was experiencing some slowness (about 1s or so), somehow it is much
faster now that I use the latest tomcat (5.5.4) and jdk 1.5, I now get
times less than .5s this on a 1.8GHz pentiumM with 1G RAM.
jm2c
On Fri, 14 Jan 2005 11:28:41 -0700, Kurtis Williams <kw...@mshare.net>
wrote:
> [Cue desperate wail for help]
>
> I run Tapestry in "development mode" with the command line switch
> "-Dorg.apache.tapestry.disable-caching=true" on my Tomcat app server. I
> do this because I want to view changes to my templates and specification
> files when I hit the refresh button on my browser.
>
> But (and this is a BIG but) this mode is so utterly painful to work with
> that it almost eliminates the productivity gains I've made by switching
> to Tapestry in the first place (OK, that's an exaggeration, but as we
> established before, I'm desperate!)
>
> [Cue second pathetic cry for help]
>
> Is there any way to do this without paying such an enormous penalty for
> working in "development mode?" I've tried enabling caching and then
> just depending on Tomcat to reload using the reloadable="true" in the
> context, but that carries it's own set of side-effects.
>
> Has anybody found a good way to rapidly develop Tapestry sites without
> the painful lag time between clicks? (Other than buying a quad
> processing 5Ghz development box with a hardware XML accelerator?)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN????
Posted by Konstantin Iignatyev <kg...@yahoo.com>.
>>Other than buying a quad processing 5Ghz development box with a hardware XML accelerator?
1.That is one solution
2.another is to have dual comp workstation( this is how I work) one is main dualscreen Linux machine for IDE and servers, and another is Windows comp for browser etc. Such config is more efficient than dual processor comp. Do not forget Synergy for sharing keyboard, mouse and CLIPBOARD between machines http://kgionline.com/articles/productivity_ws/workstation.jsp
3. Firefox browser performs miserably ( I have impression that it is especially true for non XHTML)
4. Tapestry could internally check modification time on resources in a development mode and do not reparse everything blindly - that would be a welcome addition!
Kurtis Williams wrote:
>[Cue desperate wail for help]
>
>I run Tapestry in "development mode" with the command line switch
>"-Dorg.apache.tapestry.disable-caching=true" on my Tomcat app server. I
>do this because I want to view changes to my templates and specification
>files when I hit the refresh button on my browser.
>
>But (and this is a BIG but) this mode is so utterly painful to work with
>that it almost eliminates the productivity gains I've made by switching
>to Tapestry in the first place (OK, that's an exaggeration, but as we
>established before, I'm desperate!)
>
>[Cue second pathetic cry for help]
>
>Is there any way to do this without paying such an enormous penalty for
>working in "development mode?" I've tried enabling caching and then
>just depending on Tomcat to reload using the reloadable="true" in the
>context, but that carries it's own set of side-effects.
>
>Has anybody found a good way to rapidly develop Tapestry sites without
>the painful lag time between clicks? (Other than buying a quad
>processing 5Ghz development box with a hardware XML accelerator?)
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
--
Thanks,
Konstantin Ignatyev
http://www.kgionline.com
PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2.700 tons of CFCs to the stratosphere, and increase their population by 263.000
Bowers, C.A. The Culture of Denial:
Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools.
New York: State University of New York Press, 1997: (4) (5) (p.206)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Development mode with LESS PAIN????
Posted by Howard Lewis Ship <hl...@gmail.com>.
I can see that people are having some pretty wild differences w.r.t.
load times when caching is disabled. I suspect there's a lot of
tuning to be done, even in development mode: heap size, GC config,
etc.
I would love to see a smarter, JSP-like, reloading of Tapestry pages
and components. I have, in my mind, a rough sketch of how it would
work. There's some prioritizing in my mind (and hopefully in the dev
mailing list) about what will go into 3.1 and what will be deferred to
3.2... it would be very, very nice to get a useable 3.1 out as soon as
possible.
On Fri, 14 Jan 2005 11:28:41 -0700, Kurtis Williams
<kw...@mshare.net> wrote:
> [Cue desperate wail for help]
>
> I run Tapestry in "development mode" with the command line switch
> "-Dorg.apache.tapestry.disable-caching=true" on my Tomcat app server. I
> do this because I want to view changes to my templates and specification
> files when I hit the refresh button on my browser.
>
> But (and this is a BIG but) this mode is so utterly painful to work with
> that it almost eliminates the productivity gains I've made by switching
> to Tapestry in the first place (OK, that's an exaggeration, but as we
> established before, I'm desperate!)
>
> [Cue second pathetic cry for help]
>
> Is there any way to do this without paying such an enormous penalty for
> working in "development mode?" I've tried enabling caching and then
> just depending on Tomcat to reload using the reloadable="true" in the
> context, but that carries it's own set of side-effects.
>
> Has anybody found a good way to rapidly develop Tapestry sites without
> the painful lag time between clicks? (Other than buying a quad
> processing 5Ghz development box with a hardware XML accelerator?)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org