Performance Discrepancy Between Localhost and Railway Deployment using NodeJS

I am experiencing a significant performance discrepancy between running a Node.js script on my localhost and running the same script on Railway. The script involves heavy usage of API requests to Shopify and ERP. When I run this script on my localhost, it completes in approximately 45 minutes. However, when running the script on Railway, the process takes roughly 6 hours to complete. Given that the code is unchanged between the two environments, the performance difference is puzzling, and I am reaching out for input or suggestions on why this might be the case and how to possibly improve the performance on the Railway platform. Any guidelines or optimizations for running extensive API calls in a Railway app environment would be highly appreciated.
11 Replies
Percy
Percy8mo ago
Project ID: c295f9c1-64c9-4948-91d0-611c034d0a64
TheLittlePrince
TheLittlePrince8mo ago
c295f9c1-64c9-4948-91d0-611c034d0a64
Brody
Brody8mo ago
at this time I don't have an answer on this performance difference, but I felt the need to comment on the 45 minutes of api calls to Shopify / ERP, being honest that's raising a lot of red flags for me, so please tell me a bit more about whats happening for these 45 minutes
TheLittlePrince
TheLittlePrince8mo ago
During the 45-minute period: 1. The script is primarily performing a synchronization operation between Shopify and ERP via their respective APIs for all our product variants. (~40.000 variants) 2. For each product variant, we grab its barcode, inventory quantity, and price from Shopify. 3. Using the barcode as the identifier, we match the product variant with a product in ERP and retrieve its current price and inventory quantity. 4. If there are discrepancies in the price or inventory quantity between Shopify and Sedona for the same product variant, we use Shopify's API to update the product variant's details in Shopify to match ERP. 5. This procedure repeats for all product variants, thus the need for a large number of API calls. 6. We have incorporated delays of roughly 2 seconds between API calls to avoid being rate-limited.
Brody
Brody8mo ago
okay perfect write up, the flags are green now okay so you have a deadtime of 2 seconds, that means this increase in the time difference would be coming from the actual api request? from the sounds of it you aren't actually doing any heavy compute?
TheLittlePrince
TheLittlePrince8mo ago
Correct, the script itself is not very compute-intensive. It is mainly performing API requests, data comparison, and making updates if needed. The 2-second delay is strictly to ensure we don't exceed Shopify's or ERP rate limits
Brody
Brody8mo ago
love to hear you aren't hammering their APIs at full blast for 45 minutes straight, if that where the case it would be very bad for others using the Shopify / ERP at normal rates since ip's are shared but all that aside, does your app have any telemetry reporting? specifically time related telemetry for the various tasks your app performs? without that kind of telemetry it would be extremely hard to debug this slow down, and there's especially nothing we as a community can do without these kinds of things from you
TheLittlePrince
TheLittlePrince8mo ago
We currently don't have detailed telemetry or monitoring in place that shows a comprehensive breakdown of time spent on each task/operation
Brody
Brody8mo ago
then yeah my current recommendation would be to integrate such reporting, without that it would be extremely hard to debug as you've probably already seen going from 45 minutes to 6 hours is definitely concerning, but it's not information we can do much with on its own
TheLittlePrince
TheLittlePrince8mo ago
Absolutely, I understand Thank you for your recommendation and guidance on this issue. We appreciate your time and insights!
Brody
Brody8mo ago
of course! I look forward to hearing back from you with more information, definitely wanna help you get to the bottom of this