We have encountered an issue that is happening intermittently.
The issue is that when an order is finalising, it's taking a very long time, in excess of 4-5 minutes sometimes. This results in timeout error from azure (as that's baked at 4 minutes) and is affecting customers.
In the code, there is a Handler that is run after the order has been finalised, using the following code.
This 'OrderFinalizedHandler' does not get hit for, sometimes minutes and sometimes not at all.
As the application is quite large in terms of dependencies we have been exploring multiple possible causes. Our recent profiling of the application has shown a lot of hot methods related to the Vendr GiftCardRepository. (see screen grab below)
Could this be because of the volume of data and Gift Cards stored for the application?
Would you be able to assist us in further investigating this issue?
I suspect it might be an issue with the fact we use Guids and when we fetch Gift Cards we then have to fetch all of their properties (which is what DoProcessDtos does) but it does this by loading all Gift Card properties with a SQL where clause of
WHERE giftCardId IN (@ids)
Which it then processes all of the properties, assigning them to the relevant order models.
Because the ID's are Guids though, they aren't going to be in an optimised order for lookup here so my guess is SQL is just taking an age.
We do try to combat this in Vendr v2 where all entities still have Guids but we use COMBS (similar to what nHibernate does) which is essentially still a Guid but they are sequential and thus the DB table can have an Index put on them to sort them effectively without a ton of fragmentation.
I guess the best thing to do currently is to see if you can identify this to be the exact issue.
I'm not entirely sure what we can do to rectify this though if it is, as even if I create a support build of Vendr with COMBs added for you, this only works if ALL ID's are COMBS and anything that has already been created won't be. It might be that the only option is to add an index on the GiftCardId column of the vendrGiftCardProperty table and know that it will become fragmented and might need rebuilding regularly. (I suspect you may end up needing some other similar indexes elsewhere too)
It might also be worth checking the azure portal to see if it has any suggestions for you. I know when I had a poorly performing project a while ago it made suggestions to optimize your DB for better performance.
Suspected Vendr Performance Issue
Hi Matt, me again.
We have encountered an issue that is happening intermittently. The issue is that when an order is finalising, it's taking a very long time, in excess of 4-5 minutes sometimes. This results in timeout error from azure (as that's baked at 4 minutes) and is affecting customers.
In the code, there is a Handler that is run after the order has been finalised, using the following code.
This 'OrderFinalizedHandler' does not get hit for, sometimes minutes and sometimes not at all.
As the application is quite large in terms of dependencies we have been exploring multiple possible causes. Our recent profiling of the application has shown a lot of hot methods related to the Vendr GiftCardRepository. (see screen grab below)
Could this be because of the volume of data and Gift Cards stored for the application? Would you be able to assist us in further investigating this issue?
Thanks, Rob
Hi Rob,
Kinda hard to say without a bit more info. How many gift cards do you have? What Umbraco version are you on? What Vendr version?
Umbraco Version - 8.16.0
Vendr Version - 1.8.6-beta0007
The amount of giftcards are around 100,000
OK yea, then that is a lot.
I suspect it might be an issue with the fact we use Guids and when we fetch Gift Cards we then have to fetch all of their properties (which is what
DoProcessDtosdoes) but it does this by loading all Gift Card properties with a SQL where clause ofWhich it then processes all of the properties, assigning them to the relevant order models.
Because the ID's are Guids though, they aren't going to be in an optimised order for lookup here so my guess is SQL is just taking an age.
We do try to combat this in Vendr v2 where all entities still have Guids but we use COMBS (similar to what nHibernate does) which is essentially still a Guid but they are sequential and thus the DB table can have an Index put on them to sort them effectively without a ton of fragmentation.
I guess the best thing to do currently is to see if you can identify this to be the exact issue.
I'm not entirely sure what we can do to rectify this though if it is, as even if I create a support build of Vendr with COMBs added for you, this only works if ALL ID's are COMBS and anything that has already been created won't be. It might be that the only option is to add an index on the
GiftCardIdcolumn of thevendrGiftCardPropertytable and know that it will become fragmented and might need rebuilding regularly. (I suspect you may end up needing some other similar indexes elsewhere too)It might also be worth checking the azure portal to see if it has any suggestions for you. I know when I had a poorly performing project a while ago it made suggestions to optimize your DB for better performance.
Matt
How many gift cards do you have?
njmcdirect
He's already said, >100,000
is working on a reply...