Currently at 7.7.8 with real slow performance, 9 seconds for case listā¦
Doing analysis on sql request we found out that 1800 requests is needed to show and account! obviously something is wrong.
We have been using platform since sugar 5.x on Linux/MySQL then switched to IIS /Ms-SQL at 6.2
then migrated to SuiteCRM since almost the beginning of SuiteCRM, still on IIs MsSQL performance has been okay up to 7.7.x
I tried in test environment to use brand new install of 7.7.8 and connected to copy of production database.and performance is back like 7.2 time
Here are findings:1. All dropdown list needs to be redefined
Needed to migrate upload directory to new code
all views needs to be redefined
Needed to re enter security credentials for LDAP bindings (may be because of different host server?)
Obviously I will need to look after my logic hooks and other customisation performed⦠but
What else should I prepare time for to get the system to run properly with less disturbance to my users on the new code?
Many of those things you list will be immediately passed over if you copy the custom directory.
However, I would be very careful with that because a lot of AOP/AOW/AOS stuff was moved away from the custom directory around version 7.4, and itās easy to mess things up. (This might even be the cause for your problem).
You run the risk of passing your problem to the new server while copying customizations, hooks, etc.
If I were you, I would first try to pinpoint more accurately whatās going wrong with your system. Can you debug the code and see what itās doing to create all those queries? You must have some hook gone crazy, running around in an infinite loop or something. Even if you canāt solve the bug, you can know what to avoid copying into the new system.
Regarding dropdowns: you can just look for the file: custom/include/language/en_us.lanf.php (or other language files you are using).
You will find inside all the definitions of your dropdown lists (not the layouts).
I recommend that you back things up before you touch anything. Then you could compare thje files from the old and the new system and add the missing things.
If you copy the entire file you may overwrite other needed things so I wouldnāt recommend it.
I will only copy my own custom stuff if not in āstandardā install.
And I will make sure there is no problem with it⦠actually really simple stuff.
@pgr I do see a lot of meeting queries
but my current code is like the corrected one from githubā¦
Before I looked I was sure this was the problemā¦
Iām not sure if that fix prevents the delays once the system is filled with too many lines in the database⦠maybe all it does is keep those lines from being generated in the first place.
So, even if your code is now fixed, you could try checking the database (that notification table). Some people fixed their systems with just this SQL in phpMyAdmin (use at your own risk):
update āremindersā
set deleted = 1
where deleted = 0
It was a bug. There was a hard coded date in the code, after a certain moment in history it starts generating lines in the database. Itās been fixed for a long time, but it was an ugly and serious bug. Itās so illogical it must have been one of those cases where the developer means to change it before shipping, but then forgets to, or ships the wrong version of the codeā¦