|
|
|
|
|
by pdimitar
1329 days ago
|
|
I did read the article. One of the incidents was about their webhook worker(s) being swamped -- plus had errors due to deleted DB workloads that were necessary for the event to be processed. So I'd count that one as a slow endpoint attributed to Ruby on Rails (and it's famous for that). And even if zero of their incidents alluded to performance problems with Rails I still worked a lot with it and I know for a fact that it's a factor. Your snark doesn't change reality but you are free to pretend otherwise, fine with me. > Also have you considered that if you had weekly outage when billion dollars companies continued to stick with Rails, maybe you were the problem? Indeed, a programmer not having executive powers to influence change of deployment tech and server (was Puma at the time) is indeed me being a problem, surely. Especially after he made a study demonstrating the problems and calculated how much programmer time is wasted on these matters every week and he still got ignored. Perhaps I am the problem indeed! |
|
That's a capacity problem caused by a logic bug. Nothing stack specific. If you throw more work at a system than it is designed to handle, you'll hit a bottleneck.
> Your snark doesn't change reality
What reality? You are just barking your uneducated opinion. No one who ever worked on a service anywhere close to the scale of GitHub (regardless of the stack) would make such statements.