we have a database for each tenant, in my test database we only have 4* entries in the table of conc
we have a database for each tenant, in my test database we only have 4* entries in the table of concern. id is: 7b0f67f7-6768-44a8-a855-08e758a65989
Mwhen you say it takes almost 300, do you mean as measured from the Worker? I don't see evidence of that kind of performance regression in that DB
Malso, how much traffic is this DB doing? smart placement relies on steady traffic to place your Worker optimally
Syep, i measuered the time within the worker. it always was around 20ms before.
should i disable smart placement? database is in WEUR anyway and all our traffic (should) come from germany
should i disable smart placement? database is in WEUR anyway and all our traffic (should) come from germany
Sdashboard doesnt show any smart placement traffic, only default placement, so maybe not enough traffic
Msmart placement uses 1% of your traffic to compare timings (so 99 get smart placed, 1 is left default placement as a baseline), it sounds like it needs a bit more traffic yeah
Sim just wondering because even our tenant has this problem where traffic should exist, more than our dev deployment ever had even while testing
Sfunny thing to say: "yeah you just need to use the app more so it becomes faster" lol
LCan you check your placement status for your worker? https://developers.cloudflare.com/workers/configuration/smart-placement/#placement-status
I think you also need to do multiple roundtrips from your worker to the database, otherwise it cannot get much faster anyway if it's a single request.
I think you also need to do multiple roundtrips from your worker to the database, otherwise it cannot get much faster anyway if it's a single request.
N@Max (@rozenmd) will smart placement slow down (as it's doing more requests) workers that don't have a lot of traffic?
Myou may have misunderstood what I wrote, smart placement doesn't do more requests, it requires more requests for better data
LIt's not doing more requests. It just uses 1 out of a 100 of your requests with smart placement disabled, so that it can compare that with your other 99 requests that are smart placed to figure out if it's worth it doing the smart placement or if it should "smart place your worker" elsewhere.
But always check the placement status to see if you are actually smart placed.
But always check the placement status to see if you are actually smart placed.
Swill do, wait a moment
SINSUFFICIENT_INVOCATIONS - so yeah... how many are needed? :D
N@Max (@rozenmd) @lambrospetrou got it. Thank you
JI personally wouldn't use D1 as a primary due to the nature of D1 being so far from potential workers depending on your user base, the latency isn't good. During my own testing the extra 100-500ms latency per worker request due to multiple round trips to D1 wasn't worth it.
It forced me to use the DO SQL engine instead and refactor my app to per-user DBs which I feel is a more scalable design.
It forced me to use the DO SQL engine instead and refactor my app to per-user DBs which I feel is a more scalable design.
Ehow/why are you doing multiple round trips to D1?
DWe use workers paid account, we have about 15 D1 databases and each one is less than 5 gb, so I doubt it crossed the 250 gb account wide threshold. The "Exceeded maximum DB size" errors show up for some time and then resolve on it's own, which is what it makes harder to understand if the db size actually breached 10gb or not, the UI's d1 db size is what we are use to decide to change the db, but these errors show up even when the db size is less than 2gb in the UI. Any tips would be gratly appreciated.
Jweb app makes all kinds of D1 requests on a worker request, get session, get user, update user etc. Each SQL stmt is a round trip.
E100 ms seams reasonable. but 500 doesnt. You should consider not splitting up your statements and write real SQL language. I'm not making fun of you FYI a lot of people including me have a issue of splitting up queries when realistically it can be one query.
JAlready use straight SQL, there's no getting around some big requests with lots of disparate SQL for different purposes on a modern app. The downfall of D1 is that it's not colocated with the web server like many other services. Whats close for one user is far for another. Personally a db request should have sub 10ms latency from the web worker for simple queries. Closer to 1-5ms even or less.
Ecompletely agree. The latency is a network latency tho thats the issue
EI had the same argument last time about it in this chat
I
wonder if you could run a SQLite DB in WASM and then stream the client the WAL somehow: https://sqlite.org/wasm/doc/trunk/npm.mdEthere is a sqlite client in WASM
Esql.js i believe
IThe link I sent above is one yeah
INot really a client it's actual full SQLite
IOh yeah sql.js is also one
EEam i missing something about wasm?
Ewhy wasm in the backend?
Esame with the one i sent i believe
IIf you are building a native application in JavaScript (using Electron for instance), or are working in node.js, you will likely prefer to use a native binding of SQLite to JavaScript.They recommend against that actually
ETalking about cloudflare in general :NotLikeThis:
IMainly because WASM is portable and secure. If you allowed anyone to upload binaries (as does AWS Lambda/GCP Cloud Run) then to get enough security you basically need to run them in a full, dedicated VM or at least gVisor (GCP). With WASM even though it's untrusted code, running inside the V8 WASM sandbox is secure enough.
IAnd because it's running in V8 it's far lighter-weight than a VM/gVisor and they can afford to run thousands/tens of thousands of WASM sandboxes.
IMD1s alpha was SQLite in WASM on DOs, it was uh "fun" to operate
E:kekw:
Ei will have to test this
Eim working o nsomething similar to AWS lambda and CF workers using NixOS microvm.nix and firecracker
BWorker smart placement should help with this though, as it should put your worker closer to D1 rather than closer to user if it sees that you are making multiple round trips to D1. Read replica is also on the roadmap, although there doesn't seem to be any ETA for that.
BI'm also considering if I should build on D1 or DO + SQLite storage, but the latter having to pay extra for DO requests, as well as losing out on D1 features, are putting me off.
JHad the same concern, what clinched it for me is the 10gb limit on d1. Audit trails, request logging etc eats that up quick. Only d1 feature I miss is dumping the SQLite file. Going custom on the rest isn’t hard.
B10 GB limit? Ah, maximum database size.
Emake new dbs i guess
Ebut i swear cloudflare already does those for you
BDO SQLite currently only has 1 GB limit though, and doc seems to indicate that it will be raised to 10 GB when GA, which matches what D1 offers.
J1gb per user is reasonable for a multi tenant app. Can scale that to terabytes if needed. Much harder to scale d1 to 1tb.
SWell i truly think my worker smart placement is bugged, it wont analyze anything anymore, not even stating something in the dashboard. has the minimum traffic for smart placement increased in someway?
