5 ms·

55 / 2.62 (millions of seconds in a month) ~= 20reqs / second That's not very impressive, you could achieve that easily on something deemed "slow" like Django

55 / 2.62 (millions of seconds in a month) ~= 20reqs / second That's not very impressive, you could achieve that easily on something deemed "slow" like Django or RoR But I guess your load is not constant. How many reqs/sec can it handle in the peak time?

jcelerier 5y ago
> 55 / 2.62 (millions of seconds in a month) ~= 20reqs / second I'm pretty sure Java 1.0 running on an Amiga could handle that...
- airhead969 5y ago
  I bet even 8051 + 10 Mb ISA 10BASE2.
- deleted 5y ago
  [deleted]
liveoneggs 5y ago
to be fair t3.medium is very small for a production deployment ($30/month on-demand) so I read this as having cycles to spare
atonse 5y ago
Yes it's not constant. We have a handful of bursts (tens of thousands of SMS conversations happening at 9am every day that complete in about an hour, for each SMS we send out, we get back 3 status callback webhooks from Twilio). And we've had a couple "mass" message sends where it did take a few hours to send 1.6 million messages. But again, that was due to our twilio limits and not elixir. We had to throttle our jobs when Twilio started saying their queue for our number was full. I just checked (because we now process most jobs in the background), we have gone as high as about 500 jobs per second in exq on that same machine (and each job typically runs anywhere from 5 to 15 SQL queries). The bottleneck is actually the size of our RDS instance. Not complaining about postgres, just saying elixir hasn't been the bottleneck for that amount. Every hour we process CSV files with 30,000 records, etc. We only started caching things about a month ago. I have been very lazy about that since it just didn't make any difference until recently. Again, the point I'm trying to make is that using elixir has been positively and utterly boring in the best way possible. No drama whatsoever. We've spent the overwhelming majority of any of the time related to this looking at postgres. Not even complaining about Postgres either, it's more a conversation of what's the right RDS size and IO for our traffic. This stack has caused us very little drama.

jcelerier 5y ago

> 55 / 2.62 (millions of seconds in a month) ~= 20reqs / second I'm pretty sure Java 1.0 running on an Amiga could handle that...

airhead969 5y ago
I bet even 8051 + 10 Mb ISA 10BASE2.
deleted 5y ago
[deleted]

liveoneggs 5y ago

to be fair t3.medium is very small for a production deployment ($30/month on-demand) so I read this as having cycles to spare

atonse 5y ago

Yes it's not constant. We have a handful of bursts (tens of thousands of SMS conversations happening at 9am every day that complete in about an hour, for each SMS we send out, we get back 3 status callback webhooks from Twilio). And we've had a couple "mass" message sends where it did take a few hours to send 1.6 million messages. But again, that was due to our twilio limits and not elixir. We had to throttle our jobs when Twilio started saying their queue for our number was full. I just checked (because we now process most jobs in the background), we have gone as high as about 500 jobs per second in exq on that same machine (and each job typically runs anywhere from 5 to 15 SQL queries). The bottleneck is actually the size of our RDS instance. Not complaining about postgres, just saying elixir hasn't been the bottleneck for that amount. Every hour we process CSV files with 30,000 records, etc. We only started caching things about a month ago. I have been very lazy about that since it just didn't make any difference until recently. Again, the point I'm trying to make is that using elixir has been positively and utterly boring in the best way possible. No drama whatsoever. We've spent the overwhelming majority of any of the time related to this looking at postgres. Not even complaining about Postgres either, it's more a conversation of what's the right RDS size and IO for our traffic. This stack has caused us very little drama.