topic Re: Performance issue with 3.2r2 in Alfresco Archive

Performance issue with 3.2r2

gyro_gearless — Wed, 14 Apr 2010 15:42:22 GMT

Hi folks,currently i am facing some serious performance problems when working with Explorer - e.g. it takes ages (some 30+ seconds) to display the first page of an folder containing some 600 documents.Digging in the log files revealed that oviously Hibernate emits some less than optimal queries. Her

Re: Performance issue with 3.2r2

gyro_gearless — Fri, 23 Apr 2010 08:38:05 GMT

Update:
Out of despair, i tried the same with MySQL instead of PostgreSQL: same result.

Displaying the first page in a space containing some 500+ Documents takes about 35 seconds. Ouch, even slower than the legacy DMS Alfresco is supposed to replace :mrgreen:

Cheers
GYro

Re: Performance issue with 3.2r2

ssaravanan — Fri, 23 Apr 2010 11:45:41 GMT

The performance depends on many things, not just the DB alone.
Whats your memory, CPU speed, JVM tuning ,etc are some of the main factors
which probably need to be investigated. Chrome & Firefox seems to be much
faster in executing rich Ajax apps

Re: Performance issue with 3.2r2

marco_altieri — Wed, 05 May 2010 13:45:58 GMT

In my opinion, 500 documents in a single folder are too much for Alfresco.
With a better hardware, It could be faster, but it would be slow anyway.

Re: Performance issue with 3.2r2

mabayona — Wed, 05 May 2010 14:22:14 GMT

I´ve seen same sharp performance degradation in Alfresco Explorer after migrating from 3.0 to 3.2r2.

It happened in two different servers, both with linux and 2 and 4 Gbytes of RAM + MySQL.

It takes now about 10 seconds to display the first page of a space with 240 subspaces (paged in chunks of 20 as per default configuration). Before with 3.0 (same configuration, same data, same all, just upgraded from 3.0 to 3.2r2) it took less than a second to display the very same space.

Definitly something has changed in this area between 3.0 and 3.2r2.

It has to do with caching, but only partially, because if same space is reloaded, it takes less time (about 4 seconds) but still much more that in 3.0.

Any idea why?

Re: Performance issue with 3.2r2

mabayona — Fri, 07 May 2010 16:19:30 GMT

Probably this problem is explained with detail in:

http://forums.alfresco.com/en/viewtopic.php?f=6&t=26544

Re: Performance issue with 3.2r2

luca — Wed, 16 Jun 2010 13:35:10 GMT

I have similar problems, but I want to add some considerations.

Looking at the DB, PostgreSQl in my case, I noticed some difference from 3.0 schema and 3.2 that might cause some problems.
In particular adding some indexes I open the web client in 1.68 second instead of 10.38 seconds without indexes!

I'm still testing it, does anyone could say me if I'm running in others trouble or it could be a good solution?

Here's the SQL script to add indexes:


CREATE INDEX fk_alf_ace_auth ON alf_access_control_entry USING btree (authority_id);
CREATE INDEX fk_alf_ace_ctx ON alf_access_control_entry USING btree (context_id);
CREATE INDEX fk_alf_ace_perm ON alf_access_control_entry USING btree (permission_id);
CREATE INDEX fk_alf_acl_acs ON alf_access_control_list USING btree (acl_change_set);
CREATE INDEX fk_alf_aclm_ace ON alf_acl_member USING btree (ace_id);
CREATE INDEX fk_alf_aclm_acl ON alf_acl_member USING btree (acl_id);
CREATE INDEX fk_alf_adtf_conf ON alf_audit_fact USING btree (audit_conf_id);
CREATE INDEX fk_alf_adtf_date ON alf_audit_fact USING btree (audit_date_id);
CREATE INDEX fk_alf_adtf_src ON alf_audit_fact USING btree (audit_source_id);
CREATE INDEX fk_alf_attr_acl ON alf_attributes USING btree (acl_id);
CREATE INDEX fk_alf_autha_ali ON alf_authority_alias USING btree (alias_id);
CREATE INDEX fk_alf_autha_aut ON alf_authority_alias USING btree (auth_id);
CREATE INDEX fk_alf_cass_cnode ON alf_child_assoc USING btree (child_node_id);
CREATE INDEX fk_alf_cass_pnode ON alf_child_assoc USING btree (parent_node_id);
CREATE INDEX fk_alf_gatt_att ON alf_global_attributes USING btree (attribute);
CREATE INDEX fk_alf_lent_att ON alf_list_attribute_entries USING btree (attribute_id);
CREATE INDEX fk_alf_lent_latt ON alf_list_attribute_entries USING btree (list_id);
CREATE INDEX fk_alf_matt_att ON alf_map_attribute_entries USING btree (attribute_id);
CREATE INDEX fk_alf_matt_matt ON alf_map_attribute_entries USING btree (map_id);
CREATE INDEX fk_alf_nasp_n ON alf_node_aspects USING btree (node_id);
CREATE INDEX fk_alf_nass_snode ON alf_node_assoc USING btree (source_node_id);
CREATE INDEX fk_alf_nass_tnode ON alf_node_assoc USING btree (target_node_id);
CREATE INDEX fk_alf_node_acl ON alf_node USING btree (acl_id);
CREATE INDEX fk_alf_node_store ON alf_node USING btree (store_id);
CREATE INDEX fk_alf_node_txn ON alf_node USING btree (transaction_id);
CREATE INDEX fk_alf_nprop_n ON alf_node_properties USING btree (node_id);
CREATE INDEX fk_alf_qname_ns ON alf_qname USING btree (ns_id);
CREATE INDEX fk_alf_store_root ON alf_store USING btree (root_node_id);
CREATE INDEX fk_alf_txn_svr ON alf_transaction USING btree (server_id);
CREATE INDEX fk_alf_usaged_n ON alf_usage_delta USING btree (node_id);
CREATE INDEX fk_avm_s_acl ON avm_stores USING btree (acl_id);
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Re: Performance issue with 3.2r2

gyro_gearless — Wed, 16 Jun 2010 17:02:27 GMT

Hi,

i just tried the missing indexes on some lame system - cool, this turbocharged ALfresco to show some folder which took 40+ seconds before to show up in 10 seconds. Of course, i had to do a VACUUM ANALYZE first to get the speed-up :mrgreen:

Together with an increase of shared_buffers in postgresql.conf (1000 -> 32768) this yielded some 700% performance boost….

Thanks a lot, this saved our day!

Cheers
Gyro

Re: Performance issue with 3.2r2

luca — Thu, 17 Jun 2010 15:07:39 GMT

Hi gyro, glad to help you!

I also applied some patch on HibernateNodeDaoServiceImpl from Alfresco 3.3, in particular cacheNodesNoBatch method I changed the beginning like this:

    private void cacheNodesNoBatch(Store store, List<String> uuids)
    {
        Criteria criteria = getSession().createCriteria(NodeImpl.class, "node");
        criteria.setResultTransformer(Criteria.ROOT_ENTITY);
        criteria.add(Restrictions.eq("store.id", store.getId()));
        criteria.add(Restrictions.in("uuid", uuids));
        criteria.setCacheMode(CacheMode.PUT);
        criteria.setFlushMode(FlushMode.MANUAL);

        List<Node> nodeList = criteria.list();
        Set<Long> nodeIds = new HashSet<Long>(nodeList.size()*2);
        for (Node node : nodeList)
        {
            // We have duplicate nodes, so make sure we only process each node once
            Long nodeId = node.getId();
            if (!nodeIds.add(nodeId))
            {
                // Already processed
                continue;
            }
            storeAndNodeIdCache.put(node.getNodeRef(), nodeId);
            nodeIds.add(nodeId);
        } 
…‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I found also some problems related to the search that is very slow although the patches.
Are You experiencing this problem like me? Did you find a solution?