Anyone have any suggestions on how to perf tweak

SST.ApolloApi

. How to investigate where the bottle neck could be.

I’d start by implementing Xray to see where the issue is. Also what’s the axis you’re trying to optimise? Cold start time, warm request time, throughput?

@Omi Chowdhury to be honest, the focus is really on… “our GQL endpoint is VERY (

avg 1500ms

) slow, how can I speed it up” So we’re not even at the point of targeting a specific cause/axis… it more about where to even start here.

Yeah I think the first step is to diagnose the problem - which means adding some visibility into the what’s happening during a request. Xray is probably the easiest to get implemented in most serverless stacks and will give you some ideas of where to start

With Apollo (or any API related framework inside a lambda), you have essentially 4 components to “time”): • Cold Start: This is mostly dependent on package size, and Apollo aint small, but not gigantic. • Apollo initialization: This is pretty quick, but slows down with schema size. • Apollo Routing: typically very quick. • Business logic: Wildcard. Additionally, with GraphQL, you have the possibility of chained resolvers, where you must get one before the other. Even more additionally, if any data sources are other lambdas, you may repeat 1 and 2. 1 and 2 should only happen on a cold start, but a cold start at 1.5s is actually pretty decent for a “fat” lambda.

Thanks @Derek Kershner let me try and tell you what ours is doing… We are essentially just wrapping the native Contentful GraphQL API with 1-2 transforms that act on a single fiend of a single schema type. Aside from minor deriving of urls for fields… its using an HTTPAPI Authorizor (Auth0) caching on

Authorization

header, to either include all private content or not.

We are using the standard JWT Authorizer, and hitting (mostly) dynamo. That could account for nearly all of the gap, but not sure on contentful API speed.

contentful api directly is VERY fast

whats your lambda package size?

trying to check that now

that looks like a get route

should be … but I think this is it? don’t see any other function

apollo-server-lambda

is about 10x that on its own: apollo-server-lambda v3.6.3 ❘ Bundlephobia, you got a hell of a treeshake.

looks like both post and Get use that same “Get” named function

are those maybe the ones that connect to your local SST? (start)

lol

tiny for apollo, that aint it

🤷‍♂️ no idea

just to confirm, you arent doing performance testing locally…right?

ah…. you are right again… I mean.. the most notable time was when it was local yes…. FORGOT that can F things alot

lol, all good, happens to everyone sometimes.

let me try again as full deploy