Skip to main content

I had recently investigated a performance issue in the contract window of FSM 6 UPD11.
This occurs when there are more than 1000 records in the lines tab.

When we navigate to the contract window and select the lines tab it took more than 1 minute to load the relevant data. If we navigate to another tab and comes back again to the lines tab it will load within 4-5 seconds.
I had executed the relevant hierarchy SQL in XML poster and it provide the result within 4-5 s.
Page size is set to 25, still no luck.


Please share your ideas on why it might slow on the first instance, and only when navigating for the first time to lines tab.

This was resolved by changing the app parameter ENABLE_UI_DRIP_FEED from Y to N.
Issue will be permanently resolved via UPD13

I had recently investigated a performance issue in the contract window of FSM 6 UPD11.
This occurs when there are more than 1000 records in the lines tab.

When we navigate to the contract window and select the lines tab it took more than 1 minute to load the relevant data. If we navigate to another tab and comes back again to the lines tab it will load within 4-5 seconds.
I had executed the relevant hierarchy SQL in XML poster and it provide the result within 4-5 s.
Page size is set to 25, still no luck.


Please share your ideas on why it might slow on the first instance, and only when navigating for the first time to lines tab.


Hi @Avindu Hendawitharana ,

Came across kind of a similar incident . But I’m not sure whether this information helps on why this happens. But thought of sharing as this can be relevant to what you have talked. 

The issue was related to the indexes and there was no indexes created for the particular table.
So , Initially we had to check whether there had been any index already created for the relevant table. If not had to try creating a new index.
Again, If this is a Azure customer you can check whether automatically indexing has been enabled or not from the cloud side. If this enables , it monitor the database and create indexes for the tables for which has highest usages. And removes non used indexes accordingly. So when there is such slowness observed due to high number of records this worked for that particular scenario .

Thanks,
Tharindu 

Reply


Terms & ConditionsCookie settings