Meteor build & deploy incredibly slow

deployment
1

Between the slow build times (local) and the slow deployment on Galaxy (as well as a few minification bugs I’ve run into recently), this ecosystem is starting to drive me away. Is there anything being done to speed up build time? And on the Galaxy side as well?

1 Like
2

What times are you seeing for build and also for deploy?

3

thats funny because I just posted today how I thought they were way faster

4

3.75 minutes to build/upload. Once Galaxy sees it, it takes about 3.5 minutes till code push to the user. I’m not sure if this is typical or not, but it seems like a while.

1 Like
5

I use Semaphore CI, I push to a Github branch, Semaphore monitors the repo, gets the new push/webhook and starts a build. It:

  1. downloads meteor
  2. downloads npm dependencies
  3. starts app
  4. runs tests
  5. If successful, deploys to galaxy.
  6. Galaxy does almost similar except the test part.
  7. Starts new servers, then stops existing servers.

For me its’ 2-2.5 minutes on semaphore, which falls under their <10 minutes category, they call Good.
2 - 2.5 minutes at Galaxy.

You could potentially see a faster time if you deploy from a CI box with a webhook, vs locally, especially if you choose a CI box that is in the same AWS Datacenter as your galaxy deploy.

6

Semaphore can be configured to cache large parts of the app, the downloads and npm libraries to speed up those downloads. Could probably reduce another 30 seconds minimum

7

I don’t know if I’d call it “incredibly slow”, but it does impact our workflow. For our production server, it’s not such a big deal as we only do one or two deployments a week. But for QA, our goal is to mimic production as closely as possible, which means running on Galaxy. With sometimes multiple deployments happening every day, the build time is noticeable.

And I also agree that the post-upload time is problematic and impacts my workflow as a developer. Obviously, I’m pushing to QA with things I need our team to look at, so if they aren’t looking at the latest deployment, they aren’t seeing the right thing. Which means I usually have the Galaxy logs open, waiting for the Application exited with signal: killed message so I can ping them and let them know the deployment is ready.

Not sure much can be done about the local build, but I would definitely like to see some hooks for the build on the Galaxy side. Building some slack hooks into Meteor startup is on my list of things to do, but it feels like that is unnecessary code bloat and should probably be handled at the deployment level?

8

You can create a small function that executes when your server/instance starts up. You have access to the Galaxy container id from within the environment variables in the meteor app. Using this, you can compose the link that Galaxy uses to connect directly to an instance.

The format of the link is:

https://APPNAME.meteorapp.com/?g_container=CONTAINERID&g_debug=true

APPNAME is the name/subdomain in the config
CONTAINERID is the Galaxy container id env variable.

The environment variables you have access server side are:

process.env.GALAXY_APP_VERSION_ID
process.env.GALAXY_CONTAINER_ID

So you can make a link such as:

if (Meteor.isProduction) {
  const version = process.env.GALAXY_APP_VERSION_ID
  const id = process.env.GALAXY_CONTAINER_ID
  const link = `https://appName.meteorapp.com/?_g_container_=${id}&_g_debug_=true`
  Meteor.call('sendAWebHookOnStartup', link, version);
}

This will give you potentially a nice message in slack with a clickable link directly to the new instance, with the version number in Galaxy. You don’t have to use a meteor method, just an example.

1 Like
9

I’ve got my own custom deploy scripts. Been building the application for about 3 minutes.

Comes out to 150mb, which I have to wait to upload. There’s 5 mins.

Then once it’s on my Google Cloud Compute server, the script to deploy the update is insanely fast. 20s and it’s done.

It’s about exactly as fast as Galaxy.

ONLY other hack way to do fast deploys, is RUN METEOR on a VPS, and push your /client/template/testing.html file up, and Meteor will serve that page up. You can even run in --production mode to minimize your code.

Just thank your lucky stars your not in Java…

10

I’d like to try out Semaphore CI for building my Meteor app. Could you post a link to your Semaphore CI config file (or whatever portions you don’t mind making publicly available as a gist) so I can see how to get started? Thanks!

1 Like
11

Hey Phillip,

I posted a new forum link here with a brief guide

12

Thanks so much! Very helpful!

13

My deploy on galaxy takes more than 30 minutes! Its super frustrating. Build size is 68MB. upload speed test indicates 0.6MB/S. I don’t understand why this is taking so long…

1 Like
14

I’m in your boat, @yann – deploy is catastrophically heavy & slow. Last two deploy attempts failed because of running out of memory or socket hang up. Halp!

Edit: Those of you with slow build times, is anybody using meteor-webpack? My team started with it before it got deprecated, have been making workarounds to stick with webpack ever since. These builds are stupid slow, though, an order of magnitude longer than what some of you are reporting. Anybody else using that in their build chain?

15

Very typical build times. Yes, it’s annoying, but you’re building an app.

Program on localhost and push to production when necessary. My app at www.StarCommanderOnline.com is FINALLY stable. I do about 2-3 updates a day to it on peak days.

It sucks using a mac from 2008 to process it, but it’s all automated now. So I set it to update and walk away from the PC.

My app is about 100mb, so lets assume yours is too. I bet a big part of your deployment is simply waiting for the upload to process. Then galaxy builds an entirely new container, starts it up, runs your app, and swaps it out.

My custom hosting solution, my users simply drop from the game, which is kinda bad. +1000 points for Galaxy here.

Another way you can do it, is run Meteor on the custom ubuntu server. Then you can run meteor --production, which isn’t the BEST practise, but if your app is small it’ll be much faster, as you can now just push that 1 file you updated to ‘production’ and meteor will auto refresh.

16

meteor deploy has to upload your build to Galaxy, and it’s huge, so yeah if you are on DSL at home then it’s going to take a long time.

Take advantage of the free CircleCI plan with the GitHub trigger so that it picks up your latest changes and if all your tests pass in the stable branch it deploys to production.

(Or whatever rules you feel comfortable with)

Point is, pushing your updates to GitHub is way faster than pushing an entire Meteor build (without diffs). And pushing the Meteor build from CircleCI is way faster than on your DSL connection.

17

Do a local build and look at the size, from that you can get an idea of expected time to create and upload.
Remember that all the resources you put in the build, for instance stuff in /public like videos and images, has to be uploaded.