Simple sql query returning 1 row from 10 rows is taking 748.00 ms, the worker's placement is changed to smart and spamming get request every 5s for more than 24 hours. the latency is still crazy high
The Cloudflare Radar Data Explorer provides a simple Web-based interface to build more complex API queries, including comparisons and filters, and visualize the results. The accompanying AI Assistant translates a user’s natural language statements or questions into the appropriate Radar API calls.
Describe the solution Currently, we cannot use D1 since we need the usage of editdist3 (levenshtein distance) which is included in the spellfix1 extension. However, when trying to run SELECT load_e...
I am not sure if this has been answered before. Given the per-DB size limit and recommendation to shard your data into separate databases, how would one go about it in practice. Let’s say I wanted to have a separate DB per customer, how would I create one on the fly and bind it to a worker? Or am I misreading something?
Have you explored using Cloudflare Durable Objects (DOs) with the SQLite API? They provide a workaround for the current lack of dynamic binding for D1. One DO per customer is a common pattern.
I also want to know ETA for D1 dynamic binding, we've been asking for more than a year now and we get the same answer every time (soon without any timeframe approximation).
There are two pricing models for DO, there's the KV storage backend and the SQLite storage backend. For the SQLite storage backend, pricing model is the same as D1.
Even for a very simple query like “SELECT 1”, the database latency takes around 500ms. This number is confirmed using serverTiming, so I’m certain it’s not caused by other factors outside D1.
Additionally, I have confirmed that several people in the X community are experiencing the same issue. I tested this by sending requests to Workers with D1 binding from the Tokyo area.
If anyone else can reproduce this, or if you know the cause or any solutions, I would greatly appreciate your input.
Where is your database located? Usually network is what takes up the whole time when querying D1. The
meta.duration
meta.duration
field should tell you how much the actual SQL query takes when running inside your database. Everything else is networking to get from your Worker location to your D1 database location.
This is not to say there aren't things to improve internally (there are!!), but if worker and database are far away, then hundreds of ms latency is to be expected.
Hi, @lambrospetrou Indeed, when fetching the meta, it appears to be the case. This suggests that D1 itself is not hopelessly slow. Does this mean that D1’s location selection strategy is the issue? As a user, is there any way to intentionally select the location other? Smart placement didn't work.
Unfortunately, region-wise location hints are the only way to influence its location at the moment. In certain regions this is still a very wide area though, indeed. For example, APAC can be anywhere between Singapore and Osaka (https://where.durableobjects.live/region/apac). I can't promise anything on this yet, but it's something we are thinking on how to improve. Read replication will definitely help with reads on this depending on where your queries originate, but writes are going to still be impacted.
For now, if your servers/workers are in a single location (e.g. Tokyo), try creating one a few times and see if you get one close to you.
After creation the database doesn't move no. The first query is always going to be slow since you are cold starting your database, its location being cached in Cloudflare's CDN etc.
Thank you, I understand now. I apologize if my understanding is incorrect, but I had heard that D1 delivers “read replicas to the edge,” so I assumed that READ operations would be reasonably fast regardless of the location.