Measuring server performance

[lorensr]

At some point it will be nice to be able to recommend a way for devs to measure server-side performance, whether it's a guide to using a 3rd party package or tool, or something built into in apollo server.

Meteor example case

When I switched from DO to Galaxy, my pageload subscriptions ready time jumped due to the CPU maxing out. It was due to some combination of:

• number of subs
• amount of publish-with-relations use
• total amount of data

But I didn't have visibility into how much each was responsible. One thing I could have done was copied the database and run locally with the Kadira CPU profiler.

Apollo server

I guess the Apollo equivalent is queries and resolvers. Is there a way to instrument for CPU, or can you just start and stop the v8-profiler? Instrumenting latency is helpful for working on response time – eg this query took X ms, and it was due to these db queries that took however long, some of which were in series (perhaps @arunoda /Kadira will be doing this?). And then the other thing to measure is the memory and cpu usage of whatever does the reactive part, so people have the information needed to decide what data in their app is worth – from a server resources perspective – being instantly reactive vs polling vs non-updating. And ideally you'd be able to measure this in your production environment (unlike Kadira CPU server profiler).

Related: profiling issue in apollo-client

[helfer]

Yeah, that's a great idea, that's definitely something we want to build for Apollo.

[stubailo]

I think the start is having good loggers via the decorators you're working on, right? Then if the connectors integrate nicely with the logger you can get a lot of info about what backend calls are happening.

[helfer]

Yeah, that's the plan!

[helfer]

I think this will be well covered with Tracer, which will tell you how much time each resolve function took to run, in addition to logging how much time is spent parsing, validating and executing the request. I think monitoring server resources (CPU, memory) is a separate issue, but could also be added to tracer, if necessary.

[helfer]

I think the first thing someone should do before we look into the performance of the server itself, is to look into the performance of the execute function in graphql-js, because that's where most of the time is spent (apollo-server itself doesn't have that much code). Would be really cool if someone could pick that up and try to profile graphql-js.

[DxCx]

I'm already familiar with graphql-js execution code because of the Observables work i've done there.
i can take a look at that in the future, but i think that the ability to instrument and profile the server operation is needed and can be done regardless the graphql-js engine side..

[helfer]

Closing this since it's no longer on top of our list of priorities. Most performance issues with GraphQL servers can be solved with tools like Apollo Optics or other instrumentation in my experience.