Issues with free tier cpu limits

Feedback
1

Hi,

I am a student attempting to create a free & open source app to assist students at my university during course selection.

Since the course selection site is pretty big I am having trouble staying within the 10ms runtime using HTMLRewriter and as a student I would not be able to upgrade my account.

I reached out to support about a potential student plan that could have a longer CPU runtime to work within the limits of other apps and they asked me to reach out to the community managers on this forum. I would love to share more details with anyone who could help raise the limit on my account or test out a student account if that is possible.

Thanks a lot & happy new year!

2

It sounds like youā€™re having some success with staying within that limit. There are some Workers gurus here, like @adaptive, @thomas4, and, of course @KentonVarda. And others, as well. Maybe if you posted the code somewhere (here or GitHub), there might be a way to optimize it to stay within the 10ms limit.

1 Like
3

Thanks for the reply!

With the code posted below I am getting ~1200 logs out of ~2000 items. Since my code is essentially the tutorial I am not sure how much room there is for optimization unless I should use a counter instead of console.log - even then, I assume logging would use less CPU time than converting each row in the table to JSON and writing it to a DB.

addEventListener(ā€˜fetchā€™, event => {
event.respondWith(handleRequest(event.request))
})

/**

  • Respond to the request

  • @param {Request} request
    */
    async function handleRequest(request) {
    let res = await fetch(ā€œURLā€)

    return new HTMLRewriter().on(ā€˜tdā€™, new ElementHandler()).transform(res)
    }

class ElementHandler {
element(element) {
// An incoming element, such as div
console.log(Incoming element: ${element.tagName})
}
}

4

Unfortunately, this might just be the way it is. 1200 items in 10ms is 8.3 microseconds per item. Each callback is a call from native code into JavaScript, which is not super-efficient. And when you run with console logging enabled, each console.log() does some non-trivial work as well. I could easily imagine that this all adds up to 8.3 microseconds per callback.

5 Likes
5

Yeah it makes sense to me as well, which is why I was wondering if there were any ways to increase the CPU limit as a student working with old & clunky university sites.

6

You can wait until Workers Unbound have been released, it doesnā€™t have CPU-limits.

1 Like
7

You donā€™t need to upgrade to a Business plan, the regular $5 plan will do and will fix your issue.

8

I was referring to an upgrade from free to bundled (the $5 plan)

9

All right, but thatā€™s just $5 and in that case certainly affordable.

10

In case anyone comes back to this issue ā€“ the problem was in console.log being very slow as @KentonVarda outlined above. By creating a var of ElementHandler and storing properties inside it, the HTMLRewriter code becomes much more performant. In my small set of testing it also appears that the workers preview runs slower than deployed workers.

Here is an example of how to store properties in the handler since I had trouble discovering how it works.

addEventListener(ā€˜fetchā€™, event => {
event.respondWith(handleRequest(event.request))
})

/**

Respond to the request

@param {Request} request
*/
async function handleRequest(request) {
let res = await fetch(ā€œURLā€)

const handler = new ElementHandler()
await new HTMLRewriter().on(ā€˜tdā€™, handler).transform(res)

console.log(`handler saw ${handler.count} elements`

return new Response('done', {status: 200})
}

class ElementHandler {
constructor() {
this.count = 0
}
element(element) {
this.count++
}
}
11

Watch outā€¦ thereā€™s a longstanding bug in which production workers are given some upfront grace time, and will only start failing if they consistently go over the limit over the course of many requests. So it could be that you are going over the 10ms limit, but not noticing it because the first few requests get extra grace time. We havenā€™t been able to fix this bug because doing so breaks a bunch of peopleā€™s workers that depend on the grace time. :frowning: But weā€™re hoping we can finally fix it when Workers Unbound is generally available, by moving those people over to Unboundā€¦

In any case, if your worker fails CPU time limits in preview but not production, be wary. It might start failing in production after a certain number of requests.

1 Like
12

Thanks for the heads up! Ill definitely keep that in mind!