4 ms·

>>> process about 2 million messages each month... >>> ... We run about 60 instances in production Seems like a very low efficiency in either the hardware or t

by fasteo 11y ago

>>> process about 2 million messages each month... >>> ... We run about 60 instances in production Seems like a very low efficiency in either the hardware or the software. We run a comparable service with roughly 2 million messages per day in a 6 server dedicated cluster.

Loic 11y ago
60 servers for less than one message per second. I suppose they do something important and CPU intensive with each message.
dantiberian 11y ago
Agreed, that stuck out to me too 2,000,000 / 30 / 24 / 60 / 60 = 0.7 requests/second/cluster. However it's probably worth extending them the benefit of the doubt, there may be other factors that they didn't cover.
- fasteo 11y ago
  Yes, that's also my feeling. They mention ElasticSearch; this alone can consume several servers but, again, storing 2 million/messages per month plus associated data in ElasticSearch does not explain that many production instances.
- count 11y ago
  Is your message handling a linear deal over the month? They may process 1.5M of those in the last 8 hours of the day, which would be 3750 requests a second instead...
  - thwarted 11y ago
    I'm not sure how you arrived at this 3750 per second number. Processing 1.5 million messages for ⅓ of the time (1500000 messages / 30d / 8h / 60m / 60s) is an average of 1.7361 messages per second during those 8 hours per day. If the remaining 500k messages were spread evenly over the remaining 16 hours a day for a month, that's an average of 0.963 messages per second ((((500000 / 30 / 8 / 60 / 60 )×2)+1.7361)/3) over the entire month. Even if you were to process 1.5million messages during the last 8 hours of the month, that is only 52.08 ( 1500000 messages / 8h / 60m / 60s ) messages per second during that 8 hour period.
    - count 11y ago
      I, uh, don't know how I got that either (must have fat fingered in calc). I was talking about all in one 8 hour deal though. Thanks for the clarification.
ianlevesque 11y ago
From the article: > Our main API is backed by Rails (messages, authentication and authorization). There are a lot of reasons to run rails, but pure efficiency per request is not one of them. I'm sure they could replace their bottlenecks later as needed.

by fasteo 11y ago

Loic 11y ago

60 servers for less than one message per second. I suppose they do something important and CPU intensive with each message.

dantiberian 11y ago

Agreed, that stuck out to me too 2,000,000 / 30 / 24 / 60 / 60 = 0.7 requests/second/cluster. However it's probably worth extending them the benefit of the doubt, there may be other factors that they didn't cover.

fasteo 11y ago
Yes, that's also my feeling. They mention ElasticSearch; this alone can consume several servers but, again, storing 2 million/messages per month plus associated data in ElasticSearch does not explain that many production instances.
count 11y ago
Is your message handling a linear deal over the month? They may process 1.5M of those in the last 8 hours of the day, which would be 3750 requests a second instead...
- thwarted 11y ago
  I'm not sure how you arrived at this 3750 per second number. Processing 1.5 million messages for ⅓ of the time (1500000 messages / 30d / 8h / 60m / 60s) is an average of 1.7361 messages per second during those 8 hours per day. If the remaining 500k messages were spread evenly over the remaining 16 hours a day for a month, that's an average of 0.963 messages per second ((((500000 / 30 / 8 / 60 / 60 )×2)+1.7361)/3) over the entire month. Even if you were to process 1.5million messages during the last 8 hours of the month, that is only 52.08 ( 1500000 messages / 8h / 60m / 60s ) messages per second during that 8 hour period.
  - count 11y ago
    I, uh, don't know how I got that either (must have fat fingered in calc). I was talking about all in one 8 hour deal though. Thanks for the clarification.

ianlevesque 11y ago

From the article: > Our main API is backed by Rails (messages, authentication and authorization). There are a lot of reasons to run rails, but pure efficiency per request is not one of them. I'm sure they could replace their bottlenecks later as needed.