• Replies 2 replies
  • Subscribers 337 subscribers
  • Views 82 views
  • Users 0 members are here
Related

Payment Gateway Service location

Gretchen Shantz
$organization

Hi,  

We upgraded to v12.5.1 and have since experienced slowness in our credit card processing in the evening.  

Our servers are located on a SAN that is managed by the University IT group.  They perform a backup of the SAN starting at 6 pm.  That is when we see our cc processing times jump from 1-2 seconds to 5-20 seconds.   

Last season (year), before the v12.5.1 upgrade, I can see in the PGS logs that there was a slowdown that started at 6 pm but it added only a few second, meaning it wasn't noticeable.  This season it adds enough seconds that can make a transaction take a minute or longer & when there is a line at the Box Office it gets uncomfortable for the patrons and sellers.   

I want to jump right to a solution and wonder if moving the PGS (payment gateway service) to the Database server will fix the slow response times and speed up the cc processing.  

But...I don't know exactly why it is slowing down.  I did some netsh traces on both servers and see a sql read/write that happens btwn the cc and db servers using the SMB2 protocol that significantly slows down starting at 6 pm (when the backup starts).  

Has anyone moved the PGS to the DB server and found an improvement or deterioration of Tessitura?    I have read 2 posts that talk about where to put the PGS when you move to vantiv or elements and I understand that there is a PCI benefit to putting it not on a public ip address.  but putting the PGS on the webapi server would lighten the load for sql server.   sounds like it is a toss up.  

Any feedback is appreciated.  Especially if you can tell me what is happening with sql query using smb2 protocol - logging?

Thanks, Gretchen 

  • $organization

    Gretchen,

     

    You should keep your DB & PGS on different servers as your DB should be in a secure isolated network per PCI Compliance. Your PGS should reside in the DMZ with ACL rules allowing it to communicate with the DB. Has the IT group changed their backup solution? You might be noticing lags on your network due to high I/O on your SAN. Maybe scheduled reports?  

  • $organization

    Thanks Mike. 

    This gives me some good information.  I imagine what you are saying  is  like an onion. 

    With the DB nearer to the center and then the PGS and seat server/report server in one layer and then the web gateway on the border.   

    Yes, it is high I/O on the san that is slowing us down.  One dept has already moved off of the SAN because it was so slow during this time frame.   Finally got to the bottom of the mystery. 

    Now to figure out what we are going to do to remedy the situation.   

    Thanks again. 

    Gretchen

     

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Mike Tiernan
    Sent: Monday, March 13, 2017 9:54 PM
    To: Gretchen Shantz <gshantz@uw.edu>
    Subject: Re: [Tessitura Technical Forum] Payment Gateway Service location

     

    Gretchen,

     

    You should keep your DB & PGS on different servers as your DB should be in a secure isolated network per PCI Compliance. Your PGS should reside in the DMZ with ACL rules allowing it to communicate with the DB. Has the IT group changed their backup solution? You might be noticing lags on your network due to high I/O on your SAN. Maybe scheduled reports?  

    From: Gretchen Shantz <bounce-gretchenshantz5061@tessituranetwork.com>
    Sent: 3/10/2017 3:07:03 PM

    Hi,  

    We upgraded to v12.5.1 and have since experienced slowness in our credit card processing in the evening.  

    Our servers are located on a SAN that is managed by the University IT group.  They perform a backup of the SAN starting at 6 pm.  That is when we see our cc processing times jump from 1-2 seconds to 5-20 seconds.   

    Last season (year), before the v12.5.1 upgrade, I can see in the PGS logs that there was a slowdown that started at 6 pm but it added only a few second, meaning it wasn't noticeable.  This season it adds enough seconds that can make a transaction take a minute or longer & when there is a line at the Box Office it gets uncomfortable for the patrons and sellers.   

    I want to jump right to a solution and wonder if moving the PGS (payment gateway service) to the Database server will fix the slow response times and speed up the cc processing.  

    But...I don't know exactly why it is slowing down.  I did some netsh traces on both servers and see a sql read/write that happens btwn the cc and db servers using the SMB2 protocol that significantly slows down starting at 6 pm (when the backup starts).  

    Has anyone moved the PGS to the DB server and found an improvement or deterioration of Tessitura?    I have read 2 posts that talk about where to put the PGS when you move to vantiv or elements and I understand that there is a PCI benefit to putting it not on a public ip address.  but putting the PGS on the webapi server would lighten the load for sql server.   sounds like it is a toss up.  

    Any feedback is appreciated.  Especially if you can tell me what is happening with sql query using smb2 protocol - logging?

    Thanks, Gretchen 




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!