[fixxer]

16k requests per second is not fast if you're talking about fetching a page or doing a minimal amount of I/O.

16k requests per second is worth writing about if you're talking about a process with substantial side effects (S3 I/O).

[vidarh]

If the language implementation is an issue when doing this, you're doing something wrong.

I'm working on a contract doing this exact thing at the moment, and unsurprisingly the Ruby code that's in the picture is responsible for just a tiny little fraction of the overall latency.

You should spend most of the time waiting on S3, pretty much no matter what language you choose. If you don't, it's not the fault of whichever language you use.

In fact, S3 performance is so dominant in this type of scenario if you do things properly, that if you want to optimize for speed and can afford to risk data loss (or in our case, the clients poll for confirmation and re-upload data in the rare event of loss), it's generally proving substantially better to write to local disk and do uploading to S3 in the background.

[mstump]

It's just pass through. The limit in this instance is probably packets per second of the legacy AWS network. Why is this difficult?

[fixxer]

Read the analysis. First attempt was "just a pass through".

[mstump]

No, it is just pass through, they just did a crappy job of handling concurrency.

[fixxer]

Maybe they should hire somebody smart like you.

[threeseed]

Where did this come from ?

They DID do a crappy job at concurrency and it's fair enough to admit it. It's not personal sometimes it takes a few iterations to get to the right solution.

[fixxer]

The final version was crappy? How would it be better?

[mstump]

To be snide, maybe they should, I am an expert in this topic this is what I do all day every day.

They're doing development without understanding how computers work, where the bottlenecks are, or what the maximum theoretical throughput for the use-case is. They ended up with something slightly better than the horrible situation they were in, and are celebrating a inefficient solution as a technical triumph.

[fixxer]

> inefficient solution as a technical triumph

They were able to solve their problem in a single process balanced over 4 boxes without ever having to hire someone like you, despite your expertise.

Could they have increased throughput? Absolutely. It would have involved a different architecture with more complexity & time, and it also would have relied on skills beyond what was immediately available. I'm guessing their line count is around ~200 for the core functionality.

Can you share some actual technical points where they made an error? I would really like to see you demonstrate expertise beyond these uninspiring generalities.

[ignoramous]

Genuine question, as I was wondering about what an alternative architecture would look like from a systems perspective.

Would something like NodeJs+clusters (or any evented IO framework) be a better fit (considering the clusters are stateless, and don't have to talk to eachother)?

If we're talking concurrency/parallelism, would you prefer JVM+Threads/Erlang+Actors over Go? Thanks.