Skip to content

[BUG] High CPU usage on releases after 0.5.12 #600

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
ankagar opened this issue Apr 23, 2025 · 6 comments
Open

[BUG] High CPU usage on releases after 0.5.12 #600

ankagar opened this issue Apr 23, 2025 · 6 comments
Labels
bug Something isn't working triage waiting for feedback

Comments

@ankagar
Copy link

ankagar commented Apr 23, 2025 •
edited
Loading

Describe the bug

After migrating from 0.5.12 to 1.0.0.beta3, I noticed very high cpu usage in my app requests.
It went down when I rolled back to 0.5.12

Metrics view from dashboard
Image

Steps to reproduce

App is very simple, completely SSG with around 20 pages

open-next.config.ts (version 0.5.12) - NEXT_INC_CACHE_KV is not defined (does this disable caching?)

import { defineCloudflareConfig } from '@opennextjs/cloudflare'
import kvIncrementalCache from '@opennextjs/cloudflare/kv-cache'

export default defineCloudflareConfig({
  incrementalCache: kvIncrementalCache,
})

open-next.config.ts (version 1.0.0-beta.3) - no cache binding defined

import { defineCloudflareConfig } from '@opennextjs/cloudflare'
import staticAssetsIncrementalCache from '@opennextjs/cloudflare/overrides/incremental-cache/static-assets-incremental-cache'

export default defineCloudflareConfig({
  incrementalCache: staticAssetsIncrementalCache,
})

PS: I am new to Next.js/Cloudflare but even after reading the docs multiple times, I have not really understood how this cache is really working and what purpose is serving - if anyone can point me to a more verbose write up or video. Thanks!

Expected behavior

CPU is not 20x

@opennextjs/cloudflare version

1.0.0-beta.3

Wrangler version

4.12.0

next info output

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.3.0: Thu Jan  2 20:24:06 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T8103
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 22.14.0
  npm: 11.3.0
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 15.3.1 // Latest available version is detected (15.3.1).
  eslint-config-next: 15.3.1
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.8.3
Next.js Config:
  output: N/A

Additional context

No response
@ankagar ankagar added bug Something isn't working triage labels Apr 23, 2025
@conico974
Copy link
Collaborator

Could you provide a reproduction ?
You said that downgrading to 0.5.12 decrease cpu time, have you tested any of the 0.6 ?

@vicb
Copy link
Contributor

vicb commented Apr 29, 2025

See https://nextjs.org/docs/app/deep-dive/caching for some explanation on caching.

Basically caching allow to generate the page once and serve it for a period of time. It should offload your server.

There is nothing we can do without seeing your app code. Please create a minimal repro and add a link to the repository here. Thanks.

@elliotodyl
Copy link

I also encountered this problem when upgrading from "0.5.10" to "0.6.6," and I don't know what went wrong.

Image

@vicb
Copy link
Contributor

vicb commented Apr 30, 2025

Again, to make progress on this issue, we need:

  • a minimal repro (code in a GH repository + clear instructions)
  • know what version caused the perf regression

Without that there is nothing we can do and will close the issue.

Thanks!

@ankagar
Copy link
Author

ankagar commented Apr 30, 2025 •
edited
Loading

Hi @vicb , I will try to create a minimal repo with issue and get back (will update this post)

Update:

I am able to 'sort of' reproduce it with

npm create cloudflare@latest -- my-next-app --framework=next --platform=workers

Image

Under the red line is with version 1.0.0-beta (actually 0.6.0 shows the same) and above with 0.5.12. The high number is browser making first request, which seems to be very slow (why?) and the subsequent requests are faster. So with 0.6.0 first slow request is 2-3x compared to 0.5.12, subsequent requests are fast with both - which also corresponds to the graphs above P50 being fast but P90+ being slow.

@vicb
Copy link
Contributor

vicb commented May 2, 2025

This must be because we dynamically import the server handler in the worker vs a static import before (as suggested by @conico974).

So the time was actually spent before but in the init (i.e. you should see wall time > cpu time in that case).

A few notes:

  • we might be able to switch back to top level import now that we do import the routes lazily - but I think it would work only with the most recent versions of next
  • there are some limitations on what you can do outside the context of a request in cloudfare (i.e. no IO, timeout, ...)
  • process.env needs to reflect the values set in cloudflare and .env files (process.env is populated by workerd after 20250401)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working triage waiting for feedback
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@vicb @conico974 @elliotodyl @ankagar