Thread Details
  • State Not Answered
  • Replies 3 replies
  • Subscribers 353 subscribers
  • Views 606 views
  • Users 0 members are here
Forum Actions
Related

Optimize Logic Hooks and API Response Time

Krishna Mohan

We are currently using Sugar Enterprise 14.0 onsite and have implemented custom logic hooks and API endpoints to handle some of our complex business processes. However, we are experiencing performance issue with response times of these customizations and are seeking your assistance to optimize them.
Issue Faced: -
The response times for both the logic hooks and API calls are longer than expected.
There is noticeable delay which impacts the user experience and overall system performance.
Request for Assistance: -
Could you provide best practices for writing efficient logic hooks and in API (like load relationship function or else)?
Are there any inbuilt functions or methods in SugarCRM that can help optimize database queries or API responses?
Any recommendation on caching mechanism or other techniques to reduce response time?
Are there any tools or built-in features in SugarCRM for profiling and optimizing custom code?
If possible, please provide example code snippets or reference implementations that demonstrate efficient use of logic hooks and custom API endpoints.
Thank you for your support and looking forward to your response.

Parents
  • 0 Sugar Employee Badge

    Hello Krishna,

    Thank you for bringing this up!

    Both Jeff and Vlad's comments are spot on. Profiling your actions to identify bottlenecks is a great start, and offloading logic to the schedulers is a common approach to reduce processing time for users.

    Additionally, I recommend using SugarCRM to log slow queries and focus on optimizing them in the database, adding indexes where necessary.


    Regarding your mention of loading relationships, I’d like to add something specific to that scenario. In my daily work, I often see developers fetching related bean objects, even if they only need the related record ID to perform an update. 

    If you identify such scenarios in your codebase, a more efficient approach would be to retrieve the related IDs using SugarQuery.
    Here’s a code snippet that can be adapted to retrieve IDs:

    Retrieving a Bean by Unique Field

    After obtaining the IDs, you can then fetch the bean and perform the required updates like so:

    Updating a Bean

    The advantage of this approach is that you maintain record-level security using SugarQuery while performing only a single query to the database to fetch the IDs of the related records, instead of loading the full related bean object.

    I hope this helps with your scenario.

    Cheers,

    André

Reply
  • 0 Sugar Employee Badge

    Hello Krishna,

    Thank you for bringing this up!

    Both Jeff and Vlad's comments are spot on. Profiling your actions to identify bottlenecks is a great start, and offloading logic to the schedulers is a common approach to reduce processing time for users.

    Additionally, I recommend using SugarCRM to log slow queries and focus on optimizing them in the database, adding indexes where necessary.


    Regarding your mention of loading relationships, I’d like to add something specific to that scenario. In my daily work, I often see developers fetching related bean objects, even if they only need the related record ID to perform an update. 

    If you identify such scenarios in your codebase, a more efficient approach would be to retrieve the related IDs using SugarQuery.
    Here’s a code snippet that can be adapted to retrieve IDs:

    Retrieving a Bean by Unique Field

    After obtaining the IDs, you can then fetch the bean and perform the required updates like so:

    Updating a Bean

    The advantage of this approach is that you maintain record-level security using SugarQuery while performing only a single query to the database to fetch the IDs of the related records, instead of loading the full related bean object.

    I hope this helps with your scenario.

    Cheers,

    André

Children
No Data