A few weeks ago I was tasked with trying to mitigate some timeout issues in a client’s Rails app making BrainTree calls. This was becoming more of a problem as the client’s users built up more & more history in BrainTree. Apparently you can’t paginate the results or ask BrainTree to exclude certain parts of the response via the API. So you can end up getting two years worth of transaction history that you don’t even care about attached to the piece of data that you do care about. As you’ll see, parsing that potentially big ball of XML can become a problem.
I started by outputting timestamps of the interactions with BrainTree to see if the slowness was on our side or theirs. For many calls it was slow on both ends. As an example, it might take 20 seconds for BrainTree to respond with the XML for the request and then another 28 seconds(!) for the BrainTree gem to parse that response. My client’s server was set to issue a timeout after 45 seconds, so you can see how this was a problem (besides the fact that we wouldn’t want the users to have to wait so long for a response).
As I dug a little deeper I discovered that the gem *should* use the speedy LibXML gem instead of the default REXML to do XML parsing. Unfortunately, we hadn’t installed LibXML. So I installed and configured LibXML but I still got the same results. So then I dug into the BrainTree gem’s code and discovered that there was a bug which was preventing it from finding LibXML.
The problem was a simple typo — the gem was looking for “::LibXml::XML” but it should have been checking for “::LibXML::XML”. See the difference? The ‘M’ and the ‘L’ need to be capitalized.
So I changed the gem’s code and ran my test again. This time it still took the same amount of time for BrainTree to send us the XML response but the parsing only took 2 seconds instead of 28 seconds.
I’ve submitted a pull request to BrainTree for this fix. You can see my commit here.