Today I wanted to talk about some ways that we’re improving the performance of transactional data found in places like the transaction search page, custom report generator, transaction details page, etc. Prior to this update we were taking the entire payment record even if we didn’t need it. So, a business that does 1,000 bookings a month we’re pulling all the data for 1,000 bookings for that month even if your custom report only uses three fields from that record.

person on blocks getting ready to race

To demonstrate why this can be a significant cost for performance assume that each transaction record has 100 fields of data. Let’s also assume (for round numbers) that each of these fields is 10 bytes of data. That would make each booking record 1,000 bytes (or close to 1Kb of data which is what we will round this example to for round numbers.)  Given our example of 1,000 bookings per month that would be 1,000 Kb of data per month (or, round numbers, 1Mb of data) per month. 

Given our example we’re only generating a report for three fields so really we’re overfetching our data by 97 fields (or 970 bytes of data). Put another way, to get a report that uses these three fields we are pulling an extra 97% of data! For businesses that are high volume this causes a problem because as a business scales larger more and more data is being fetched that isn’t used. The additional data takes longer to retrieve, longer to process, and longer to render.

Dynamic Queries to the Rescue

Enter dynamic queries. With dynamic queries we are able to request which fields are returned to us from a request and only those fields. So in our above example if we’re generating a report of three transaction fields, instead of bringing back 100 fields per booking we’re bringing back three fields per booking. Substantial savings in both size of payload as well as processing time. 

We ran tests on some of our highest-volume businesses before and after this change. We pulled a month of data before this dynamic queries change was released and got a baseline of 5,678 milliseconds or 5,678  seconds to process. After this was released we ran the same report and it returned in 341 milliseconds. That’s a reduction of 94% in processing time. After the release we also used the same business and report but pulled a year of data which was returned in 3,045 milliseconds or 3.045 seconds. Pulling an additional 11 months of data took 46% less time than pulling a month of data the previous way!

Performance is one of our primary focuses because we know tour and activity operators consider time to be money. If you’re sitting around waiting for reports to generate that’s time you could be spending another way. Stay tuned for additional performance improvements as we release them.

Transaction Search Performance Gains