MongoDB MMS for Production


#1

Hey, has anyone been using MMS in production?

I’ve set up a 3.0.3 replica set for an upcoming product launch, and I’d gladly hear out others’ experiences/best practices

One issue I’m experiencing already is when I use the MMS db for my local dev, it takes a considerable amount of time to start up the app (maybe it’s just the internet in this office space I’m at right now)

I also intend to run the WiredTiger engine… I’ve read a couple of positive posts about it in the forums

Thanks


#2

I think we should ping @khamoud for this :wink:


#3

Hey! Thanks for the ping! I’ll try to answer your questions to the best of my ability. We use wired tiger in production and we have had reported data sizes of 11GB compress down to 2GB but we have also seen some numbers like 11GB down to 6GB. Still amazing but there is a pretty big difference in reports.

The time it takes to start your app could be a few things. It could be a slow internet or latency depending on where you are relative to where your mongodb is located.

Could you clarify on what you mean in terms of best practices? MMS has a lot of functionality and we’ve used it to trace observers, inefficient queries, we’ve seen the effects of both OPLOG tailing and long polling and the different issues that arise in either use case when we have high velocity data (eg. 100k documents bulk inserted/updated) and how that effects our meteor servers.

If you have specific questions I would be happy to answer of if you have general ideas I can also try to assist to the best of my ability.

Let me know :smile:


#4

Hey @khamoud ,

thanks for ponging back

as I’ve mentioned in my initial post, I’m bracing for a product launch and I like to be well-prepared
that’s why I’m gonna launch on a 3 nodes replica set

Since the post, I also set up oplog and WiredTiger successfully, and it seems like the slowness is only when I spin up the app (after a couple of page visits, it’s ok)

So everything looks pretty smooth so far, just wondering if there’s any caveat or misstep that you’d encountered during the initial configuration

Also, are you using 2.6.x within your project development?


#5

We used to be on 2.6.x but when meteor supported 3.0 out of the box we upgraded. Come to think of it we did have some issues with speed when we first launched. We used a combination of kadira and MMS to find that we had some slow/redundant queries and were able to get rid of them. If none of your queries are slow then you’re probably fine. We keep a screen in the office with our MMS up at all times to make sure our CPU and memory usage isn’t spiking for any reason. If you look at your graphs and see spikes then that is probably the cause of the slowness. It would get better over time because you would be caching some documents.


#6

cool.

so during development, do you use a local, external (to the Meteor default bundle) mongoDB 3 server?

btw, the performance figures you mentioned in the previous post are very encouraging


#7

It depends. One of our performance problems was caused by bulk updates on a task server. It would update 100k+ documents at once with pretty high frequency. We were subscribed on that collection and the CPU usage would spike because the OPLOG had to parse through those changes and it would crash all of our application servers. The solution was to move that data to a different mongodb altogether.

So to answer your question, if we need access to those high velocity documents then we connect to the staging db which is also deployed with MMS and has access to both our main and alt dbs. If we don’t need access to those documents then we usually work locally.

The performance figures are very good but we have seen some variation to the reports. In either case though the numbers are very good.