[opencms-dev] Lessons learned with the calendar

[fhsubscriptions at componio.net]

Hi list,

with the introduction of Solr to OpenCms we resolved most of the
performance issues. Especially content aggregation and property
resolving/querying is a blast. However we make no use of the embedded
Solr collectors but have written our own taglibs to interface with the
Solr backend(s). Further we patched the OpenCms kernel to allow for
dynamic (reads runtime) content type mappings to Solr.

Maybe this can be a feasible solution for your cases too.

Sincerely


\Fabian



Am 27.03.15 um 15:51 schrieb Roman Uhlig:
> We had the same (bad) experience with OpenCms XML-content that reaches
> a certain amount of items (unfortunately not as many as you might think).
> It's basically as if your database would store every row as XML in a
> virtual filesystem. This just can't perform very well at all, the
> concept doesn't allow this.
> And with something complex like a calendar with events, it goes
> totally nuts. A sophisticated calendar is tricky even with a regular
> database, with XML content it's server kill. ;)
>
> Unless OpenCms is offering some database connection features (e.g.
> through Hibernate) to avoid storing everything in XML in the VFS, you
> do better with a real database solution.
>
> Am 27.03.2015 um 15:15 schrieb Alberto Gallardo:
>> Dear list,
>>
>> in the last OpenCms days I talked to some of you mentioning some
>> performance problems we were facing. I got some valuable input and
>> was asked to share our findings, in case we further analyzed the
>> situation.
>>
>> Today, seizing Deiversons Silveira post 'Problem with lucene - Old
>> Generation Memory', I wanted to share with you the main conclusion
>> after our analysis: we found that the alkacon-oamp/calendar was
>> responsible for most of the server processing time.
>>
>> It turns out that this component aggregates all existing events under
>> a configured folder. It doesn't make any difference if these are old
>> or not. Even with the OCEE accelerator, building the calendar view is
>> a very expensive operation.
>>
>> Removing the calendar from some pages bring us a ten-fold performance
>> improvement.
>>
>> Just keep in mind that content aggregation in OpenCms isn't for free.
>> It takes a lot of memory and processing time. I'm talking about
>> querying 5 properties of some 3000 events. So many elements it's
>> probably not that common, but if you are not aware of it, and you
>> have been using similar components (e.g. lists) accumulating ballast
>> during several years, it could inadvertently affect you some day.
>>
>> Regards,
>>
>>
>>
>> Alberto Gallardo
>>
>>
>> _______________________________________________
>> 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/cgi-bin/mailman/listinfo/opencms-dev
>>
>>
>>
>
>
>
> _______________________________________________
> 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/cgi-bin/mailman/listinfo/opencms-dev
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://webmail.opencms.org/pipermail/opencms-dev/attachments/20150327/050d812c/attachment.htm>