NScan response times

Hi everyone,

I'm new to the forum, still pretty new to the role in fact, just 4 months now!

Since I started, NScan has been at the top of my to-fix list. We're using the Motorola MC65b for hardware with both Tessitura and print-at-home tickets. I've identified that we may have difficulties with our WiFi network and we're addressing that through capital investment but, even when the WiFi is up, the NScan system doesn't respond in a particularly timely manner when there are lots of tickets being scanned concurrently. Has anyone else found this? It can be fine with just one or two scanners but once we have 4 or 6 on the go it really slows down.

I've put a couple of suggestions in to the development team that we
a) separate the database 'write' elements of the code to some separate procedure and
b) ensure the stored procedure is able to be called by more than one process at a time as my diagnosis seems to suggest we're seeing queuing of requests which is leading to a considerable slowdown in processing.

So far they are still pondering these ideas so I wondered what the community's experience is please and if you have any suggestions for tweaks we could employ to speed things along?

Thanks everyone, look forward to hearing from you! 

Kind regards,

 

Paul Thompson

IT Manager

Mayflower Theatre

Paul.Thompson@Mayflower.org.uk

Parents
  • We regularly run just fine with up to 11 active scanners in 3 venues with no customization of Tessituras code.  I’m sure that there are other venues using more scanners than we.

     

    --Tom

     

    From: N-Scan [mailto:groups-n-scan@tessituranetwork.com] On Behalf Of Paul Thompson
    Sent: Tuesday, March 17, 2015 10:13 AM
    To: Thomas Brown
    Subject: [N-Scan] NScan response times

     

    Hi everyone,

    I'm new to the forum, still pretty new to the role in fact, just 4 months now!

    Since I started, NScan has been at the top of my to-fix list. We're using the Motorola MC65b for hardware with both Tessitura and print-at-home tickets. I've identified that we may have difficulties with our WiFi network and we're addressing that through capital investment but, even when the WiFi is up, the NScan system doesn't respond in a particularly timely manner when there are lots of tickets being scanned concurrently. Has anyone else found this? It can be fine with just one or two scanners but once we have 4 or 6 on the go it really slows down.

    I've put a couple of suggestions in to the development team that we
    a) separate the database 'write' elements of the code to some separate procedure and
    b) ensure the stored procedure is able to be called by more than one process at a time as my diagnosis seems to suggest we're seeing queuing of requests which is leading to a considerable slowdown in processing.

    So far they are still pondering these ideas so I wondered what the community's experience is please and if you have any suggestions for tweaks we could employ to speed things along?

    Thanks everyone, look forward to hearing from you! 

    Kind regards,

     

    Paul Thompson

    IT Manager

    Mayflower Theatre

    Paul.Thompson@Mayflower.org.uk



Reply
  • We regularly run just fine with up to 11 active scanners in 3 venues with no customization of Tessituras code.  I’m sure that there are other venues using more scanners than we.

     

    --Tom

     

    From: N-Scan [mailto:groups-n-scan@tessituranetwork.com] On Behalf Of Paul Thompson
    Sent: Tuesday, March 17, 2015 10:13 AM
    To: Thomas Brown
    Subject: [N-Scan] NScan response times

     

    Hi everyone,

    I'm new to the forum, still pretty new to the role in fact, just 4 months now!

    Since I started, NScan has been at the top of my to-fix list. We're using the Motorola MC65b for hardware with both Tessitura and print-at-home tickets. I've identified that we may have difficulties with our WiFi network and we're addressing that through capital investment but, even when the WiFi is up, the NScan system doesn't respond in a particularly timely manner when there are lots of tickets being scanned concurrently. Has anyone else found this? It can be fine with just one or two scanners but once we have 4 or 6 on the go it really slows down.

    I've put a couple of suggestions in to the development team that we
    a) separate the database 'write' elements of the code to some separate procedure and
    b) ensure the stored procedure is able to be called by more than one process at a time as my diagnosis seems to suggest we're seeing queuing of requests which is leading to a considerable slowdown in processing.

    So far they are still pondering these ideas so I wondered what the community's experience is please and if you have any suggestions for tweaks we could employ to speed things along?

    Thanks everyone, look forward to hearing from you! 

    Kind regards,

     

    Paul Thompson

    IT Manager

    Mayflower Theatre

    Paul.Thompson@Mayflower.org.uk



Children
No Data