#Travis-rate

1 messages ยท Page 1 of 1 (latest)

gritty pivot
#

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.

pseudo fulcrum
#

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)

iron prairie
#

HI ๐Ÿ‘‹ I"m stepping in for @gritty pivot

pseudo fulcrum
#

Hi @iron prairie

iron prairie
#

I think you would likely hit our API rate limit with this approach

#

100 POST requests per second.

pseudo fulcrum
#

We are aware of the 100 post rate limit and we are intentionally throttling the threads to prevent that

iron prairie
#

One question, are any of these payments associated with records that might be shared across multiple payments (e.g. same Customer record)?

pseudo fulcrum
#

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?

iron prairie
#

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.

pseudo fulcrum
#

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. ๐Ÿ‘