medusa
medusa copied to clipboard
[Perf] Performance issues around line items and draft orders
@dwene show me some performance issues around the line items (remove, create) and the draft order interaction

I will have a look but I wanted to know @olivermrbl if this is something you already encounter.
I am sure that in the code base, there is some operations that can be handled out of the request lifecycle if that does not impact directly the client. Finding which part must be processed during the request lifecycle and which part does not required to be processed during the request lifecycle could already improve the response time globally.
Also, as we discussed, we have to look into the queries and run an EXPLAIN ANALYSE in order to start finding bottleneck and improve queries performances. Some process could also be made directly into the database which as we discussed, help maintaining consistency as well as improve performance since it is done on a low level.
I am waiting your feedback before digging deeper into that as if thats already known and that you have some input I might end up working twice on that 😂
@dwene could you give some indication of the size of the draft order cart so we can try to play around with this?
At max we have 25 unique product variants in the cart at a time. The typical user probably has around 7 items in the cart though.
And what is the update that is being performed?
I have also suggested to look into the indices usage after analysing the queries since depending on the query an index can end up not being used and therefore slow down the query.
But before that let's look the easy parts 😃
@srindom it seams from my understanding that it is happening when they are swapping lines items, they remove and add lines.
@srindom I think you've worked on bulk update no?
@dwene also, depending on your tests it might be worth looking on the database capabilities, memory, cpu etc to see if there is a sizing problem as well and remove or not one problem
Yea it's particularly slow when creating or removing line items.
I think some of it could be fixed by removing unnecessary save loops like this: https://github.com/medusajs/medusa/pull/1219
@dwene also, depending on your tests it might be worth looking on the database capabilities, memory, cpu etc to see if there is a sizing problem as well and remove or not one problem
Yea I will look into that, but I'm running our Nest API against another schema the same database and it's running quick.
Can you give us the diff between the schemas
They are extremely different schemas haha. Our Nest schema contains additional tables specifically needed for our clients food subscription product.

Database looks pretty bored. It's all running in Kubernetes
@dwene when you say that you run the query against both schemes and that the results are different what is your process to test that at the moment
@dwene when you say that you run the query against both schemes and that the results are different what is your process to test that at the moment
Sorry I think there's a misunderstanding here. I'm running the Medusa database in the same docker container as our Nest Database, and the database seems to be performing well for our Nest database (nibll-home-dev)
Ahah alright, not what I though my bad 😂 yeah so we can't compare them
We will wait @srindom feedback since he has been working around the lines items and see if he got some insight that can help. Then depending on the nature of the issue if it is needed I'll jump into the digging 👍 is that alright for you @dwene ?
Yep! Thanks y'all!