#Travis-rate
1 messages ยท Page 1 of 1 (latest)
Hi there! When you say speed this up, what do you mean exactly? I think you are referring to something like a batch API, which we unfortunately don't support.
Hi Bismarck. We are using multithreading with semaphore slim to send over payments using the create method in the PaymentIntentService object. The response time we get back from the create method wildly varies on Test Mode (see screenshot for console logs.) Usually the first couple of threads have a decent response time but then it falls flat after that. We are planning on using this application to process 4000+ payments which, at this rate, would take 3+ hours to run.
We're sending over the payments one at a time concurrently (not trying to batch since thats not supported)
HI ๐ I"m stepping in for @gritty pivot
Hi @iron prairie
I think you would likely hit our API rate limit with this approach
100 POST requests per second.
We are aware of the 100 post rate limit and we are intentionally throttling the threads to prevent that
One question, are any of these payments associated with records that might be shared across multiple payments (e.g. same Customer record)?
yes, of these in our test environment there are many with are the same customer. Could that be what's slowing it down? That unique customers process faster?
Yes, because there is a brief lock on the Customer record as the payments process. Then the subsequent request has to wait until the lock is released.
Ah ok - then that's perfect then, I did not realize that. We will create a bunch of unique test customers and give it another try soon. I really appreciate the insight @iron prairie. We will be back later if there are any issues. ๐