Two aspects of resolvers have an outsized influence on their performance: the size of the execution context, and the way we compute their value. In the Node.js implementation of graphql, promises wrapping primitive values are especially disruptive, since they add a large computing overhead. The context size creates a memory usage baseline that can rise very quickly with even small additions to the context, when there are many concurrent contexts. The execution can create temporary objects, increasing memory usage. Often-run resolvers, such as those responsible for filling out large arrays of objects, can become performance bottlenecks.
At Auction.com, our search results page (SRP) requests up to 500 items of roughly 80 fields each. The query resolving these fields was suffering a high latency. We shall examine the tools to instrument our code and identify memory usage and CPU utilization bottlenecks.
Our realtime elements (e.g. realtime updates to the status of currently viewed properties) are implemented using a translation of kafka messages to graphql updates. We shall present the tools and procedures to reduce memory usage and CPU usage when fanning out such messages.
