The documentation says 2 cores and 2GB RAM are the minimum requirements for configuring the FOREM selfhost.
I would like to get an approximate understanding of how many users does this minimum configuration support.. and what is the hardware configuration being used for the https://dev.to.
thanks.
Top comments (15)
DEV currently runs on a configuration which uses ~6GB of RAM I believe on Heroku, which is probably more than we need, but good to use a buffer.
DEV does make use of Fastly as a caching layer which self-hosters don't have configured by default but could use (though we mostly consider this the DEV story)....
Ultimately Forem is quite efficient and battle tested, but we don't have an exact apples-to-apples comparison in all the different scenarios due to us trying new things with Forem. We will build up more of a shared knowledge base of different scenarios, but no really great answers.
When you account for all Heroku dynos combined on DEV, we have 33GB of total RAM capacity available to the app (40GB total at the hardware). We only use about 12GB of that, though.
That that's only part of the story, though. If we're comparing with Forem selfhost, that configuration runs the entire stack on the same box:
If DEV used this configuration in production, it would require a machine with well over 300GB of RAM.
@jamie would you be able to mention the approximate number of dynos as well.. or the number of workers employed on rails server to serve this many users..
this statement has confused me.
If we have different servers for each service, we allocate 2 GB RAM for each VM, it adds up to 12 GB.
If we have all the services in one VM, I was thinking that the idle RAM is better utilized and either 6 or 8 GB may be enough.
We use a total of 16 Puma processes across 2 PL dynos with a total of over 100 Puma threads. Sidekiq workers run 2 Sidekiq processes across 2 PM dynos with a total of 30 Sidekiq threads.
Most Forem instances should indeed run everything on the same box for precisely that reason. There is significant overhead per machine and performance-per-dollar decreases once you scale beyond a single machine, so until you need more capacity than a single machine can feasibly provide, you should absolutely stick to that single machine.
However, DEV is well beyond that threshold. We serve more traffic than Hacker News, so it's more cost-effective at our scale to spread across multiple machines and delegate things like Postgres and Redis to cloud services that specialize in running them. If there's an outage, downtime is measured in seconds to minutes, whereas if we put everything on a single box to save infrastructure costs, downtime would easily be 8-24 hours. It would take weeks or months to recover from the SEO penalty of that downtime and, most importantly, the hot takes on Twitter would be devastating. 😄
@jamie thank you very much for the excellent clarification.
I am planning to use cloudflare free plan as CDN to reduce the load on server.
Any insights on why I should or should not use cloudflare..
We use Fastly on DEV and there is more built-in logic for really caching in that way. All in all It's your best bet for max scalability given the custom support in the Forem code.
^^ This. The only currently supported caching reverse proxies are Fastly and Nginx. The Forem Self-Host configuration uses OpenResty, which is built on Nginx, so even though you won't have the points of presence that a proper CDN would provide (which often has a low cache hit rate anyway without a large quantity of traffic), you'll still get solid caching on top of the layers of application-level caching we do.
Are you currently seeing traffic volume that would require looking into a CDN?
Not yet :) just preparing for the future.
I tried a website killer app few days ago on my website url, which was hosted with 2 core 4 GB RAM on GCP.. the response times are approximately as below:
5 concurrent users - 1 sec
100 concurrent users - 2 sec
200 concurrent users - 4 sec
800 concurrent users - 50 sec
100 concurrent users itself is a huge traffic, which the website can hold good, proved by the test.
But if someone else uses similar tools and continuously attack the website, there is no protection,
Even the cloud security mechanisms did not intercept the attack; and the website was not accessible from other devices during the attack.
That's why hoping that cloudflare or any other CDN may be able to effortlessly serve the cached static content to such attackers and keep the website up for real users.
Thank you for the reply. Could you please mention the number of vcpus / cores / dynos as well? and the number of instances..
Among the vertical scaling (increasing the number of vcpus on one instance) and the horizontal scaling (increasing the number of small instances and deploying a load balancer), which method works better for forem?
Asking this because of the puma clustering implemented in Forem.
Fastly is costly while Cloudflare has a free plan. Any insights on forem's compatibility with Cloudflare?
After embedding few youtube videos in posts with liquid tag ..
the RAM usage went upto 3GB.
I was thinking that embedding youtube videos and playing them on our website should not affect our server resources.
Is my understanding correct? or is there something we are doing differently in Forem?
Yes, this is correct. I don't know why this would spike RAM. @maestromac @jamie any thoughts on this?
Checking…
@9comindia I can't reproduce this by embedding a YouTube video. I created a post with one in it (from the Forem Liquid Tags docs) and spammed requests on it but memory usage is staying steady in the range of 360-380MB in my web process.
Are you able to reproduce this in a way that highlights the memory usage?
As all the services are residing in one vm, may be the spike is caused by any of the other processes. I'll try to isolate the issue, reproduce and get back to you. thank you very much.
Yeah, this seems unlikely related to youtube specifically. But maybe something going on with liquid tags in general?