Julien Viet wrote:
how much was performance degrading ?
  
In shortcut, tests from revision 1010 (before patch commit) show throughput numbers with big load bigger than 550 samples(HTTP requests) / s. In Revision 1012 (after patch commit) best throughput was 463 samples/s. In revision 1025 (after patch reverting) throughput and mean response time was back to similar values as in revision 1010. Here are more detailed results from all 3 tests:

1) revision 1010

Nodes: 1, Sessions: 500, active: 500, samples: 50376, throughput 279.8 samples/s, 11,885,653.5 bytes/s, mean response: 79 ms, sampling errors: 0, invalid samples: 50, valid samples: 50326 (99%)
Nodes: 1, Sessions: 800, active: 800, samples: 70451, throughput 391.3 samples/s, -11,928,909.7 bytes/s, mean response: 38 ms, sampling errors: 0, invalid samples: 0, valid samples: 70451 (100%)
Nodes: 1, Sessions: 1100, active: 1100, samples: 92851, throughput 515.8 samples/s, -11,928,920.2 bytes/s, mean response: 125 ms, sampling errors: 0, invalid samples: 23, valid samples: 92828 (99%)
Nodes: 1, Sessions: 1400, active: 1400, samples: 98814, throughput 548.9 samples/s, -11,928,862.6 bytes/s, mean response: 542 ms, sampling errors: 0, invalid samples: 445, valid samples: 98369 (99%)
Nodes: 1, Sessions: 1700, active: 1700, samples: 99574, throughput 553.1 samples/s, -11,928,824.2 bytes/s, mean response: 1068 ms, sampling errors: 0, invalid samples: 195, valid samples: 99379 (99%)
Nodes: 1, Sessions: 2000, active: 2000, samples: 98428, throughput 546.7 samples/s, -11,928,648.2 bytes/s, mean response: 1653 ms, sampling errors: 0, invalid samples: 2771, valid samples: 95657 (97%)
Nodes: 1, Sessions: 2300, active: 2300, samples: 97263, throughput 540.3 samples/s, -11,928,892.2 bytes/s, mean response: 2181 ms, sampling errors: 0, invalid samples: 3669, valid samples: 93594 (96%)
Nodes: 1, Sessions: 2600, active: 2600, samples: 100675, throughput 559.2 samples/s, -11,928,728.3 bytes/s, mean response: 2598 ms, sampling errors: 13, invalid samples: 7717, valid samples: 92945 (92%)

2) Revision 1012

Nodes: 1, Sessions: 500, active: 500, samples: 48988, throughput 272.1 samples/s, 11,461,718.4 bytes/s, mean response: 137 ms, sampling errors: 0, invalid samples: 50, valid samples: 48938 (99%)
Nodes: 1, Sessions: 800, active: 800, samples: 64433, throughput 357.9 samples/s, -11,928,733.8 bytes/s, mean response: 232 ms, sampling errors: 0, invalid samples: 211, valid samples: 64222 (99%)
Nodes: 1, Sessions: 1100, active: 1100, samples: 83344, throughput 463.0 samples/s, -11,928,876.1 bytes/s, mean response: 366 ms, sampling errors: 0, invalid samples: 362, valid samples: 82982 (99%)
Nodes: 1, Sessions: 1400, active: 1400, samples: 79022, throughput 439.0 samples/s, -11,928,803.7 bytes/s, mean response: 1189 ms, sampling errors: 0, invalid samples: 1462, valid samples: 77560 (98%)
Nodes: 1, Sessions: 1700, active: 1699, samples: 71334, throughput 396.2 samples/s, -11,928,857.3 bytes/s, mean response: 2251 ms, sampling errors: 0, invalid samples: 3305, valid samples: 68029 (95%)
Nodes: 1, Sessions: 2000, active: 2000, samples: 72807, throughput 404.4 samples/s, -11,928,893.2 bytes/s, mean response: 2865 ms, sampling errors: 0, invalid samples: 5460, valid samples: 67347 (92%)
Nodes: 1, Sessions: 2300, active: 2291, samples: 74245, throughput 412.4 samples/s, -11,928,861.8 bytes/s, mean response: 3423 ms, sampling errors: 41, invalid samples: 6930, valid samples: 67274 (90%)

3) Revision 1025

Nodes: 1, Sessions: 500, active: 500, samples: 50123, throughput 278.4 samples/s, 11,879,908.4 bytes/s, mean response: 85 ms, sampling errors: 0, invalid samples: 50, valid samples: 50073 (99%)
Nodes: 1, Sessions: 800, active: 800, samples: 71070, throughput 394.8 samples/s, -11,928,707.7 bytes/s, mean response: 21 ms, sampling errors: 0, invalid samples: 0, valid samples: 71070 (100%)
Nodes: 1, Sessions: 1100, active: 1100, samples: 94914, throughput 527.2 samples/s, -11,928,737.8 bytes/s, mean response: 80 ms, sampling errors: 0, invalid samples: 0, valid samples: 94914 (100%)
Nodes: 1, Sessions: 1400, active: 1400, samples: 102960, throughput 571.9 samples/s, -11,928,745.6 bytes/s, mean response: 441 ms, sampling errors: 0, invalid samples: 445, valid samples: 102515 (99%)
Nodes: 1, Sessions: 1700, active: 1700, samples: 100837, throughput 560.1 samples/s, -11,928,794.4 bytes/s, mean response: 1025 ms, sampling errors: 0, invalid samples: 190, valid samples: 100647 (99%)
Nodes: 1, Sessions: 2000, active: 2000, samples: 99385, throughput 552.1 samples/s, -11,928,724.3 bytes/s, mean response: 1621 ms, sampling errors: 0, invalid samples: 2405, valid samples: 96980 (97%)
Nodes: 1, Sessions: 2300, active: 2300, samples: 99707, throughput 553.9 samples/s, -11,928,730.3 bytes/s, mean response: 2071 ms, sampling errors: 3, invalid samples: 4123, valid samples: 95581 (95%)


On Dec 16, 2009, at 12:02 AM, Matt Wringe wrote:

  
On Sun, 2009-12-06 at 19:29 -0500, Matt Wringe wrote:
    
On Wed, 2009-12-02 at 15:16 -0500, Matt Wringe wrote:
      
On Wed, 2009-12-02 at 20:31 +0100, Julien Viet wrote:
        
Have you studied the possibility to make the ui component
UIPortalApplication to buffer the content of its rendered children.
          
The only way to buffer the children it to create a temporary  
writer and
have the children write their content to that. The children by  
default
will try to write directly to the response writer. This was one of  
the
options mentioned in my last email.
I already have something almost finished that will do this.
        
patch for it was added here a few days ago:
https://jira.jboss.org/jira/browse/GTNPORTAL-321

The output of the children is sent to a temporary writer before the  
head
of the page is rendered. Then the page is rendered normally, except  
it
uses the output from the writer for the child elements.
      
I committed the patch yesterday but reverted it back due to  
performance
degradation with using a temporary writer.
I will need to figure out a way to do with without affecting
performance, or make it configurable so that its off by default.

    
When the rendering is terminated the UIPortalApplication  
component can
do two things:

1/ setup the HTTP headers (if we do support it)

2/ update its state to store the headers and then have them  
pulled by
the template UIPortalApplication.gtmpl

The control flow could be modified to follow:

1/ called process render on its children and buffer the byte array
response
2/ update its state with the buffered response and the headers
3/ output HTTP headers
4/ call render template to render the UIPortalApplication.gtmpl
5/ in the uicomponent.renderChildren() callback send the buffered
response
6/ in a finally block clear the transient state (buffered  
response and
headers)

On Dec 2, 2009, at 8:12 PM, Matt Wringe wrote:

          
I am trying to get portlet markup headers working with gatein.  
This
allows portlets to set content in the html head of the portal  
page.
This
only works if the portlets are processed before the page gets
generated,
which is currently not the case.

We can get around this by creating a preRender phase to the webui
lifecycle. This phase would generate the markup for the  
uicomponent
and
store it. When the processRender phase occurs, it will just  
retrieve
this stored markup.
Adding a new phase to the lifecycle is going to require a bunch of
changes to webui.

I already have a simple proof of concept with a preRender phase  
that
is
working with portlets to allow setting the html head.

Before I get too far with this, I would to know if anyone else  
has any
better ideas about how to handle this.

We could modify the html head using javascript that gets called  
when
the
page is loaded. This will work and would be easy to implement, but
seems
like a hack.

I looked into seeing if we could just modify how the
UIPortalApplication
gets rendered so that we wouldn't need to touch the rest of the  
webui
lifecyle. We could do something like render the html body to a
temporary
writer first, but this is a messy hack.

_______________________________________________
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
            
_______________________________________________
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
        
_______________________________________________
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
    

_______________________________________________
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev