0

Optimizing ticket_group listing

Brad Carson

March 05, 2012 22:13

None

Follow

I cache Events locally so the lookups are fast but not TicketGroups, because I don't know if this is possible or if it is, the API docs are unclear on how this process would work.  So currently, when a visitor lists tickets for an event all of the ticket data is pulled from TE and then sorted first by featured and then price before being displayed.  This can take waaaaay too long depending on the event.

How can this be optimized?  

I imagine it would be much faster if I could store TicketGroup data locally, poll TE for changed data at time of the request, parse these local changes (remove sold tickets, etc.) and then display back to user.

The EndPoint documentation http://developer.ticketevolution.com/endpoints/ticket-groups#list has attributes that hint this is possible but they are not documented.  For instance, if I pass in a datetime to updated_at _do I get records that have been updated since the specified time or updated exactly at that particular time?  And what are _ticket_states (and its nested available field)?   

Thanks!

• Facebook
• Twitter
• LinkedIn

8 comments

• 0
  
  Drew Gainor March 07, 2012 16:57

  Currently we return all ticket groups for an event by default.  We do pass back a flag with each ticket group where "featured = true/false" which is automatically set to true if they belong to your brokerage or if you built a rule to feature another brokers tickets in the Settings App.  Through the settings app you can also exclude brokerages, override markups, etc...  That being said the ticket groups should be returned very quickly right now (maybe 3-5 seconds for a very large event) and then you would need to handle any special sorting/filtering on your end.

  We are continuing to optimize the ticket_groups endpoint for V9 so it is hyper fast but it is much much faster than it previously was at the moment and should be just a few seconds on average.  Please feel free to compare with Goldentickets.com, eseats.com or any other live sites for comparison.

  We will also be adding paramaters to this endpoint so you can actually pass the filters and sort requests to the API in order to always receive the most accurate data.  This should be done over the next month or two.

  Updated_at is based on the time of that particular brokers last import since all files are not updated every import, only changes or added ticket groups.  You can pass "updated_at" if you only wanted to show tickets based on a certain freshness.  IE maybe down the road you only want to show real time inventory from users on our Point of Sale.

  The ticket states are not too relevant right this second for you but will be much more relevant when on our Point of Sale if you need to see how many tickets are available from a group, on hold, sold, etc...

  Please let me know if I did not properly answer your questions.
  
  Thanks 

• 0
  
  Brad Carson March 07, 2012 17:35

  Thanks for the feedback, Drew.

  Goldentickets.com and eseats.com return ticket data in the blink of an eye.  They must be storing TicketGroup data locally - there's no way they can hit the API, process, and return data that fast.  I refrained from storing TicketGroup data in our own databases because I assumed it changed unpredictably minute by minute (people buying tickets).  Maybe I'm wrong?   Also, it seems too large a dataset to be downloading and updating every hour or less!

  But, maybe I could store TicketGroup data locally and use updated_at to poll for changes.  So, if I pass a datetime into "updated_at" when requesting a ticket_groups listing, I will get all ticket_groups ON or AFTER that datetime?

• 0
  
  Drew Gainor March 07, 2012 17:51

  Actually they are no aching any ticket data, only events and catalog data like you.  Every time you load an event on their sites it is making a live call for all ticket groups and then processing them however they need (sort, feature, etc...  You may need to optimize how you are pulling them in because they are definitely being returned very fast from the API.'

  You definitely do not want to start storing ticket groups, that would be completely excessive.

• 0
  
  Brad Carson March 19, 2012 17:53

  Been looking further into performance testing and a benchmark production console call to list ticket groups with the ruby gem takes a few seconds, depending on the event - nevermind any custom sorting or rendering of the view.  I was thinking that perhaps each ticket group (i.e. each row in the ticket results table) could be fragment cached and only changed ticket_groups could be polled for using a  "updated_at.gte" query.  That way, the amount JSON data returned by the API is greatly reduced, making it faster for Rails to chew through.  Data could be sorted through Jquery on html data attributes instead of in the controller, further cutting down on time required to return the page to the visitor.

  This would only work if a ticket_group is updated when part or all of it is sold.  To that end, I'm wondering how that process works - specifically, what changes in the ticket_group record when a visitor buys a split, and what changes in the ticket_group a visitor buys the last ticket in the group.  In other words, would these actions trigger an update to that ticket_group record (such as decreasing number of available tickets, etc.)?

• 0
  
  Drew Gainor March 21, 2012 15:43

  Hi Brad,

  I would highly recommend against caching tickets groups in any capacity as then can get very hairy and I dont think the effort and issues it can cause are worth the benefits.  We will run some testing this week against pulling ticket groups through the Ruby Gem to see if there is any bottleneck there and let you know.  The goal is simply to get it very fast through the gem so you can simply call the tickets as needed.

  Thank You

  Drew

• 0
  
  Drew Gainor March 23, 2012 22:47

  Hi Brad,

  It does appear there is a bottleneck in gem.  We should have this fixed early this week and you should be in great shape!

  I will let you know when complete.
  
  Thank you 

• 0
  
  Brad Carson March 24, 2012 15:59

  Super!  Thanks, Drew.  This is great news.

  I found a nice JQuery plugin to handle sorting client-side, so with the enhancements to the gem hopefully we'll be set!  Looking forward to seeing those commits!  :)

• 0
  
  Brad Carson April 02, 2012 22:14

  Performance issues resolved with release of 0.7.4 ruby gem. Thanks!