How can I audit which part of my app is slow? - next.js

When I run my app locally, it's nice and fast, however, when I deploy to Vercel, things get very very slow. My app is a NextJS app, using Prisma as the db client. The database is an Amazon RDS Postgres instance. I'm pre-launch so there's no real traffic, so I don't think there are issues with connections or that I need a pgbouncer setup... though I don't really know how to audit that either.
Any tips I'd love to hear em!

Might be worthwhile to use the browser Dev Tools, specifically the Network and Performance tabs, to see if you can find what is slowing you down.
You could also check out using the React Dev Tools and look at the Profiler tool there, but that has to be run locally, which may not be as useful, since you say the app runs fast locally

Related

Wordpress on Lightsail working slow when uploading through FTP

I recently migrated my site to lightsail. My db has about 2mm records and slightly under 1Gb. I connected do the DB through an external client. While I was connected but not running any queries, site became slow.
Then I tried uploading some images through FTP, at that point, the site came to a halt again, would even open.
Upon looking at metrics, I got into burstable zone here and there, but its not sustained.
Any there tools I can use to diagnose what is the problem.
What size instance did you deploy? Also, is this Linux or Windows. It would be good to look at metrics from the lightsail dashboard but also be good to know what's running inside of your instance. I'd be curious to know if you are overburdening your instance (undersized) or not.
SFTP is generally slower than FTP due to the security built into the protocol. The data is encrypted, which takes time, but perhaps more importantly, the protocol itself functions differently; it's not "streamed" like FTP.

Next.js app takes 33 seconds to load. What could make it THAT slow?

I'm almost done with my first ever Next.js app.
Dev was always somewhat slow to load, but production is absolutely ridiculous.
On first load it takes 30+ seconds for the home page to render.
I've seen really slow sites take 5-10 seconds, but what could I possibly be doing wrong that would lead to 30 second load times?
Is prefetch a huge performance killer?
Finding the bottleneck:
First of all you need to find out what is making your site slow.
For that I recommend lighthouse or the network tab of your development tools.
Common developer mistakes:
A. Development instead production mode:
Next.js has two modes. The development mode (next dev) is pretty slow, since a lot of development tools are executed and shipped.
To run your app in production mode first build it with next build and then start it with next start.
B. Included too much code:
Sometimes developers include gigantic npm modules or even modules that only have been build for node.js into next.js.
Finding these modules is actually pretty easy thanks to these examples:
https://github.com/zeit/next.js/tree/canary/examples/with-webpack-bundle-analyzer
https://github.com/zeit/next.js/tree/canary/examples/with-webpack-bundle-size-analyzer
C. Cold Serverless instance:
If you are running your next.js instance on a serverless provider keep in mind that it may take some time to start the serverless instance. Especially if you have a free plan.
Try to exclude your development directory from Windows Defender

Deploying on Meteorjs cloud Vs personal Meteor server

I'm developing a meteorjs application and wondering what is better , actually deploying in meteor js cloud is elegant , free , and work perfectly, but is this will still free , is their any limit or compensation .
This question is very obscure by nature and will receive mostly opinionated answers. I have a feeling it will be closed before too long but for archival sake and to answer your question. Meteor's current free deployment has no guarantee of uptime and shuts down the app when not in use until another user attempts to access your app. For demo's and prototyping this should be fine.
However I would highly suggest that if you need something reliable and for use in a production environment stay far away from the current Meteor service for deployment. You are limited to a database size and how much access you have to things such as the file server. There are many great services out there that allow you to deploy just as easily.
Check out modulus.io for super simple deploys. If you are on more of a budget you can choose a service such as Digital Ocean or any other VPS service that allows you to install Ubuntu and use something such as MUP which is a great package made by Arunoda for deploying to Ubuntu based systems.

When will Meteor.com Meteor hosting be reliable enough for production use?

I've had very mixed experiences trying to host on Meteor.com.
I often get "This site is down. Try again later.". Initially I couldn't figure out why, but then I suspected that the problems were caused by me accidentally restoring the "system.users" collection. I tried restoring without that, but the site went down a few days later. Today, it's magically back up again without me doing anything.
"meteor logs" shows nothing. It's a complete black box.
I've investigated other options (Heroku, demeteorizer, meteor bundle, etc), but they are clunky and unreliable too (problems installing fibers, doesn't seem to handle Meteor.call() properly, etc).
I would really like to host in production on Meteor.com, but I feel I can't trust it right now. Free is nice, but I need reliable, production-quality Meteor hosting. When will I be able to buy that from Meteor.com?
Thanks,
Graeme
From the documentation:
We provide this as a free service so you can try Meteor. It is also helpful for quickly putting up internal betas, demos, and so on.
So it means it's intended to try things out, not for production. They offer it for free, I think it would be bad manner to abuse it. And with so many people around trying the thing, don't be surprised if it's overloaded from time to time.
I'm not sure if and when the Meteor team will make this hosting production ready. At this moment, I'm happy they're focusing on making the framework mature.
For other options, Heroku works as a charm. I'm using it for several projects, including production ones, and had no problem. Don't bother with demeteorizer and such. Just create a new app and run these commands (replacing appname with your app name):
heroku git:remote -a appname
heroku config:add ROOT_URL=appname.herokuapp.com
heroku config:set BUILDPACK_URL=https://github.com/oortcloud/heroku-buildpack-meteorite.git
git push -f heroku master
MDG (the Meteor Development Group, the core team) is working on a hosting solution called Galaxy. It will likely tie in to meteor in ways other solutions won't (such as meteor deploy). This will be (AFAIK) a paid service, and as such will likely offer analytics for better insight (my guess). And of course scaling will be taken care of for us.
More on the subject: http://www.meteor.com/blog/2013/10/01/geoff-schmidt-at-devshop-8-getting-meteor-to-10

What's the best way to simulate a complex production web development environment?

I want to create a modestly scalable development environment for an in-development web service.
Ideally, there would be an nginx web server with haproxy and a few database servers, websockets, the works.
I'd be going with Amazon cloud services for all of this hosting... but I'd rather not pay for CPU cycles when I'm just developing... much less develop on a remote, cloud environment.
What's the best way to go about modeling a somewhat complex development environment locally that could - hopefully, at the press of a button - sync with a similarly architected Amazon cloud environment?
All I have is my Macbook Pro. I also have a fully built 1Ghz tower computer in the closet I could leverage, if needed, and wouldn't be opposed to buying more. But, ultimately, I'd like to have the ability to sync to production with minimal steps and reconfiguration.
Thanks!
Check out vagrant and virtualbox. That will get you local environments running nicely on your macbook. Syncing to EC2 is going to be tougher. At the system level you'll want to use something like puppet or chef (which are both nicely supported by vagrant). Add to that a solid automated application deployment mechanism and you should be close. Be prepared to put some time into this, it's not likely to be a trivial undertaking.

Resources