if you really plan on having 100,000/s oh well, PHP, JS, Ruby may not be what you are looking for, go for something more barebones, C, Erlang, Go, and definitely not on a laptop.
Websockets imply more resources, it’s not static like a php website, pls keep that in mind.
You can use meteor without websockets, it’ll fallback to sockjs an emulator for websockets that works through ajax, you will not benefit from it’s true reactivity but you still would have access to a lot of nice things, that enable rapid development.
So you want stats, there are some guys from codefights, which documented their struggle with Meteor. They needed 10 containers (1 core 1GB) for 1000 concurrent users. That’s very very disappointing. The reason was oplog tailing, without it, Meteor is as fast as any js framework + websockets.
The oplog tailing is it’s main issue, problem which I am going to personally take care of: Meteor Scaling - Redis Oplog [Status: Prod ready] to enable horizontal scaling. We’ll be launching a social network in Meteor soon, the news is going to hit 300,000 people, so we can expect 2000-5000 requests per second. This is why, we’re focusing on this so heavily, we invested a lot, Meteor has helped us make something truly magical and great, but now it’s time for us to contribute to Meteor and bring it to next level, it deserves it! (We already did by introducing [Grapher] (http://grapher.cultofcoders.com) and gave it to the world)
So all in all, if you embark on Meteor’s train right now, you’ll be
hit with some great stuff in the near future, that’ll make Meteor super scalable.