Openbravo Issue Tracking System - Retail Modules
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0044316Retail ModulesWeb POSpublic2020-06-09 11:432020-06-09 16:33
Reporterinaki_garcia 
Assigned ToRetail 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusnewResolutionopen 
PlatformOS5OS Version
Product VersionRR20Q2 
Target VersionFixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customer
Support ticket
Regression levelPackaging and release
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0044316: [20Q2] Performance degradation in inventory update during ticket processing
DescriptionWe have observed a performance degradation from 20Q1 into 20Q2 in the ticket processing times when executing the ticket creation JMeter test on top of the MultiOrg Sampledata.

The tests simulates the creation of 100 tickets, per each of the 100 threads or terminals working concurrently. Each of the threads do as follows:

    - A ticket in the POS is created, with one line, and it is completed
    - Then, it is synchronized with the BackEnd and the test waits for 14 seconds before creating another ticket
    - Each thread uses a different terminal, user, organization and warehouse
    - Each thread updates a different stock


By analyzing the pg statistics, we can have observed that the query with the biggest performance hit is the m_update_inventory pl:
20Q1:
funcname calls total_time self_time
m_update_inventory 9999 60597,629 59776,81
uuid_generate_v4 877743 8715 8715
m_get_stock_param 1300 7876,088 7717,419

20Q2:
funcname calls total_time self_time
m_update_inventory 9996 3428939,577 3428035,721
m_get_stock_param 9996 38791,438 37794,888
uuid_generate_v4 749340 6477,539 6477,539


With more research, we have found that this pl is explicitly called in the OrderLoader when creating a shipment (ShipmentUtils.createNewShipment())
Also, the warehouse actions like create transactions are executed with the triggers disabled in the orderLoader, so this function is not being called by the triggers
We have measured the processing times by reading the Import Order entries, both by leaving and removing the call to this trigger to confirm the scope of the performance regression:
20Q1: 136ms
20Q1 (without calling m_update_inventory): 135ms
20Q2: 440ms
20Q2 (without calling m_update_inventory): 146ms

However, we are still to find the cause behind this, since:

    - There are no extra triggers against the storage detail table in that environment
    - Each thread acts against different stock records, there should be no concurrency problems
    - We have used the same exact data (sampledata of 20Q1) in both tests, so the problem is not related to the data either
Steps To ReproduceN/A
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2020-06-09 11:43inaki_garciaNew Issue
2020-06-09 11:43inaki_garciaAssigned To => Retail
2020-06-09 11:43inaki_garciaRegression level => Packaging and release
2020-06-09 11:43inaki_garciaTriggers an Emergency Pack => No
2020-06-09 16:32inaki_garciaDescription Updatedbug_revision_view_page.php?rev_id=21163#r21163
2020-06-09 16:32inaki_garciaSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=21165#r21165
2020-06-09 16:33inaki_garciaDescription Updatedbug_revision_view_page.php?rev_id=21166#r21166

There are no notes attached to this issue.