I would debug it using the following steps 1. Where is worker running (or rather, where are you con
I would debug it using the following steps
Response time 1354ms, query time 0.18ms
Query time is what you're interested in, it should be reasonable, like a few ms at max for simple queries.
Ignore Response Time via D1 Console or Wrangler, it's not representative of what you'd see in reality. It's going through API Layer -> Core (which only runs in a few locations), then to your D1 Instance. Worker/D1 Binding run at edge and connect directly to your database, not going through core/api layer/etc.
From the workers api, if using .run on a prepared statement check meta.duration for time in milliseconds spent executing. .exec has
Checking your database's graphs for query latency metrics and/or
- Where is worker running (or rather, where are you connecting to)? You can check the response headers: Cf-Ray Header, at the end is the Airport code. Or you can go to the virtual path
/cdn-cgi/traceon your worker's hostname, look forcolo=<airportCode>. If you have Smart Placement enabled, then check the cf-placement response header, end of that is airport code. - Where is the database running? You can use
npx wrangler d1 info <dbName>, If you're not sure. you'll get a region returned like ENAM (East North America), or APAC (Asia Pacific)
If you're making multiple queries for a single incoming request, Smart Placement can help, or just placing your DB closer to your users
If you're connecting to a location reasonably near and your DB is near/latency is way higher then it should be, then debug the query itself.
Response time 1354ms, query time 0.18ms
Query time is what you're interested in, it should be reasonable, like a few ms at max for simple queries.
Ignore Response Time via D1 Console or Wrangler, it's not representative of what you'd see in reality. It's going through API Layer -> Core (which only runs in a few locations), then to your D1 Instance. Worker/D1 Binding run at edge and connect directly to your database, not going through core/api layer/etc.
From the workers api, if using .run on a prepared statement check meta.duration for time in milliseconds spent executing. .exec has
duration You can also do performance.now before/after query to measure end to end latency of each query and shove it into a response header or console.log itChecking your database's graphs for query latency metrics and/or
npx wrangler d1 insights <db> can be helpful for debugging slow queries as well

