Hey all,
I’m building an app that’s architecturally basically a to-do list, and everything is performant locally, but once I push to Cloud, it gets insanely slow. Mongo DB requests are working a little slower than I’d thought, but not terrible. (I’ve got a Tiny instance and am using the shared db option, so not expecting super-speed) But the Meteor user functionality is what seems to be biting me in the butt.
I’m using const user = useTracker(() => Meteor.user()) to get the logged in user info. Going from page to page in my app (using react-router-dom) seems performant, but first page load takes 20-25 seconds. If the user isn’t logged in, the user call resolves to null quickly, but if the user is logged in, it’s consistently slow.
If I load the page, it’s 20-25 seconds. Then if I just do a browser refresh, it’s another 20-25 seconds, even though between-page stuff seems to work. Is there a really easy gotcha for this? I would assume so, since this makes the app essentially unusable. For a test, I’ve removed any other db calls, and am just doing the user check, and it doesn’t impact the load speed.
My .meteor/packages file looks like this:
meteor-base@1.5.1 # Packages every Meteor app needs to have
mobile-experience@1.1.0 # Packages for a great mobile UX
mongo@1.15.0 # The database Meteor supports right now
reactive-var@1.0.11 # Reactive variable for tracker
standard-minifier-css@1.8.1 # CSS minifier run for production mode
es5-shim@4.8.0 # ECMAScript 5 compatibility for older browsers
ecmascript@0.16.2 # Enable ECMAScript2015+ syntax in app code
typescript@4.5.4 # Enable TypeScript syntax in .ts and .tsx modules
shell-server@0.5.0 # Server-side component of the `meteor shell` command
hot-module-replacement@0.5.1 # Update client in development without reloading the page
autopublish@1.0.7 # Publish all data to the clients (for prototyping)
insecure@1.0.7 # Allow all DB writes from clients (for prototyping)
static-html@1.3.2 # Define static page content in .html files
react-meteor-data # React higher-order component for reactively tracking Meteor data
accounts-base@2.2.3
accounts-ui@1.4.2
accounts-password@2.3.1
littledata:synced-cron
email@2.2.1
Any help you could provide would be amazing. Thanks!
maybe problem with websocket? best check the devtools and observe the requests in the network tab.
Might be that websockets hang and then it falls back to longpolling.
Do I need to make any changes regarding websockets when deploying to Cloud?
Hi @hoggworks, what region are you deploying to? Where are you accessing the website from?
Because you are using the Tiny container and the shared MongoDB it should be a bit slow but it shouldn’t be taking 20-25 seconds
Which Meteor Version are you using?
1 Like
I’m running meteor 2.7.3, and also these:
accounts-base@2.2.3
accounts-password@2.3.1
accounts-ui@1.4.2
I’m also using autopublish; I Just created the app a couple weeks ago, it’s pretty new.
Thanks!
This is likely due to the autopublish package, which results in your app sending all data of your collections (and those collections used by packages) to be sent to the client, blocking the main thread when loading the application.
Suggested fix: remove autopublish and use publications only where “live” data is really necessary (for example watching updates from other users in a shared TODO list). Otherwise use Methods to send data.
4 Likes
I have an app running in Meteor Cloud using the same free plan, and it takes less than 2 seconds to load. So you should get similar results.
You can check it here: http://simpletasks.meteorapp.com/
This is the source code: GitHub - fredmaiaarantes/simpletasks: Simple Tasks with Meteor + Chakra UI + Formik + MongoDB
So my suggestion is the same as @jkuester, and if you just started the project and could share the code with us, that would also help find the root cause.
I’ve seen tutorials talking about removing auto publish, but they all seem to involve creating your own publish replacement. My app doesn’t need the real-time updates, so would I need to worry about adding a publish replacement?
Thanks for the suggestion! I removed autopublish and the first load is significantly faster. The loading in general is sluggish, but I’m guessing that’s because of my instance size and using the shared DB, but it’s now usable for testing purposes.
Thanks!
2 Likes
It will be super slow and extremely overpriced, until you get a proper production setup. Buy your own server and run meteor inside screen and reverse proxy it via nginx or any web server of your choice. I prefer nginx because I’ve used it for over a decade and it doesn’t flinch at 4 million daily users. Load balancing is great and it doesn’t take up hardly any resources. Plus it’s free, so what’s there not to like?
Once your meteor is running along behind the proxy you can then just start mongo on the same box, zero network overhead because you are just hitting localhost and you aint sharing with no one it’s all yours. So it will run real fast.
The total cost of this will be under $100 a month from most VPS providers, you may even be able to just run a box on your local network and forward the dns for free if you are still a startup and fancy doing it for shits and giggles. You’ll learn a lot and save a stack of cash also. You’ll just need a static ip or a way to setup your router to do dynamic dns forwarding if you run it from home. if you run it from your dorm then make sure running a server is ok, sometimes it isn’t. Enjoy!
1 Like
I do appreciate the thoughtful response to my question, Truedon. Removing autopublish solved the extreme slowdown, and it’s running at an acceptable speed for the cheapest tier, and for my current usecase, which is as a prototype to see if the product I’ve got in mind makes any sense.
I’ve been a dev for a couple decades, and while I definitely have the knowledge to set up a local box and handle all of that stuff on my own, the benefits of being able to deploy to a cloud-based system means I can focus my time fiddling with the app, not the server. 
Honestly, considering I’m not using the real-time aspects of Meteor, if this prototype pans out I’ll probably eventually just port it to another system, since it’s pretty straightforward.
Cheers!
3 Likes
Fair play man if you are not using the real-time stuff in Meteor it’s still worth it because of the core and simplicity although I hear you. I’m coding since assembly pentium / commodore 64 / zx81 bbs days, getting pretty old now. Love meteor for what it has. But my true love is GNUGPL which isn’t always leveraged for what it is, so I’m just always driving home the fact that it’s free and we shouldn’t pay a dime to these SaaS cloud services for what can essentially run on a old pc in the basement.
Glad to hear it’s working and you really shouldn’t run autopublish in production because it’ll put out everything onto the client which is just a slight security concern before you break out of the prototyping stage. Have a good one
1 Like
Haha, you’re not the only one. Brings back wonderful memories!
1 Like
Nice! Yes it was a truly great era, I miss demo disks and tapes the most. The excitement of getting something in the mail and sharing it with friends. It’s gone now but not forgotten!