Weeknotes: WYSKADRF and why is my API slow today?

Client Work

Why is this endpoint so slow?

At the end of the last sprint, my client shipped a new feature that had the side effect of slowing down one of the endpoints significantly (think 25-30 seconds). This endpoint was returning a list of something — let’s say it was Games — and prior to this release we’d only had 3 Games in the system. The endpoint had never been “snappy,” but once we added 7 more Games (for a total of 10 Games), depending on how many games you had played, the endpoint was taking forever.

As I have mentioned before, this client uses a microservice architecture. This means that, for many endpoints, we need to make at least one call to another microservice to get some data. I realized that we were calling the microservice that held the info we needed once per game. 3 calls to that microservice was one thing, but 10 calls was quite another and resulted in significant slowdown.

The calls being made to the other service were also inefficient. What we needed was some summary data: your total score for all the games you’ve played in the last 3 months, plus the average number of games you play per week. What we were doing was requesting the record of every single game you played for that time period, then doing the math ourselves to add up the score and the number of games played. Yikes!

I spent about a week on a pretty significant refactor of this endpoint. Since this Games endpoint initially shipped — well over a year ago — we’d added some features to the other microservice that enabled us to get this summary data without returning all the objects.

I’ve simplified this explanation a lot — we actually need make 3 separate API calls to other services, and we were doing 2 of those calls inefficiently, resulting in at least 1 API call per Game object. Basically, I replaced 10 calls (1 call per type of Game to get all instances of the user playing that game) with a single call that returns the list of Game types with the summary data needed.

How can this pie chart add up to more than 100%?

I wrote a feature that looks at all your spending for a period of time, divides it up into categories, and tells you how much you spent weekly on average in each category. Theoretically, the percentages should add up to 100% (or close to it — some rounding means it might be off a bit).

But in dev, a tester was getting some very strange results, like 414% for one category. WTF?

I am still working on this one, but I actually don’t think it’s a bug (although it did result in some clarification discussions with the product team). First, I wasn’t filtering the transactions the way Product was expecting, so some transactions (like your monthly paycheck) were getting included in “spending.” This can significantly throw off the numbers. If you spent $400 last month on ice cream (represented with a negative number -400) but you also made $2,000 via a paycheck and that $2,000 is counted with your “spending,” that’s going to throw your numbers off.

But you can’t just look at transactions that have a negative amount. People return things, and the refund they get shouldn’t be treated as income in this case. It should be treated as spending. And returning very expensive items (like cancelling an order for a fridge) or returning things well after the initial purchase date (like you can with REI) can throw off your numbers as well. 
 So I changed the queryset for the Transactions to filter the way that product was expecting, and we also talked about some edge cases where the percent you spent in a specific category might be negative (like if you returned something that got you a refund larger than everything else you spent) or even over 100% (if the total amount you spent was technically $100 because of a large return, but you spent $200 dining out, it looks like the Dining Out category represented 200% of your spending).

I am reasonably sure that there is not actually a bug in my math, but if it turns out there is, I will update next week.

PyCascades

I presented “What You Should Know About Django REST Framework” last Saturday at PyCascades Remote (link to video)! PyCascades was an awesome conference and I’m so glad they allowed me to present. You can access all the videos from the conference on their YouTube channel.

This website

I added a Colophon to my site. I also changed some of the fonts I was using.

Writing

I wrote a 3-part series, “What You Should Know About DRF,” based on the talk I gave at PyCascades.

I didn’t write any new TILs this week.