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

  1. 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/trace on your worker's hostname, look for colo=<airportCode>. If you have Smart Placement enabled, then check the cf-placement response header, end of that is airport code.
  2. 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.
If the query is simple, run the same query via the D1 Console Tab, below your query, you'll see
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 it


Checking your database's graphs for query latency metrics and/or npx wrangler d1 insights <db> can be helpful for debugging slow queries as well
Was this page helpful?