Long running WebCrypto API?

When doing load testing on generating a Cryptographically unique string, It always stalls eventually with Exceeded CPU (~800 req here), even on small-ish length like 50 characters.

Is this expected or is it a bug?

bild

Free or paid plan?

Paid, but does it really matter?

I presume a Pro plan, right?

In this case a worker execution must not exceed 10 milliseconds. On Business it is 50 and Enterprise is a custom number depending on what was negotiated.

Wasn’t this changed to 20ms for all paid plans?

Not that I am aware of, also that would be quite a downgrade for Business plans.

I don’t see how it matters though, we’ve been told CPU time is per request - that doesn’t seem to be the case if eventually, after a lot of requests, we always hit the limit.

Well, you do seem to hit the CPU limit. A support ticket would be probably the best choice at this point.

Yeah, but the limit is reached for 22 out of 906, I’m doing the same crypto on every request. Also, it’s only the last requests that starts to fail - If i continue running it, newer requests will continue to fail more often. It is like the CPU-time accumulates, which shouldn’t be the case.

I understand, I am afraid I dont really have an answer either, hence my suggestion to open a support ticket. They should be able to give a definitive answer.

I was hoping they are in the forum :slight_smile:

Usually get an answer before they read the ticket anyway.

Maybe, but I wouldnt be that sure in this case. This question is quite specific. That does not mean nobody here might have an answer, but opening a ticket in parallel certainly would be a good idea.

2 Likes

If you have a ticket number post it here, so @cloonan can track it.

1 Like

I don’t think they actually differentiate CPU from RAM, could it be RAM exhaustion? Just a guess, not sure if it’s based in facts.

Hm, that does sound plausible. I’ll test it, thanks for the hint!

You where probably right, I isolated the crypt code and ran load tests on that alone.

It’s no problem for workers to generate random strings as large as 5000 characters.

I’ll refactor the whole thing and try to clear all variables to make it eligible for garbage collection.

1 Like

In that case, please do so :sunglasses:

@KentonVarda @harris

It’s tricky because when the isolate comes close to running out of memory, the garbage collector tends to work much harder, and as a result you tend to hit the CPU limit before the memory limit even though your problem is actually memory.

With that said, in practice, if you see error 1102, it is almost certainly from the CPU limit. These days when an isolate goes over its memory limit, we let it finish up in-flight requests before evicting it – unless it goes way over. So it’s actually hard to observe errors from hitting the memory limit.

Note that it’s common to see requests working correctly for a while, and then start throwing 1102. This is because we allow a worker to exceed its limit from time to time as long as it is not consistently over the limit. The enforced limit is 50ms (regardless of plan), so if you have a worker that runs for 60ms every time, it will succeed a few times and then start failing after awhile. TBH we should probably improve this so that the first few requests have strong enforcement and then let up a bit later on, so that errors are easier to see early…

4 Likes

FWIW generating a 50-character string should be very cheap, assuming you are using crypto.getRandomValues(). I’d guess there’s something else going on in your code that’s making it expensive…

1 Like

@KentonVarda It was actually an earlier hash comparison function that caused it, It’s doing PBKDF2 in SHA512 with 30K iterations of salt. Lowering it to 25K solves the issue.