What latency should i expect from my server (deplo...
# ory-network
r
What latency should i expect from my server (deployed on azure's east us) to the ory servers? Because i'm getting higher latency than i expected so i'm thinking about deploying to europe (roughly in which region is ory deployed to?)
This is the latency for a keto check call
This is the latency for kratos /session/whoami
I enabled "edge session" in the project settings.
s
Hi Francesco, currently Ory Network uses
europe-west1
and will add 2 additional datacenter locations in Europe soon. Once this is done we will add data center regions in the US. The latencies should be way lower for
sessions/whoami
when edge caching is enabled.
There was a discussion here to check if edge caching is actually used. Can you check?
r
Adding the cache control header. Let's see how it goes
How about keto? does it have edge caching too? I'm using the grpc api.
I tried a few times but always get these headers. I'm fetching the session from an edge function
Copy code
HeadersList {  [Symbol(headers map)]: Map(15) {    'date' => 'Fri, 24 Feb 2023 10:18:25 GMT',    'content-type' => 'application/json; charset=utf-8',    'transfer-encoding' => 'chunked',    'connection' => 'keep-alive',    'cf-ray' => '79e77504abdf9c79-IAD',    'cache-control' => 'no-cache, no-store, must-revalidate',    'last-modified' => 'Fri, 24 Feb 2023 10:18:25 GMT',    'set-cookie' => '__cflb=04dTofjtHwhfCny3TibZzRnKNQfNMfGC6CRPkfQmt7; SameSite=Lax; path=/; expires=Fri, 24-Feb-23 11:18:25 GMT; HttpOnly',    'vary' => 'Origin,Origin,Cookie, Accept-Encoding',    'cf-cache-status' => 'MISS',    'ory-session-cache-for' => '186478',    'x-kratos-authenticated-identity-id' => 'f49065b4-357f-4a87-beb9-47783a4ce1f6',    'server' => 'cloudflare',    'content-encoding' => 'gzip',    'alt-svc' => 'h3=":443"; ma=86400, h3-29=":443"; ma=86400'  },  [Symbol(headers map sorted)]: null}
h
The cache key is currently unstable (by design) and uses several signals. That’s why in some cases the cache key is recomputed with a new hash and you end up without hitting the cache. We’re decreasing this unstability over time as we observe how the system behaves. iirc we use several signals: 1. origin IP 2. user agent 3. domain 4. ory related-cookies 5. ory-related authorization headers
If one of these changes per request, you end up with a new cache key every time, not hitting the cache at all
Oh and then it also relies on the
__cflb
if I am not mistaken
Ory Permissions and Ory OAuth2 do not yet have edge cache capabilities. We first will roll out the session whoami completely. The latencies you observe are of course not OK and also not where we want them to be. We’re working this year primarily on this multi-region topic to bring down latencies globally. It’s a hard problem and needs time, but we’ve made significant progress this year already
Yeah, if the cflb cookie is missing, then the worker doesn’t hit the cache 🤔
r
ohhh yeah that could be it! Let me quickly hack around that
h
I think this is because cloudflare routes you to any nearby datacenter if the cookie is missing, and there the cache is not available because it’s a different data center. I’ll talk to SRE to figure out if we can fix this in cloudflare or what we can do here
r
Yep, I changed my nextjs function to forward/set the __cflb cookie and now latency is much much better
I think mentioning this in the docs would be super helpful for the next person 🙂
Latency for kratos is now ~20/30ms which is perfectly good!
h
Ok epic, I will start an investigation into how we could serve cache even without the __cflb cookie
r
yep that's great!
h
I think we identified the root cause of the problem, and you probably won’t need to include the
cflb
cookie in the future. For now it’s required though
🔥 1