When I saw it first time a moth ago I thought that it’s temporary issue, but it’s still there…
Just try to filter messages (Best, Trending, Recent), it will not filter them at all or will show results only after a few seconds.
Same problem with going into discussion, there I don’t see comments and even spinner, but it I would refresh page and wait a little, then comments appears.
Is it problem of Telescope code or some kind of Meteor limitations while trying to scale?
I am actually work on it today, going to move to a much more robust setup with multiple backend app servers and the latest ‘flow router’ version of Telescope. Right now the ms-seo package is creating a bunch of extra traffic on the current version of Crater deployed.
Give it a try again today. I moved the database much closer and ended up load balancing across 2 servers to help spread the load out a bit more. Between the two, I am seeing some pretty zippy response times so far.
Maybe only ‘Load more’ expirience isn’t so good yet, I have a couple seconds lag without any loader before the list is loaded, but this is a minor problem.
Is there a plan for ‘Crater.io optimaization in details’ blog post?
For sure. Was thinking about ‘Scaling your Meteor app without breaking the bank when Galaxy Dev subscriptions won’t work or your still waiting on your invite’, haha.
The whole Crater site now lives on 2 app servers at Digital Ocean, being load balanced using Nginx and I added the upstream health check plugin as well. The 3 digital ocean servers are in NYC3 and I moved the Compose.io deployment to be at NYC3 as well. Based on Kadira numbers, I may actually get the 2 app servers down to the 1gb option and bump it to 3 boxes instead.
I also removed spiderable last month and setup my own Prerender server that handles serving up pages for bots and Google. Spiderable was just untenable when Google is sending 10k bots a day to slurp up content.
Hi @joshowens . This is my first post on Meteor forum . I play with Crater.io 's Load more buttons successively for 8 times with chrome profiler. The below is what I discover.
The first click takes about 3.5s to finish. (I am a new member and can have only one image per reply…)
The subsequent clicks takes longer and longer to finish.
I think the problem maybe that whole discussion threads, even those existing, are re-rendered again. But performance-wise, only newly fetched threads should be rendered.
Actually I am facing a similar issue on the IM meteor app I am developing, do you have any suggestions how to do so so that only the newly loaded threads are rendered while the existing threads can be kept? Thanks!
In all seriousness, my guess is something is triggering a rerender, did you look at the DDP messages, are you just getting added messages passed down, or getting some changes to? Maybe it has something to do with recalculating post scores? Just spitting balling ideas here.
Temporarily I have tried two ways to mitigate the slowness.
Use Blaze.render to render the new items.
Pro: super super quick to render. (As existing items are not re-rendered)
Con: lost reactivity, will be hard to maintained
Create a mini mongo local collection, do intensive manipulation when inserting items into the collection instead of doing it on-the-fly in spacebar’s helpers(which I suspect doing too much DOM manipulation).
Pro: easier to maintain, keep reactivity
Con: Performance not better than first way.
In long term, look like it’s time to ditch blaze and learn some react for good