Hi, I was playing with AppSignal today and this is example output of measuring a post request into one of my api endpoints, which I generally expect to be the slowest one – exclusive table lock to perform a count operation and then conditional insert, with potentially tons of parallel requests coming in.
^ from this chart, I don’t really understand what is really happening between 0-200ms. Also the very first query.ecto there is actually CREATE TABLE IF NOT EXISTS "schema_migrations"... – I don’t know what that really is and why is it happening on api post request? So I understand what’s going on from call.phoenix_endpoint onwards, but before that?
Can you please advise? Thank you
1 Like
Any performance questions need to start with some basic info: How are you running the app? Releases or mix.exs? Is this locally or in production? What else was going on with these requests?
I see. At his point it’s a dev app running on localhost. I was just trying to peek into what I’m doing to see if I don’t do some very obvious mistakes, see if I have some serious bottlenecks and give me an idea which parts of my app need to be rethought or restructured.
I am basically looking at livedashboard and now tried to plug in appsignal, but still learning what are the right ways to do this. I am running some load tests using https://k6.io/ which is very cool - sending as many requests as possible and see what happens. And try to understand whether the request should take 100ms or 1000ms and why.
A big thing with localhost is the code reloader. Any request is gonna hit the phoenix code reloader which is gonna check to see if any code needs to be recompiled. Also keep in mind that mix lazy loads code so the first request or two will have extra latency from needing to load code.
At a minimum turn off code reloading.
4 Likes
thanks a lot! I dug deeper into this topic and basically deployed a production app on localhost. the numbers are significantly different now 
1 Like
