Deleted. Not relevant; took down the Galaxy hosting for the time being…
I’m running our business software on Galaxy + mLab and no issues.
Did you create indexes on mLab for your most common queries? The mLab administration page should let you know if any queries are taking a long time and suggest indexes.
Is your mLab database at the same location as Galaxy? I believe us-east 1 if i remember correctly?
One thing that did not show up in our development server, was our paginated pages, actually had a (outdated) publication that was sharing an entire collection of logs/orders/products/etc every time you went to any page. Pagination seemed fine and performance issues did not show up on development server (that hosted both the app and database on same machine).
Assuming these things are handled, there’s no reason there should be any major issues as long as your not sharing any ridiculously huge collections.
(PS - Tried out your site and it seemed to be running fine for me, no issues! Is there anything specific I could do to test a specific sitaution that is causing issues?)
1 Like
I can confirm that mLab + Galaxy performs almost as well as a localhost collection for our app, and we run some complicated queries in our subscriptions sometimes. Which part of your app is crawling? Can you set up either kadira or some basic metrics for pre/post sub times?
4 Likes
Noticed you edited, just had a little bit of input:
In our experience, when it comes to performance, it would be very hard to beat Galaxy/mLab hosting for performance on a scaleable system.
You can host the database & app on the same machine, but that would make it much less scaleable without a lot more devops.
If you have poor performance, it must be issues in the implementation somewhere. I guarantee some of us here could help you out, but we would definitely need some more information. About your publications, subscriptions, what parts are performing poorly, your indexes on mLab, and so on.
We have found that in most cases, you will put far more stress on the database than you will on the app server itself. So the problem is likely with your indexes on your database, or you might have been too “query happy” in your development of the server. It’s very easy to fall in to the trap of not thinking about how many find or update calls you do when developing with database on the same machine. But those can become big issues once you go to a legit production database, and one of the first places you should optimize.
Our business app does a lot of repetitive routines and we generally do not surpass half of 1 containers allotted CPU on Galaxy.
2 Likes
Yep, I agree with you in hind sight. It worked well with out data management; but add a few connections and serious problems arrise. LIke any application.
I’m not alone in this voice however, and there’s still a lot about Meteor that’s difficult for newer users.
Fantastic learning project.
I believe my problem is now officially resolved.
The debate of “Should I get Galaxy hosting” is that it’s easy. But you really need to pump money in to it for high volume applications. I mean, I’m building an MMO. What else would you expect? But I’m trying to push Meteor to the LIMITS right? 
Anyway, I really stripped down on the data, it’s even cached, which is really cool. My CPU said it was only at 60%… but… I upgraded from a single core to a six core, and BAM, cpu dropped to 2-5% and she runs like butter!
Doing the same action at Meteor Galaxy would have been easy, but costly. 1 Click and boom, speed increase right? Well too bad it was $28 USD for a ‘trial’ account. Sucks. I would have been paying about $100 USD a month for for the same $40 dollar a month service - so we can see that Galaxy earns for being a premium service. (and the should!!!).
I just upgraded my VM at google compute and it destroyed all data. I have my own deploy script now, so it only took 4 minutes of down time to perform; but I’ve been at this now for like a year with Meteor!
New? Galaxy with out a doubt is the way to go.
Cheers and thanks for all who stepped in on this SUPER complicated thing…
It’s really a pretty different ball game though, in your case you are comparing a VPS to cloud. Basically, I would think when people go with Galaxy for serious applications, they are doing it to allow the app to easily scale. That was the primary reason our business went with Galaxy and mLab from the beginning. No wasted time on devops, and we can easily scale as we need in the future without any further changes, or possible complications.
With that said, glad it’s working well for you now! And I wish you good luck, as someone who has dabbled with game development myself, it’s awesome to see Meteor being used for one!
1 Like
Yeah I wasted a lot of time trying to make Apache forward NodeJS ports. What a mess.
Then moved to Galaxy, it’s great.
But I’m doing something really, REALLY complex now… Bleh. I had to just dedicate a bunch of hours to learning what I didn’t want to learn, DevOps… But now I’m a pro at it.
Resume++;
By any chance are you using the free version of mLab? If so, that’s the issue.
Yes I was on free, then I moved up to the first paid for package.
You are correct, as now I’m on Google Cloud Compute and had to move to a QUAD core and do a lot of DB optimizations, still hitting 30% cpu there. Initial was 200% maxed out.
I’m hosting a friggin MMO after all, this should have been obvious in hind sight.
Honestly, I think mLab is hurting themselves with how slow their trial tier is. I mean, I get that they want to encourage people to move to the paid tier, but most customers are just going to assume mLab (in general) is garbage and go somewhere else. I almost did.
1 Like
I had hosted a web application with no problems.
it’s only because I’m doing some crazy stuff I found them slow. 