Yes you are correct. Normally, SockJS long polling connection last for around 10-30 secs.
Last time I check(few years ago) Heroku closes a long polling connection after 30 secs.
Most of the user could get WS. But at least ~10% connection needs to go through SockJS.
I don’t think we can’t reduce it anytime sooner.
To follow up:
After Arunoda pointed out to me that I had my Compose deployment in the wrong west coast data center (AWS not DO), I set about fixing that up.
mup deploy (1 min)So in less than 10 minutes, I had my database in a new data center and instances of my app on two different platforms (DO and AWS) pointing to the correct mongo url.
I can’t see all of that happening in less than half a day (with lots of googling and painful trial and error) if I was doing the same thing with DIY database hosting. (But then, I’m pretty crap when it comes to dev ops stuff.)
For me, this is a big argument in favour of hosted db solutions like Compose.
After having painfully experienced few hosting services, I’m using linode since 2010 for production servers running ubuntu/lighttpd/php/mysql without major issue so I stay with them for the new stack ubuntu/nginx/meteor/golang/mongodb.
Good price, fast and reliable infrastructure, excellent support.
For backup systems, I’m using OVH servers. Affordable, plenty of disk and cpu. Here again the support is good and quick to respond.
Hi, I’m having issues deploying to modulus as well. Trying to deploy my local codebase to a new app project on modulus to use as a staging site. I recreated the project, and in my modulus CLI, I do a deploy to the new project I created and I get this error:
[Error] This command has been deprecated in favor of ‘meteor build’, which allows you
to build for multiple platforms and outputs a directory instead of a single
tarball. See 'meteor help build’for more information.
Are you getting this error too? If so, were you able to resolve this? I was going to post this as a new question to the forum but wanted to check with you first to see if you were able to get past this. I’m not sure if this is an issue with modulus or meteor.
Thanks for any help you can provide,
Don
Just chiming back in to say that setting up MUP on DO was a breeze. I can even just use the hosted mongo db while in development, which is a huge plus. Can’t argue the $5/month for what (now) seems just as easy as Modulus. I may miss some of the bells and whistles (SMS notifications, usage statistics, a GUI…) but this is promising.
Caveat - I’m not yet running in production. But, I have the following working pretty well: Git commit triggers CircleCI build of Docker image which gets deployed to Amazon EBS. Mongo hosted at Compose. Going the Docker route also gets around the Node version issues.
I plan on playing around with adding Cluster to the mix as well.
Please, please write a blog post or tutorial on how you got all this working. Sounds like a great setup!
FYI. I am currently running on AWS Opsworks. Previously, I had it running on Beanstalk but from what I can tell now they don’t support OOTB the pre-reqs for the latest Meteor.
My Opsworks is all running OK for beta… but trying to get SSL working - so not full up and running yet.I just posted this question on Stackoverflow. http://stackoverflow.com/questions/28952351/having-issues-setting-running-meteor-app-with-ssl-on-aws-opsworks
Can you elaborate on the autoscaling approach with DO @arunoda? Are you firing a webhook via Kadira that triggers a DO API call?
About the DOS attacks. Yes, that’s a huge issue. We’ve fixed a kind of issue in a popular Meteor app recently.
We’ve also started a new package for mitigating DDP level DOS and rate limiting.
It has captcha support as well.
Just watch for this: https://github.com/meteorhacks/firewall/tree/global-rules
We’ll have the first release in early april.
We don’t have something like that yet.
We’ve plans for an API for Kadira. May be with that.
Used to be deployed on AWS Elastic Beanstalk but recently just moved to AWS OpsWorks using custom Docker containers. EBS was great at first, but eventually we could not have the customization we wanted without great struggles and the caveat of either losing websockets or sticky sessions if we were going to use the Elastic LoadBalancer.
Now, on a single machine through OpsWorks, we have a meteor docker container, an nginx docker container with websockets enabled (and serving SSL), and a papertrail container which logs all of our server’s events. We also have meteorhacks:cluster installed so that if we need to spin up more servers, it’s painless and will preserve our websockets/sticky sessions.
Currently I am in the middle of writing up a blog post detailing how and with what it was put together with. Will probably post it to the forum when I’m done.
Sweet. Looking forward to that. This sounds like a really solid production set-up.
Hey everyone!
Thanks for the shout out @babrahams! I hope that video helped you. It’s pretty old and I plan on making a better one in the future.
I work with @jkatzen on the same production meteor app that he mentioned above. If you would like to talk about production quality meteor deployments please feel free to set up a video call with either @jkatzen, myself or both. Just follow this link and set up a time.
@khamoud – the only reason I was able to deploy to AWS was because of your video. I was a complete n00b to dev ops, so without that I would have had no hope. By the way, that deploy method you outlined still works. I made a few comments on the accompanying gist that keep it current.
Pretty stoked to hear that you and @jkatzen are working together, as the OpsWorks set up sounds really legit. Very kind of you to offer to talk with others about production deployments as well!
Maybe I’m missing something, but in my EBS Config screen I see the option to enable session stickiness…
If you enable sticky sessions on EBS then you will lose the ability to use websockets. You can have sticky sessions or websockets with EBS but not both.
To get websockets working on the AWS Elastic LoadBalancer, you must switch your port configuration from HTTP/HTTPS to TCP/SSL. However, while websockets may work through the TCP/SSL protocol, the ELB is no longer parsing any HTTP messages, making it impossible to keep sticky sessions or X-Forward headers from your server.