[opencms-dev] OpenCms 7.0.5 crashes with high load

Christian Steinert christian_steinert at web.de
Tue Mar 31 16:56:31 CEST 2009


I had mentioned these things before, but maybe giving a little more detail is helpful:

If you want to make best use of flex cache, you could create a template structure that is like this:
- Your pages have JSP templates
- Your regular JSP templates use one helper JSP (the template-elements file) to include all needed elements
- The template-elements file is NOT cached, it is just a wrapper for complex inclusion
- in the template-elements file, you include lots of small JSP files that each produce one single part of the page

-> for these small JSP files, you can then set the cache-properties in such a way that they are optimal for the type of content that is generated.
  For example, an element that generates the global naviation menu could be re-used for all pages that have the same locale.
  To do this, the cache property of that JSP file needs to be set to "__locale"
-> if you have a template part that differs based on a specified URL parameter, you could use the "parameters(...)" caching directive
  to control the re-use of cached element copies
-> and so on. Try to set optimal cache settings for each separate region of your page. Then use the variants list to look which variants are generated by the cms for each template part. Be careful to make the cache re-use not too permissive - otherwise you can end up with incorrect template parts on pages where they should not appear.

Segmenting your templates in such a way should help to improve the performance for those parts of your page that are re-usable and usually requires very little memory. 

Static export on demand is orthogonal to that and speeds up the delivery of completed pages that can be re-used until the next publish operation. Since you say that your site is quite dynamic, this may not work everywhere for you. If your pages are shortlived then you can also try to cache some complete pages by caching each of your templates with one variant per URI and short expiry time. This cachese the resultant pages in memory for a while, if you can afford them to be at least a little stale. 

hth
Christian

> Thank you all for your clever insights.
> 
> I think I understood correctly the problem because my line of 
> thoughts was somehow similar to yours. I would have loved the Alkacon 
> guys giving their expert opinion, but nevertheless the information is 
> top quality.
> 
> We tried Shi Yusen modifications on the code (the ones that closes 
> much more all conections opened), and oddly the guys making the tests 
> noticed no improvements when the pool is in "blocked" mode and max 
> connections are high to 50-100.
> 
> Now we are working on the line of static exports and better flex 
> cache. If we develop something original and useful to the community, 
> needless is to say we will contribute it. Thanks again. Greetings,
> 
> Nacho Fernandez.
> _______________________________________________ This mail is sent to 
> you from the opencms-dev mailing list To change your list options, or 
> to unsubscribe from the list, please visit http://lists.opencms.org/
> 
> mailman/listinfo/opencms-dev


____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört? 
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123




More information about the opencms-dev mailing list