Sorry for the late responce. I have been testing different configurations for the past week. I used your guide above for scaling, as well as this guide: https://meteorhacks.com/how-to-scale-meteor.html
I also got advice from a more experienced Meteor developer than I, on how to optimize my code. From the Harida stats it looks like all has been fixed and I have had no more constant refreshes/slow downs.
Once the system has been stable for a couple of weeks I will report back, but it looks like the refreshes may have been caused by bad coding on my side
I still love Meteor and will definitely continue building with it.
Just to update people, I have continued to see this problem on a subdomain.
I changed my nginx settings but it didnāt seem to help.
On the regular domain, I donāt seem to have this issue.
Itās a mystery what this problem is. It can be a real killer especially
when you have a fair number of users and run the project on the side with
limited time to investigate.
In nginx config you have to set everything except the JS and CSS files to be Cache-Control no-store, because if you are using a router the main HTML file can be loaded from multiple locations.
I have two location blocks, one: location / {
And the other: location ~ /.*\.(css|js)$ {
Both have the proxy lines in. The first has add_header Cache-Control no-store;.
Both have the proxy lines in. The first has add_header Cache-Control no-store;.
I think that this disables client caching at all. As a result the bundled js gets downloaded everytime, a deal breaker for mobile / low-bandwidth environments.
and just set cache-control on my single / location.
I just copied the content from / to ~ /.*\.(css|js)$ and added add_header Cache-Control no-store; to /
Iāve no idea if it works (will update to this thread), but js and css files are cached now.
update
This did not solve the problem, itās still refreshing.
This was the location block which caused refresh loops:
location / {
proxy_pass http://app;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# WebSocket specific
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# this setting allows the browser to cache the application in a way compatible with Meteor
# on every applicaiton update the name of CSS and JS file is different, so they can be cache infinitely (here: 30 days)
# the root path (/) MUST NOT be cached
if ($uri != '/') {
expires 30d;
}
}
A lot tutorials and boilerplates advise to use this faulty configuration
Iāve been having this problem on mobile/android but not on OSX laptop - so hey I looked through my code for this nginx if ($uri != ā/ā) { expires 30d; } but I couldnāt find it. What file is this in? And if this isnāt a part of my project and Iām having the same problem, it could be something else. Whatās up? Thanks for your help everybody! Iām new-ish to meteor and deployed my first app (a very simple one) today.
I just tried adding appcache to my project and got an infinite reload locally. I wonder if this has anything to do with the issues. For now Iāve just removed appcache.
Just another datapoint on this. We recently updated our 1.2.x app to 1.4 (we tested 1.3, but not in production). We are seeing constant reloads whenever we run our app after using āmeteor buildā, but not if we run it using āmeteor runā. I can replicate this on my own laptop (OSX) as well as on out development testing servers (dockerized debian). Neither are using a proxy.
Point is, even if it is affected by nginx, nginx isnāt the cause.
Iām wondering if it is loading-order issue as Iāve seen some peculiarities in our logging that makes me think class may be being instantiated before they are defined. Iām seeing objects that just arenāt there, even though they should be created at startup and that is showing in our logs as empty arrays, for example. Strange stuff and it takes a long time to track down because I have to do a full build each time I want to test. ( What is this, C++? lol )
Well thatās great news if you can produce a reliable reproduction of the
problem. Would be worth posting the issue on github and finally getting
someone from MDG to look into it.
Maybe I spoke too fast. I upgraded my local mongo install to 3.2.9 (was 2.6) and now it has suddenly stopped. Iām going to try on our development testing server to see if it still has the problem (it is still running mongo 2.6). If it is, at least weāve isolated one possible cause of the problem.
.