I’m thinking about making a change that could increase the number of materials on a single job. There would likely be 1000 materials on average, but could be up to 15000.
Does anyone have experience with a large number of materials on jobs? Have you noticed any performance or usability issues in the newer versions of Kinetic?
Ours can go up to 10000, I see no performance issues in the cloud
I just tested adding 3000 materials to a job. If I try to update the quantity of 1 random material, it takes like 10-15s to save
Do you not run into this? Maybe you don’t update quantities on jobs that often
Wow, I thought we had a lot at 1,900.
This is… not normal?
So, in the UI, you may be hosed. In a Function, it can be fast:
Familiar face in that post @jgehling
It looks like the save times continue to get worse the more materials you add.
It was this reason we stopped creating 400 line blanket POs. It was so painful to make any changes.
Maybe @jgehling is on a version where this is all fixed
Oof that is strange. An update to a material on a job with 6000 materials for us only takes 2 seconds. We are on 2024.1.13. We are on Epicor’s public cloud so maybe they have some beefed up db servers?
It looks like you are on-prem. Maybe some SQL maintenance is needed? Faster disk, check for missing indexes etc
hmmm. I will check it out! Thanks for confirming it’s likely a me issue.
Maybe you have BPM’s that are firing and taking a long time with that many lines?
We here make everything from tiny pins for avionics connectors all the way to major structural components. So we’ve got jobs for 100,000 tiny parts (that you basically have to manage stochastically) that cost a fraction of a penny per and have a qty tolerance of +/- 5% and no one cares. One the other side, there’s 1 piece jobs for a piece of titanium that requires weeks of machining and cost more than a luxury car and if you crash it, a whole jet is getting pushed to next year and there’s all-hands meetings with the customer over it.
Had to run to a meeting, so I didn’t get to reply to this part, but there is definitely a performance impact to large objects. The more order lines, ops, mtls, or whatever, the worse UI performance gets. GetById methods can also kill performance since (as mentioned above) they grab every child record. Pretty sure JobEntry.GetById hits like 30 tables. Never loop those. Use a LINQ query where possible.
Fortunately, it’s rare for us to have more than 2 dozen ops and materials on one job. SO/PO’s top out at 100 lines. Performance is manageable.