Poor Performance of Sugar.. can't scale?

[tnmti]

We use sugar primarily for a trouble ticket system and for calendaring for our field engineers/helpdesk.

We have been on Sugar for about 2 yrs now. Wehave over 8000 cases, and probably 750 accounts/contacts.

Our helpdesk is getting killed on the slow performance of Sugar. I replaced the server with a dual processor Zeon 3.2Ghz, and 4 GB RAM, Microsoft 2003 server and e saw marginal-to-non-existant performance increases. I also had one of our engineer take a similar box and build it as a linux box, migrated the data, thinking linux might perform better with mysql, and no performance changes.

Login into the system:
Server response time: 16.60 seconds.
2004-2007 SugarCRM Inc. All Rights Reserved.

Calendaring is the worst of all. we use the shared calander extensively to see who is hte next available engineer available to respond onsite and this is the response times.. (done at night with no-one on the system...

My calander only:
>>Server response time: 20.51 seconds.
>>© 2004-2007 SugarCRM Inc. All Rights Reserved.

Shared calander: (8 users selected)
Server response time: 17.36 seconds.
© 2004-2007 SugarCRM Inc. All Rights Reserved.

Open cases asigned to support (49 of them)
>>Server response time: 16.19 seconds.
>>© 2004-2007 SugarCRM Inc. All Rights Reserved.

Account listing
>>Server response time: 13.52 seconds.
>>© 2004-2007 SugarCRM Inc. All Rights Reserved

These query times are killing us.. Has anyone seen this and have a solution or idea? I am now looking at other systems because I am not sure this will 'scale' well. I expect to grow by 33% in the next 18 months.

-tim

[ruchida]

tim,

This performance is unusual by considering the small amount of data. How many users are using SugarCRM?

[tnmti]

we have about 10 users. of which onlyabout 5 are in at once.


I was told it has to do with queries, and the amount of data sugar returns.. but... was looking for a better answer.

-tim

[ruchida]

we have about 10 users. of which onlyabout 5 are in at once.


I was told it has to do with queries, and the amount of data sugar returns.. but... was looking for a better answer.

-tim

Do you use the Emails module intensively? If so, how many emails records do you have? I recently read a thread saying that creating an index against the "deleted" field of the emails table improves performance dramatically.

[lvangool]

Please have a look at the "Performance" links in our Wiki:

http://www.sugarcrm.com/wiki/index.p...Developer_Wiki

Please, please install a PHP cacher (I recommend APC, you can do it on windows by downloading a .dll, moving it to the php/extensions dir and mentioning it in php.ini. Please analyze your database for deleted records (they're still there...) and email attachments

Your performance isn't normal, there's hope.

[jmaxwell]

Sugar does have poor overall performance, but your numbers are much worse than normal. Did you turn on slow query logging in the sugar config file to see what queries are really dragging it down? that would be the first step I'd think. The wiki has some good info on how to up the performance, as well as some good threads buried here in the forum. Let us know how it works out.

-Ed

[fernando.mello]

I have the same problem !
Server response time: 6.46 seconds. In all pages..

My server is very fast. ,
PHP Version 5.2.2
Apache 2.0

any idea ?

thks
Fernando

[eggsurplus]

I found that creating proper indexes in the db cut the load time down to about 1/5 the time. I'd recommended putting some time into that area. You should see good results.

[ruchida]

I have the same problem !
Server response time: 6.46 seconds. In all pages..

My server is very fast. ,
PHP Version 5.2.2
Apache 2.0

any idea ?

thks
Fernando

Do you run Apache on Linux?
Please check out the link below and see if Apache has open slots.
http://www.onlamp.com/pub/a/apache/2.../wrangler.html

[Jacob]

What version of Sugar are you running? We have been addressing some scaling issues in the calendar area in 4.5.1e and 4.5.1f.

I heard yesterday about some queries that were not being correctly bounded. We are investigating this.

Can you provide a list of the your database tables with row counts sorted by number of rows? This may help provide a pointer to the problem.

Slow query logging is a huge asset. If you are getting tens of second response times on a server that fast, it is likely due to poorly performing queries. We have some additional indexes that boost performance for some module. I am looking at including them in 4.5.1f (you would have to run the DB repair after patching to see a benefit).

Adding a caching accelerator like APC or Zend Platform should get you about a 50% CPU decrease for the web server.

One issue that we have recently seen is that longer running Apache instances start to take more and more memory. Apache/PHP combination does not garbage collect memory as well as one would hope. Over time, larger reports will use large quantities of memory. Changing the max requests per child on apache to a smaller value than the default (say 1000) helps to offset this issue. How is the memory on your system looking when being used? Is there anything swapping?

Also, have you increased the memory available to MySQL beyond the defaults?

Thanks,
Jacob