Live data from Hacker News

Stockfighter is live

stockfighter.io

101–110 of 151 posts

Re: Stockfighter is live

#101
post #65

Earlier quoted context omitted.

Sequence of events: 1. You play stockfighter and get the highest score this year. 2. patio11 emails you and says "hey, you're awesome. are you looking for a job?" 3. You say "yes!" 4. patio11 emails pc (CEO of Stripe) and says "hey 2oi4j3 is awesome, here is proof (i.e. your stockfighter score)" 5. pc emails you and says "hey let's talk about what job you would like at Stripe, and let's bypass most or all of that tec…

that business model... if you've nothing nice to say, say nothing, i'll keep to that

"say nothing" ...hm... looks like you failed. Better luck next time!

Re: Stockfighter is live

#102

I can't get the first level to play, seems things are still overloaded. Really looking forward to this though, hope you will post or email again once things settle to remind us about it. edit: this is the message im getting trying to play first steps, if it helps, dashboard says "Trades.Exec() (Status: playable!)" (3:08 UTC) > We couldn't start the level: This level has been locked by a different server. (Sorry if th…

I'm going to try to build a self-help tool for unlocking level instances.

Briefly: you get round-robined to a (healthy, importantly) GM machine the first time you try to start a level and that association needs to be fairly sticky. Once you've started the level, a piece of that box's memory is all your own until the level ends. To prevent a single player from getting memory on all the boxes we "lock" a level to a particular box. While the level is running, no other box will open the same level for the same player.

The problem is when the GM with your box becomes unhealthy. Nginx will put you in touch with a different GM, which could possibly mean your level is still running on a box you can't contact. At that point, you have to wait for either that box to hurry up and finish dying, for me to do a redeploy, or for one of the other GMs to figure "OK, that level appears locked but it's a very old lock so it's unlikely it is legit. I'll unlock it for you and grab the lock."

Levels generally die ~40 minutes after starting (but who knows with a failing GM). The lock ages open after ~1 hour.

Re: Stockfighter is live

#104

I am not a devops but seriously curious, wouldn't this scalability problem they are experiencing been solved already by using Amazon EC2 and stuff?

not sure if you are joking, since they are using ec2 afaik

Re: Stockfighter is live

#105

I can't get the first level to play, seems things are still overloaded. Really looking forward to this though, hope you will post or email again once things settle to remind us about it. edit: this is the message im getting trying to play first steps, if it helps, dashboard says "Trades.Exec() (Status: playable!)" (3:08 UTC) > We couldn't start the level: This level has been locked by a different server. (Sorry if th…

I'm going to try to build a self-help tool for unlocking level instances. Briefly: you get round-robined to a (healthy, importantly) GM machine the first time you try to start a level and that association needs to be fairly sticky. Once you've started the level, a piece of that box's memory is all your own until the level ends. To prevent a single player from getting memory on all the boxes we "lock" a level to a par…

Perhaps it could be as simple as keeping a hash of levels tied to a box. When your monitoring alerts that your box is unhealthy, run a process to remove all locks associated with the dead box allowing the player to refresh and restart the session?

Also, maybe a new error, is getting mixed in, response from /gm/levels {"ok":false,"error":"exit status 1"}

Re: Stockfighter is live

#106
post #49
post #34

Earlier quoted context omitted.

I BLAME RAILS.

Thomas and I have a running gag about this. Rails is holding up admirably. You can still actually see the website. Our problem is presently that one player implies 1+ ruby (not Rails) processes running bots and doing orchestration for their levels, and that has pegged the CPU on all of our GM boxes and also, possibly, saturated their network links as they hit the venue with... I don't actually know how many orders ha…

> Rails is holding up admirably.

... except that you have to spin up more boxes.

I think you have a different definition of "admirably" than most of us :-)

Follow Twitter's lead and switch to a JVM-based solution when you get a chance, you'll be shocked.

Re: Stockfighter is live

#107
post #65
post #62

Earlier quoted context omitted.

hmm yeah I get that but still, what does an "introduction" mean? :)

Sequence of events: 1. You play stockfighter and get the highest score this year. 2. patio11 emails you and says "hey, you're awesome. are you looking for a job?" 3. You say "yes!" 4. patio11 emails pc (CEO of Stripe) and says "hey 2oi4j3 is awesome, here is proof (i.e. your stockfighter score)" 5. pc emails you and says "hey let's talk about what job you would like at Stripe, and let's bypass most or all of that tec…

I think skipping #5 is unwise. What's to stop someone from making starfighter account, scoring well, and then selling their account to some middling programmer?

Re: Stockfighter is live

#108
post #49

Earlier quoted context omitted.

Thomas and I have a running gag about this. Rails is holding up admirably. You can still actually see the website. Our problem is presently that one player implies 1+ ruby (not Rails) processes running bots and doing orchestration for their levels, and that has pegged the CPU on all of our GM boxes and also, possibly, saturated their network links as they hit the venue with... I don't actually know how many orders ha…

> Rails is holding up admirably. ... except that you have to spin up more boxes. I think you have a different definition of "admirably" than most of us :-) Follow Twitter's lead and switch to a JVM-based solution when you get a chance, you'll be shocked.

I'm a fan of the JVM, but it doesn't remove the need to be prepared to scale up by adding more machines. That said, it's great at concurrency, so it's easier to harness the full capability of a machine than with other platforms.

Even if I didn't need multiple machines for throughput I'd probably still want them for redundancy (redundancy of machine hardware as well as redundancy across availability zones). (Note: didn't vote on your post)

Re: Stockfighter is live

#109
post #49

Earlier quoted context omitted.

Thomas and I have a running gag about this. Rails is holding up admirably. You can still actually see the website. Our problem is presently that one player implies 1+ ruby (not Rails) processes running bots and doing orchestration for their levels, and that has pegged the CPU on all of our GM boxes and also, possibly, saturated their network links as they hit the venue with... I don't actually know how many orders ha…

> Rails is holding up admirably. ... except that you have to spin up more boxes. I think you have a different definition of "admirably" than most of us :-) Follow Twitter's lead and switch to a JVM-based solution when you get a chance, you'll be shocked.

We have one Rails box w/ ~2 gigs of RAM which has been sitting pretty since the golang process also on the box stopped hogging 100% of the available file descriptors. Our scaling issue is with ruby processes, of which we have several thousand active at the moment. Each process runs one wee little universe, filled with wee little traders trading wee little stocks, for the benefit of a single player playing a single level.

These aren't a JVM language (or Golang, for that matter) out of expediency: I had to write the economic simulation and the trading algorithms and get it done in about ~2 weeks, so I wrote them in my best language, Ruby.

Re: Stockfighter is live

#110
post #78
post #56

Earlier quoted context omitted.

I know using Rails isn't as popular here as it once was, but in my experience, if you cache correctly (like you should), it's trivial to scale.

Modestly less trivial if you happen to put your chat server on the box with Rails because Rails is certainly not going to fall over and your chat server attempts to open several thousand websockets on a box with a not-too-generous number of open file descriptors, it appears.

I feel like a chat server is something best served by something not in your stack (especially Rails). I surprised you chose to do it in house. How about using https://pusher.com/ or https://www.firebase.com/ ?
Post reply on HN