Whats your avg data transfer usage?

Hello folks!

We are in the midst of finalizing some plans for our implementation for Tessitura and our new website.  One of the many questions thats popped up for us now is making sure that we have a large enough pipe for data to travel between our website (hosted) and our Tess db (local).

Our current website is setup such that about 85% of the data resides at the hosting site with only 15% of the data at our location which means we have small amounts of data infrequently flowing back and forth.  Our avg data transfer for a total transaction currently is ~10kb, we do not incur ANY browsing related data traffic.

With the move to Tessitura, we are looking at the reverse situation (80% local and 20% onsite).

I was hoping to get some of your metrics for data usage on a hourly or daily kb rate.  Also, what kind of numbers are you seeing solely for transaction communications vs. browsing?

Any help would be appreciated, thank you!!

  • When setting up our site, I also tried to find some info about bandwidth requirements, but it's all very circumstantial. It depends greatly on how/where you cache data (you should diffidently cache everything you can for as long as you can) and which API calls you use. There are multiple ways to get some pieces of info, and some API calls return a ton of stuff you don't need along with what you do.

    I'd just suggest running some load tests on your current setup. Look for ways to cache as much data on the web server as you can. And in the end, if you need more bandwidth, you need more bandwidth. Also, if you're using print at home ticketing, don't forget the bandwidth you'll need for sending e-mails. All those PDF tickets can really add up.

  • What Morgan said is right, cache where you can.  Also make sure you are using HTTP compression on the API server.

    I started my position here just as a big performance was selling, and the site was mostly unusable.  I was able to grab the "low-hanging fruit", and add some caching for the show information.  Turning on HTTP compression helped also, and the site went from unusable, to almost snappy.

    We have a single T1 line between the API server and the web server, and it has worked just fine.

  • Thanks for the suggestions!  I'll be sure to keep these in mind as we go through our implementation process.