<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Production performance tuning in Alfresco Archive</title>
    <link>https://connect.hyland.com/t5/alfresco-archive/production-performance-tuning/m-p/45399#M25249</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;Your analysis is good.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;The jobexecutor might need tuning to but check if it is a bottleneck first since afaik configuring it not exposed (yet?) in the config (see) modules/activiti-engine/src/main/java/org/activiti/engine/impl/cfg/ProcessEngineConfigurationImpl.java but harcoded in modules/activiti-engine/src/main/java/org/activiti/engine/impl/jobexecutor/JobExecutor.java&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;The engine itself has a low fairly low footprint, so I'd not care about that. Each process instances that is in a waitstate (usertask, receivetask etc) does not occupy any memory. A process instance only occupies memory if it is actually loaded from the db because it has to 'run'. How much is dependend on e.g. variables loaded etc, but it is not high either. &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Adding indexes should indeed be done according to your needs since the default engine cannot cater for all usecases. A query analyzer helps a lot here. &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Adding to many howeve can lead to performance degradation since the index has to be updated each time a record is added but I suspect you already know that.&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 27 Apr 2011 19:08:11 GMT</pubDate>
    <dc:creator>ronald_van_kuij</dc:creator>
    <dc:date>2011-04-27T19:08:11Z</dc:date>
    <item>
      <title>Production performance tuning</title>
      <link>https://connect.hyland.com/t5/alfresco-archive/production-performance-tuning/m-p/45398#M25248</link>
      <description>We're planning production resources and are wondering if there are any sizing/tuning guidelines specifically for Activiti.&amp;nbsp; I'm guessing that the guidelines for things like database connection and thread pool sizes for the app server it's running in are pretty standard (basically, at least one threa</description>
      <pubDate>Wed, 27 Apr 2011 15:59:41 GMT</pubDate>
      <guid>https://connect.hyland.com/t5/alfresco-archive/production-performance-tuning/m-p/45398#M25248</guid>
      <dc:creator>bwd</dc:creator>
      <dc:date>2011-04-27T15:59:41Z</dc:date>
    </item>
    <item>
      <title>Re: Production performance tuning</title>
      <link>https://connect.hyland.com/t5/alfresco-archive/production-performance-tuning/m-p/45399#M25249</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;Your analysis is good.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;The jobexecutor might need tuning to but check if it is a bottleneck first since afaik configuring it not exposed (yet?) in the config (see) modules/activiti-engine/src/main/java/org/activiti/engine/impl/cfg/ProcessEngineConfigurationImpl.java but harcoded in modules/activiti-engine/src/main/java/org/activiti/engine/impl/jobexecutor/JobExecutor.java&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;The engine itself has a low fairly low footprint, so I'd not care about that. Each process instances that is in a waitstate (usertask, receivetask etc) does not occupy any memory. A process instance only occupies memory if it is actually loaded from the db because it has to 'run'. How much is dependend on e.g. variables loaded etc, but it is not high either. &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Adding indexes should indeed be done according to your needs since the default engine cannot cater for all usecases. A query analyzer helps a lot here. &lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Adding to many howeve can lead to performance degradation since the index has to be updated each time a record is added but I suspect you already know that.&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 27 Apr 2011 19:08:11 GMT</pubDate>
      <guid>https://connect.hyland.com/t5/alfresco-archive/production-performance-tuning/m-p/45399#M25249</guid>
      <dc:creator>ronald_van_kuij</dc:creator>
      <dc:date>2011-04-27T19:08:11Z</dc:date>
    </item>
    <item>
      <title>Re: Production performance tuning</title>
      <link>https://connect.hyland.com/t5/alfresco-archive/production-performance-tuning/m-p/45400#M25250</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;From my experiments:&lt;/SPAN&gt;&lt;BR /&gt;&lt;UL&gt;&lt;LI&gt;Each &lt;CODE&gt;ProcessEngine&lt;/CODE&gt; has a memory footprint of about 4 MB.&lt;/LI&gt;&lt;LI&gt;The deployed processes do not use memory since they are stored in the database. However, they are cached into &lt;CODE&gt;ProcessEngineConfigurationImpl.getProcessDefinitionCache()&lt;/CODE&gt; which is basically a &lt;CODE&gt;HashMap&lt;/CODE&gt; so if you deploy thousands of processes, your memory footprint will rise. If you deploy a lot of processes, you should use a smarter process definition cache, e.g. one based on soft references so that the cache is garbage collected when the memory is low.&lt;/LI&gt;&lt;/UL&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 25 Jul 2014 07:52:07 GMT</pubDate>
      <guid>https://connect.hyland.com/t5/alfresco-archive/production-performance-tuning/m-p/45400#M25250</guid>
      <dc:creator>jkronegg</dc:creator>
      <dc:date>2014-07-25T07:52:07Z</dc:date>
    </item>
  </channel>
</rss>

