You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Nick Rosser <nr...@salmonllc.com> on 2008/12/03 18:19:48 UTC
Credit Card Transactions -- Payflow/Verisign Performance Woes
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
Re: Credit Card Transactions -- Payflow/Verisign Performance Woes
Posted by Adrian Crum <ad...@hlmksw.com>.
I also noticed in the PayFlowPro Developer's Guide that the code
supports multi-threading. Probably the best solution is a combination of
both ideas - modify the services in PayflowPro.java so they will accept
a list of orders to process, and then have each order processed in its
own thread. That will allow simultaneous approvals and reduce the
overall time.
-Adrian
Nick Rosser wrote:
> 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:adrianc@hlmksw.com]
> 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
>>>
>>
>
>
>
>
RE: Credit Card Transactions -- Payflow/Verisign Performance Woes
Posted by Nick Rosser <nr...@salmonllc.com>.
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:adrianc@hlmksw.com]
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
>>
>
>
Re: Credit Card Transactions -- Payflow/Verisign Performance Woes
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>>
>
>
Re: Credit Card Transactions -- Payflow/Verisign Performance Woes
Posted by David E Jones <da...@hotwaxmedia.com>.
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
>