Galaxy performance issues

deployment
1

I’ve been working on an app for awhile now - runs like a dream locally, basically behaves exactly as I would expect it to. I deployed it to Galaxy recently and I’ve been seeing some serious performance issues in some weird spots. Namely, it seems like my subscriptions are taking way too long to be ready, they don’t actually fire off until you log in (even though they are in the startup.jsx file) and there is even a 5 second or so lag when you reload the page before the app will recognize that you are already logged in. Signing up for an account will generally take 15-20 seconds on the deployed version as well.

App is deployed at: www.nexgenfantasy.com

Code can be found at: www.github.com/tonymckendry/fantasyFootball

Strangley enough, when you first visit the site, the login page shows up immediately, as I would expect, and after the initial loading of the subscriptions everything is very fast and responsive as I would expect it to be. I have console logs on the client side currently so you can see in the browser console when the app recognizes that you are logged in, and when the subscriptions are ready.

My largest db collection has about 3000 objects in it (all the players in the NFL) - currently they’re all being published at once, but I have actually removed all but a handful of them (and scaled down all of my other collections) and did not see a decrease in these load times. I have a $15/month shared cluster database on mLab as recommended by Galaxy.

This image shows the Chrome timeline from the time I click log in (green rectangle on the left), until the app is ready (yellow on the right) - I noticed that there is very little activity happening during this time. If I view this same timeline locally, there is not a large empty gap like that.

2236×787 143 KB

I am truly at a loss right now - I work on a very similarly structured app for my job, which is far more complex in nature and we don’t see these issues.

Basically, I am wondering if I have coded something wrong, if I might need to scale up my Galaxy container (or add another) or if I am just totally overlooking something crucial that might be causing these issues.

I reached out to Galaxy support and they said my question was outside of their scope.

2

Have you tried integrating Kadira APM to get a better idea of what’s happening behind the scenes?

3

I get some errors when trying to run your app:

Warning: TeamItem: prop type `item` is invalid; it must be a function, usually from React.PropTypes.printWarning @ modules.js?hash=40cbdf1…:22031

Warning: React.createElement: type should not be null, undefined, boolean, or number. It should be a string (for DOM elements) or a ReactClass (for composite components). Check the render method of `Login`.printWarning @ modules.js?hash=40cbdf1…:22031

Uncaught Invariant Violation: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object. Check the render method of `Login`.invariant @ modules.js?hash=40cbdf1…:21974

But one thing that caught my attention is how you subscribe to your publications:

https://github.com/tonymckendry/fantasyFootball/blob/56e0e96e50da1bf3127c2b84cd0d841865e6aaac/client/startup.jsx#L20

This code will mean that you will subscribe to all those publications several times, because when autorun() block runs again on subscription ready status, all thos subscribe(...) will be called again. And then again. And having a lot of subscription can be the cause of the slowness you see in production. Try doing it like this:

    var usersSub = Meteor.subscribe("users");
    var playersSub = Meteor.subscribe("players");
    var teamsSub = Meteor.subscribe("teams");
    var gamesSub = Meteor.subscribe("games");

    Tracker.autorun(function(){
      if (teamsSub.ready()) {
        Dispatch(App.Constants.Dispatch.teamsReady)
      }

      if (teamsSub.ready()
          && gamesSub.ready()
          && usersSub.ready()) {
            console.log('subs are ready')
        Dispatch(App.Constants.Dispatch.subsReady)
      }
    })
4

Will definitely give this a shot! Thanks!

5

Hey @hwillson, we meet again :slight_smile: haha

Galaxy support mentioned Kadira to me, and I looked into it and it just seemed like a paid for monitoring service (trying to keep costs low atm) - what benefits am I going to see if I use Kadira? maybe I didn’t understand it correctly

6

Kadira APM has a free version, which works really well. Kadira will give you insight into what’s happening behind the scenes in your app, so things like pub/sub response time, method response times, overall server health, etc. It’s really helpful when troubleshooting performance problems like the one you’re seeing. For more specific details, check out the Meteor Performance 101 article put together by Kadira - they step through different ways to troubleshoot and improve the performance of your Meteor app, using Kadira APM as the tool to do so.

7

I will just add that I had a similar issue to yours with my app and it was thanks to Kadira that I found the issue, which was subscribing too much without stopping prior subscriptions.

8

Thanks for all of your help @hwillson and @M4v3R - will try these fixes this afternoon and report back!

9

Just wanted to check back in and say thank you! Changing up my subscriptions definitely cut my load time down by a lot. It still seems slow at first, but I think I should be able to improve it even more. Regardless, big difference!