-
Notifications
You must be signed in to change notification settings - Fork 27.2k
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.
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
extremely slow builds / vercel crashes and fails to build our app #26588
Comments
Would you mind turning off as many extensions as you can that don't involve breaking your app or having to modify it in a meaningful way, and reporting build times? I'd suggest starting with source maps, which we have known to be problematic. |
Can you try disabling |
If this is related to the webpack build (not the static generation or typechecking) there is now a env variable you can set to get more insight into the build:
Note: just seeing you are still on webpack 4, where this isn't available... |
Did the profiling and the verbose logging ( I did this on my extremely fast desktop (32gb ram, ryzen 5950x). Doing it on my laptop is substantially slower. Profiles and logs:
Some naive thoughts:
|
I have just cloned a project, done yarn install, and the first build takes more than 5 seconds, the next builds take 2-3 seconds. |
Hi, all. Sentry JS SDK maintainer here. I checked out the logs (thanks, @zallarak!) and TL;DR, sourcemap upload is taking forever because more stuff is getting uploaded than necessary. Because this is really an issue with our SDK, I've filed an issue in our repo with lots more detail (linked above). @sokra, @timneutkens, there are some questions there having to do with webpack and/or nextjs which might benefit from your expertise, if you wouldn't mind taking a look. P.S. @zallarak - I notice in the logs that you're still using the |
Thanks @lobsterkatie , we switched to |
Just for reference, please follow this issue (getsentry/sentry-javascript#3769) we are going to improve this. |
@zallarak can you please update our webpack plugin to |
…les (#3845) Though sourcemap uploading using `SentryWebpackPlugin` is generally quite fast, even when there are a lot of files[1], there are situations in which it can slow things down a lot[2]. [1] #3769 (comment) [2] vercel/next.js#26588 (comment) There are a number of reasons for that, but one of them is that, in the current state, `@sentry/nextjs`'s use of the plugin is pretty indiscriminate - it just uploads anything and everything in the `.next` folder (which is where nextjs puts all of its built files), during both client and server builds. The lack of specificity leads us to upload files we don't need, and the fact that we don't distinguish between client and server builds means that whichever one happens second not only uploads its own unnecessary files, it also uploads all of the files from the other build (which have already been uploaded), both necessary and unnecessary. More details in #3769. This change makes it so that we're much more specific in terms of what we upload, in order to fix both the specificity and the duplication problems. Notes: - There's discussion in the linked issue about which non-user sources/maps to upload (things like code from webpack, nextjs itself, etc). In the end, I chose to restrict it to user code (almost - see below), for two reasons. First, non-user code is unlikely to change much (or often) between releases, so if third-party code were included, we'd be uploading lots and lots of copies of the same files. Second, though it's occasionally helpful to be able to see such code in the stacktrace, the vast majority of the time the problem lies in user code. For both reasons, then, including third-party files didn't feel worth it , either in terms of time spent uploading them or space spent storing them. (I say it's "almost" restricted to user code because, among other files, the server build generates bundles which are labeled only by numbers (`1226.js` and such), some of which are user code and some of which are third-party code, and - in this PR at least - I didn't include a way to filter out the latter while making sure to still include the former. This is potentially still a worthwhile thing to do, but the fact that it would mean actually examining the contents of files (rather than just their paths) makes it a more complicated change, which will have to wait for a future PR.) - In that issue, the topic of HMR (hot module reloading) files also came up. For the moment I also chose to skip those (even though they contain user code), as a) the plugin isn't meant for use in a dev environment, where every change triggers a new build, potentially leading to hundreds of sets of release files being uploaded, and b) we'd face a similar issue of needing to examine more than just the path in order to know what to upload (to avoid uploading all previous iterations of the code at each rebuild). - Another small issue I fixed, while I was in the relevant code, was to prevent the webpack plugin from injecting the release into bundles which don't need it (like third-party code, or any bundle with no `Sentry.init()` call). Since this lines up exactly with the files into which we need to inject `sentry.server.config.js` or `sentry.client.config.js`, I pulled it out into a function, `shouldAddSentryToEntryPoint()`. Fixes #3769 Fixes vercel/next.js#26588
FYI, all - 6.11.0 is out with this fix. I did some testing in my small example app, to see how many files would be uploaded under different scenarios, both under 6.10.0 and 6.11.0 (
(In the above tests, I started with a clean slate each time. The change will be more dramatic for folks using next 10 and either running Please give it a try and let me know how you do! [UPDATE: If you've changed the default and don't suppress the |
We're on webpack 5 and that builds are going well. we upgraded to next 11 and webpack 5 at the same time, and in doing so changed the way we did sourcemap generation, so it's hard to say exactly which thing was slowing us down before. right now we're pretty sure our build time bottlenecks are due to some specific node_modules dependencies and not due to vercel. |
Awesome @zallarak! Really glad updating to latest Next.js and webpack has improved things 😄 If you have further questions, please let us know! |
This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Describe the feature you'd like to request
next.js version: 10.2.0
here is our next.js config
Describe the solution you'd like
help debugging or resolution - right now vercel is not usable and we must use google cloud
Describe alternatives you've considered
moving to react or using higher performance machines
The text was updated successfully, but these errors were encountered: