fix: orders performance

[mikemurray]

Resolves #5094
Impact: major
Type: performance

Issue

The orders admin panel is performing very poorly.

Solution

• Remove aggregations in an attempt to improve performance
• Rebuild the Orders table to be more performant

Breaking changes

Multi-shop orders will no longer work

Testing

1. Make orders, many orders, or use a data-set that provides many orders
2. Paginate through the pages and ensure they still paginate
3. Fulfill an order to completion
4. Cancel an order
5. View PDF preview, and ensure it has all the correct data
6. (basically make sure all parts of order fulfillment still works for an order with a single shop

[mikemurray]

Removing the aggregation form the PaginatedOrders publication didn't seem to help the UI perform any better. I doubt it has helped much with the performance of the system.

As per @aldeed's #5094 (comment) on the linked ticket, it may be necessary to make this a GraphQL query instead and completly remove the publication altogether.

It may also in part be to an inneficently designed UI relying on many Meteor trackers.

[manueldelreal]

@mikemurray I know that this is still WIP but pagination seems a bit slow for me when I'm displaying more than 20 rows of orders. My system struggles to paginate when there are 25 and 50 orders on each page and 100 just seems to kill it.

My specs are:

Dual core i7 4510U
16GB of RAM
I dont know if write speed matters but I have a 512gb SATA SSD

[mikemurray]

@manueldelreal Yea, that's what I'm seeing. The publication seems to be as simple as it gets, even simpler than the Products publication. I wonder if it's a UI problem, or if the publication itself is just bad all around.

If it's either of those two problems, this would require a refactor of the Orders UI at the least, and at the worst, a full refactor of data and UI to use GQL.

[mikemurray]

cc @spencern @zenweasel

[aldeed]

@mikemurray @manueldelreal Maybe try adding a { createdAt: 1 } index on Orders collection in your Mongo and see if that helps. The reverse sorting by createdAt may be the culprit.

[mikemurray]

@aldeed Tried that, didn't seem to help. I removed the sort by createdAt altogether and it's still pretty slow.

It seems like the further you paginate through orders, the slower it gets.

[mikemurray]

As a super quick test, I created a new table component and just used the same type of table layout I used for the product admin. The result is a madness fast table with pagination... So something in that old UI super render intensive.

[aldeed]

@mikemurray Not surprising. Seems like that's what we have to do then.

[spencern]

I'm not really surprised that the UI rendering is part of the issue.
If we're able to keep the filters working, I'd be in favor of biasing toward performance here.

@rymorgan this probably gets us further from the design aesthetic that you're really looking for here. Curious if you're okay with this move "temporarily" in order to drastically improve the performance.

[rymorgan]

@spencern yes, but this design needs upgrades anyway. So yes i'm ok with some version of this to improve performance. Especially since performance seems to be a blocker for using the UI at all. Can we provide at least sorts for order and shipping status? and even better a table search? (aka a similar table component to tags).

[spencern]

[mikemurray]

@manueldelreal @spencern @rymorgan So here we are. A more performant orders table. It's definitely faster, but like 99% of the time. That 1% may just be a system hiccup as I can usually click as fast as possible through all 700 orders. This is an improvement no doubt, but probably not the last we'll see of the orders performance issues.

This is ready for review now @manueldelreal

[manueldelreal]

this actually is much faster now, I can increase/decrease number of displayed orders and paginate without any visible hiccups