It is very difficult to say where the slowness comes from. I wish I could say. I mean “slowness to render when you click on something”. Sometimes more than 2 seconds of seeing “loading …” when clicking something.
We had maxed out CPU issues for a long time until I moved to bigger machines on EC2.
In these situations the app became completely unresponsive. Now it is just “not snappy”
I currently have two meteor processes running on an EC2 t2.medium using mupx. They run on different ports and nginx “ip_hash” load balances on a sticky ip basis.
Mongo runs on a separate t2.small and never shows any load on the graphs on the EC2 console.
As mentioned, we do not have oplog tailing enabled.
We have separate node processes that write to / update the same collections so contention /locking issues here is not out of the question. On the other hand, simple admin pages reading from small collections also aren’t ever very snappy.
Is there a way of gaining insight into how much data is being transferred via ddp between the server and a client?
I’ve paid for the basic Kadira but this hasn’t given me any clues, nothing looks obviously wrong.
Server CPU profiles just showed a lot of time on “other” or something, and profiling of the app when it was flailing at 100%cpu never succeeded. Nothing helpful from client-side profiles either. From memory the bulk of time was within Meteor “processing Mongo documents”
Number of users seems more or less proportional to CPU usage. We have never even had number of users > 15. Users see a lot of graphs that can be resized etc so there are some unavoidably heavy subscriptions.
I’m using most of the suggested kadira packages except for kadirahq/subs-manager
This made things snappy but at the expense of up to date information.
If Pub/Sub/ddp got things totally right why would there be any need for subs-manager?
We have been running on Meteor 1.1 for a long time.
I have a 1.3.4 version of the app being tested in Staging. It doesn’t seem obviously faster.
I wrote the initial sketch of an app then it was fleshed out by a relatively junior developer.
There is definitely plenty of sub-optimal code in there, but I would like to be able to work out what parts to investigate from more of a “distance” first.
Any advice on diagnosing the slowness please?
METEOR@1.3.4
standard-app-packages
iron:router
accounts-password
multiply:iron-router-progress
ian:bootstrap-3
ian:accounts-ui-bootstrap-3
ephemer:reactive-datatables
wylio:mandrill
comerc:bs-datetimepicker
kadira:debug
meteorhacks:kadira-profiler
meteorhacks:fast-render
standard-minifier-css
standard-minifier-js
email
meteorhacks:ssr
.A