David, Adrian, Thanks for the feedback -- we have considered multi-threaded order processing, async calls etc but my thought was that we should really investigate the 2-3 delay before moving to the next level of tuning.
Sounds like 2-3 seconds is not totally unreasonable so we'll start looking at the alternates. I know that our customer is considering alternate providers who can guarantee 0.5 - 1 second processing time so that's an option as well. Nick -----Original Message----- From: Adrian Crum [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2008 5:50 PM To: user@ofbiz.apache.org Subject: Re: Credit Card Transactions -- Payflow/Verisign Performance Woes From the PayFlowPro Developer's Guide: "The entire process is a real-time synchronous transaction. Once connected, the transaction is immediately processed and the answer returned in about three seconds." An alternative to David's suggestion might be to modify the services in PayflowPro.java so they will accept a list of orders to process. That might trim some time from each transaction - because the PFProAPI instance can be re-used, instead of being created and torn down on each order. -Adrian David E Jones wrote: > > 2-3 seconds does sound pretty normal. Because there is communication > over the internet involved, I'd be surprised no matter how good the code > is to see it under 1 second. > > I'm going out on a limb here... but it sounds like you're processing the > orders 1 at a time. Chances are all of the time is spent waiting for > network communication as there is natural latency there. Still, you > network probably has very good throughput, so this opens an opportunity > to run orders in parallel. > > I'd change your processing service to do more than one order at a time. > > The pattern is simple, just have 1 "loop" service, and one service that > processes one order at a time. In the loop service have it use the > dispatcher method that returns a result waiter, and call the single > order service 10 times (or 100 times, or some configurable amount so you > can tune it) and then wait for the results of each call. Once they are > all done, move on to the next set. This is really easy to do with the > service engine since it handled the async stuff. BTW, if you're going to > do a lot make sure the service engine thread pool size is large enough > so they all really do run at once. > > -David > > > On Dec 3, 2008, at 10:19 AM, Nick Rosser wrote: > >> We're using payflow / verisign for cc processing. >> >> >> >> We have 2 batch processes that run each evening. One creates ~5000 >> orders; >> and issues a credit card "authorize" transaction. The other completes >> ~5000 >> orders; and issues a credit card "capture" transaction. >> >> >> >> We've found that for both runs the credit card transaction takes 2-3 >> seconds >> for each transaction. Not enough hours in the day to get these batch jobs >> completed before the day starts up again. >> >> >> >> It seems to me that this is simply unacceptable and I wondered if anyone >> else is experiencing this problem? >> >> >> >> Is anyone else out there processing 1000's of batch (offline) cc >> transactions and getting better response times? Which providers are you >> using? >> >> >> >> The response from Verisign was that this is normal . they advised that we >> upgrade to version 4 of the SDK. >> >> >> >> >> >> Nick >> > >
