So both of them are on US West 2 if I’m understanding then?
So from Tylers question “Lastly, I am a touch confused still because it sounds like when you removed the match expression from the trigger, it worked. Is that correct?”
And are both of them the same cluster tier? Is one by chance an M10 and the other an M5 etc? Or are both free tier M0s?
Because if they are both single digits following the M they are on shared tier clusters meaning their resources are shared between neighbors. And each one can be found on different server racks with differing number of neighbor clusters, which all are sharing the same resources.
So one may be experiencing what we used to call “Noisy Neighbor” causing delays, while the other doesn’t go through this.
In which case if that is the case, this can literally just be an issue of shared tier performance vs non-shared tier.
This is just a copy and paste of what I used to share with customers who used shared tier environments:
These behaviors are common for Realm clients as a lot of Realm customers go with shared tiers or M10s often.
Something worth sharing with the customer:
Information about shared tier clusters
- Shared tier clusters share resources between all tenants on the same tier.
- Resources provided to each tenant of course increase for each tier level.
- M0 has the smallest amount of resources in the shared tiers, as M5 has the most.
- The shared tier instances theoretically do gain better throughput via networking and the writing service as you go higher in tier. - Due to less tenant density.
- All tenants on the same shared tier cluster share the same networking, writing, and other resources.
Cluster Recommendations
MongoDB does not recommend shared tier clusters for full production environments, and we encourage at the least an M10 as a dedicated cluster for a production environment with extreme lows in traffic, but an M20 would be the better starting point. Our official recommendation overall is an M30 cluster for production environments.
Notice
We cannot guarantee stability on a live production environment on a shared tier cluster for the reasons mentioned above, as these clusters are intended for educational and development environments. As the shared cluster gains tenant density the available resources outside of the dedicated RAM, and CPU allotted to the specific tenant on creation will be spread more thin.