Suitecrm 7 vs 8 page load speed

I can remember testing 8 and then deciding to install 7 quite a while ago. But I canā€™t really remember why. I think it was because of the speed, some pages loaded really slow, the current suitecrm7 is also not a speed monster.

Can any one confirm that the current versions of 8 are faster and have at least the same functionality as 7?

You may have installed v7.x because the v8.x lacks some features.

The v8.7 is pretty fast as well as v7.x.

I think that it is issue with your php.ini file. You need to set some parameters correctly in order to work it well.

Here are few links for you:



https://expertincrm.medium.com/how-to-improve-the-speed-of-sugarcrm-instance-657449fd1ad7



I tried 8 on windows and it sucks.
However it really works great on ubuntu with apache and php as per the installation matrix.

You have to make sure the VM has minimum 8 GB ram and you need to allow memory of atleast 512 MB (although official documents recommend 256 MB).

You need to enable cache and also tweak mysql configuration and it should work like a charm.

Permissions are also one of the hurdles we faced but at the end, it all got sorted.
Currently 2 of my clients are using on cloud based customized SuiteCRM hosted on GCP VMs and never faced any issue with more than a million records.

Make sure you purge activities, soft deleted records and alerts.
Schedule the rebuild indexes every 2 weeks at late hours and you will thank me later :smile:

Did you update php.ini file in XAMPP?

How can we do this? Could you please provide steps? :face_with_peeking_eye: :bulb:

Yes I did update the php.ini in XAMPP but it doesnā€™t really help much.
Although I have used suiteCRM back in 2018 it used to work fine on windows servers. I will try to dig deeper in free time.

You need to create cron job for it.
I have created a node.js application and I m using node-scheduler along with mysql2 libraries. Rest depends on what you want to achieve.

const mysql = require('mysql2/promise');
const schedule = require('node-schedule');

async function rebuildIndexes() {
    const connection = await mysql.createConnection({
        host: 'localhost',
        user: 'your_user',      
        password: 'your_password', 
        database: 'your_database'
    });

    try {
        const tableName = 'Leads'; 
        await connection.execute(`OPTIMIZE TABLE ${tableName}`);
    } catch (error) {
        console.error('Error rebuilding indexes:', error);
    } finally {
        await connection.end();
    }
}

// Schedule job to run on the 15th of every month at midnight
const job = schedule.scheduleJob('0 0 15 * *', async function(){
    console.log('Running scheduled job to rebuild indexes on the 15th of the month at midnight!');
    
    await rebuildIndexes();
});

Above code basically rebuild the indexes of suitecrm Leads table every 15th of month.

1 Like

Just crazy for the 200 records I currently have.

Thatā€™ weird! can you list down your config? what os, webserver and all.

That is actually what I like, roles and security groups that seems to be ok. But this performance should be ok out of the box for someone starting with it.

Did you restart your php-fpm after making changes in the php.ini file?

Did you restart your web server after making changes in the php.ini file?

I am not applying any changes to my php.ini, that one is just fine. You also do not need to ask about restarting the webserver, nowadays most are forced to do this automatically because of these crappy short term certs. Next to that, most probably have php-fpm running so restarting a webserver does not really help.

More likely is that you probably need to do some performance debugging if you require so much resources for the little data I use.

Recently I had some dev coding in java something for ldap, he also told me to apply more resources. Turned out that the way you code is a difference of being able to handle 200 req/s or 10000 req/s. So you can imagine a bit my attitude if someone starts telling me to add more memoryā€¦

hahaha make sense! It is strange that it is running slow for 200 records.

Tried with this apc
but that was also not detected.

is this apcu already in some version?

What SuiteCRM and PHP version are you using?

SuiteCRM7 and php7

I just renamed these functions for apcu, but does not really speed things up. This 300 sec timeout is also low

It takes >2s (2.6s according to browser console) to browse to the next contact/account

index.php?module=Accounts&action=DetailView&offset=21&record=65c277cd-172f-9d8d-c9cf-63b980d8826a&ajax_load=1
takes 750ms

Thatā€™s interesting. Is it happening in all modules? Did you install it on Linux? Are these 200 records uploaded by you? Is your system has good internet speed? Are you using any firewall on same system?

Whole website response feels slow like this. Linux indeed. I had some students enter these records. Other pages also have these turtles in the console

index.php?entryPoint=retrieve_dash_page
500ms

index.php?module=Contacts&action=index&parentTab=Support&ajax_load=1&loadLanguageJS=1
633ms

There is no inherent, architectural reason for v8 to be slower than v7 (on the contrary).

And the subsequent v8 versions are getting faster, some of the minor versions had great performance improvements (and more are coming up).

So your issue is just a case of troubleshooting the performance problems in your system. I know, sometimes it can be hard to discover why, but keep trying :slight_smile:

So your issue is just a case of troubleshooting the performance problems in your system. I know, sometimes it can be hard to discover why, but keep trying

No, it is not my system. Yesterday a dev optimized first page load from my php phalcon project by 40% to 60ms. Does not have that many db queries, but nothing changed on the system. Just coding, 40% difference.

Same is with your code. You have just a text website, yet it is still a 3,5MB download? How many years ago is this switch from apc to apcu done, and I still need change it here manually? Why should I believe it is anything related to my environment, with such facts?

1 Like

Nice work on your setup! :sunglasses: Keep us posted when you figure it out. In the meantime, weā€™ll be enjoying the speed and efficiency of our SuiteCRM. :rocket: Wishing you all the best as you continue the challenge!

Other people see it working fast, thatā€™s basically why I said it could be something in your system. Performance issues are not obvious to troubleshoot.

Also, I would definitely not aim my performance troubleshooting at first page loads, full refreshes etc. I agree those are quite heavy with v8. You have to let all the caches kick in, but itā€™s designed for that, and itā€™s the normal scenario that CRM users deal with - continued use.