cancel
Showing results for 
Search instead for 
Did you mean: 

Help troubleshoot slow performance

steel
Champ in-the-making
Champ in-the-making
My repository has roughtly 13,000 documents. Total document size is around 5GB.  Operations such as checkin and checkout are noticable slower with this volume of content. Checking a document out takes 30 seconds to 1 minute and making a node versionable could take 5 minutes. I have profiled the system and the primary call that takes so long is the get child assoc call off the DB Node Service Impl. The JDBC query it calls consumes most of the time.  The database is on a dedicated server with 2GB of ram and is optimized to give max performance.

Any ideas on what might be going on?  I have read posts that Alfresco has been tested with a million documents, but whats the response time with that many documents?

The Tomcat server has 1GB heap size and runs on a Dual Xeon system with 3GB of ram.  The db server is also a dual Xeon with 2GB of ram. 

Any help with be gladly appreciated.

thanks.
3 REPLIES 3

derek
Star Contributor
Star Contributor
Hi,

What version of the repo are you running?
What is the structure of the documents?
The following query will work for a 1.3 repo on MySQL - the top 10 results would be useful.

select parent_node_id, count(child_node_id) children from child_assoc group by parent_node_id order by children desc limit 10;

Regards

steel
Champ in-the-making
Champ in-the-making
I do not have a "parent_node_id" field in my child_assoc table. Instead I used this query:

select parent_guid, count(child_identifier) children from child_assoc group by parent_guid order by children desc limit 10; 

Results:

<ROOT>
    <row>
      <field name="parent_guid">89f5d761-a00d-11da-a55c-cfc22b16149b</field>
      <field name="children">17261</field>
    </row>
    <row>
      <field name="parent_guid">12f87c3d-0c6b-11db-a416-cd1113b93183</field>
      <field name="children">3791</field>
    </row>
    <row>
      <field name="parent_guid">3bcabb5d-a231-11da-a01a-839237687f45</field>
      <field name="children">1707</field>
    </row>
    <row>
      <field name="parent_guid">7ad422f1-a00e-11da-a55c-cfc22b16149b</field>
      <field name="children">903</field>
    </row>
    <row>
      <field name="parent_guid">1d586e22-0c6b-11db-a416-cd1113b93183</field>
      <field name="children">109</field>
    </row>
    <row>
      <field name="parent_guid">1331b4b4-0c6b-11db-a416-cd1113b93183</field>
      <field name="children">106</field>
    </row>
    <row>
      <field name="parent_guid">1d98d289-0c6b-11db-a416-cd1113b93183</field>
      <field name="children">106</field>
    </row>
    <row>
      <field name="parent_guid">88cf918a-0c6b-11db-a416-cd1113b93183</field>
      <field name="children">98</field>
    </row>
    <row>
      <field name="parent_guid">1de51dd0-0c6b-11db-a416-cd1113b93183</field>
      <field name="children">94</field>
    </row>
    <row>
      <field name="parent_guid">1d09d8eb-0c6b-11db-a416-cd1113b93183</field>
      <field name="children">94</field>
    </row>
</ROOT>

I am using repository version 1.2 and the documents are scattered throughout a large tree.

derek
Star Contributor
Star Contributor
Hi,

The good news is that the 1.3 schema results in less data and uses Hibernate's ability to apply the indexes that will deal with the scalability issue you are experiencing.

Provided you have a scattered structure, you should find that the system scales much better with 1.3.  You'll have to update to 1.2.1 and then to 1.3.1.

Regards