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