4 ms·

I've been using Thredded for years now on a relatively popular site (~250k users on Notebook.ai; our instance at https://www.notebook.ai/forum https://www.noteb

I've been using Thredded for years now on a relatively popular site (~250k users on Notebook.ai; our instance at https://www.notebook.ai/forum https://www.notebook.ai/forum) and have been extremely happy with its performance, scaling, and featureset. The devs behind it are super smart and care about code quality. Would definitely recommend if you need a drop-in discussion engine for your Rails app.

nickjj 5y ago
How much caching are you doing and what are the CPU / memory / disk specs of you server if you don't mind me asking? I ping 15ms to your server but page load times are 500-600ms on most threads (10 or 3,000 replies doesn't make a difference). This is checking out the Rails app server response in dev tools.
- drusepth 5y ago
  Page load times around the site are probably pretty high because I don't do any caching (or, really, prioritize load speed in code), but right now I'm scaling between 1-4 of the $250/mo Performance-M dynos on Heroku (2.5GB RAM but other specs are hand-wavy) whenever my p95 goes above 1000ms. I have had some occasional backend issues in the bigger threads from things like notifying all users of responses in a 20k-post thread, but I think that's more on me for not having anything to scale up more workers as needed. In general though, most things Just Work.
  - nickjj 5y ago
    Thanks, that's impressive and exactly what I was hoping to see. Pretty much zero effort into making it faster but it's still decently fast and could probably get literally 10x faster if you wanted to cache a few things. Also surprisingly not that much RAM usage. Are you using Sidekiq too where this is included in the number of dynos you run? What's neat is (and I'm not recommend switching) it sounds like you could host a massively popular forum and throw it onto a single $48 / month DigitalOcean server with 8GB of memory and 4 CPU cores if you wanted to. I get wanting to use Heroku but for folks who are ok with self hosting that's really affordable for such a popular site that has quite a lot of writes.
    - drusepth 5y ago
      Thanks! Glad the details are helpful. There's a lot of optimizations to be made on my end, for sure. I isolate Sidekiq to a separate worker dyno (a shared Standard-2X dyno with 1GB RAM for $50/mo) and typically run just 1, but up it to 2 if I ever notice a backlog of jobs that need done. Most of the main dynos's RAM needs are for the main site outside of the forums, which is way more resource-intensive. On Heroku: I'm admittedly very terrible with devops and their UI has made it really easy to scale resources for viral shares without the pressure being on me to figure out how to scale properly (and their support has been super helpful in cases where the DB failed, certs expired, etc). Thredded itself hasn't really required much resource scaling, so Heroku's probably overkill for it unless the rest of your app needs it. :)
  - e12e 5y ago
    Having just added some fragment caching as well as cache headers (basically cache do...end around view fragments and some fresh_when in controllers) - at a glance it looks like there's a lot of low-hanging fruit for increasing performance in the thredded code-base. The project i adjusted was an old rails 3.2 code base, and in addition to fixing some missing db indeces - the caching sped things up significantly (10-100x, from atrocious to acceptable). I sometimes get the feeling that no-one using rails ever read the cache section in the guide. https://guides.rubyonrails.org/caching_with_rails.html https://guides.rubyonrails.org/caching_with_rails.html Caveat: there may be callbacks and authorization hooks in thredded that hamper this approach in practice. For a new project i would probably try and go with "fresh when" (http caching) and varnish or fastly.com in front. But fragment caching can make a lot of difference too. More than I expected. Ed: although I can see why it might be missing - the upstream demo feels plenty snappy - so for most uses, extra caching might just be extra complexity for little gain.
- ksec 5y ago
  I was expecting a much much faster site. Instead I thought the site was really slow. StackOverflow manages sub 20ms response on nearly all pages time with zero caching. While I dont expect Ruby Rails to ever achieve that performance, 500ms response time is just painful. The bar needs to be far higher. Even for non-caching web site. ( May be I got too used to HN's speed )
  - nickjj 5y ago
    Personally if it were my site I would put in some time to cache a few things. Rails makes this fairly easy with https://guides.rubyonrails.org/caching_with_rails.html https://guides.rubyonrails.org/caching_with_rails.html. I say "fairly" because caching is never really easy because of what could go wrong but I would say this is as realistically easy as it can get with Rails. A cold page load on any old StackOverflow answer page is about 50ms for me. Keep in mind the hosting environments between both sites too. The forum site is on Heroku. StackOverflow is running on https://stackexchange.com/performance https://stackexchange.com/performance, basically hundreds of CPU cores and multiple terrabytes of RAM on dedicated hardware. There's no doubt .NET is going to crush Ruby even with the same hardware tho. > StackOverflow manages sub 20ms response on nearly all pages time with zero caching I'm not sure where you read they don't cache anything? They cache a lot of things. They have an in depth article on this at https://nickcraver.com/blog/2019/08/06/stack-overflow-how-we-do-app-caching https://nickcraver.com/blog/2019/08/06/stack-overflow-how-we.... They're also serving a lot from a CDN to give end to end low latency responses across the globe.
    - ksec 5y ago
      The 20ms is straight form the Stackexchange Performance page in your link, at the bottom of the page. That is server response time. I assume your 50ms is with latency, and paint delay included? They only cache static asset like images, they dont cache page in CDN. [1] There is probably a better tweet which I cant find right now, but they dont cache page on their server either, every thing is generated on demand. [2] StackOverflow is quite famous for not doing any cache and dont use CDN. HN doesn't use CDN either and uses minimal cache ( for non-logged in users ). But yes the hardware is quite far apart. My opinion is that I dont think we should settle for 500ms response time as acceptable. But then it is quite costly on Heroku...... [1] https://twitter.com/Nick_Craver/status/1318296453266231297 https://twitter.com/Nick_Craver/status/1318296453266231297 [2] https://twitter.com/Nick_Craver/status/1410549840493350915 https://twitter.com/Nick_Craver/status/1410549840493350915

nickjj 5y ago

How much caching are you doing and what are the CPU / memory / disk specs of you server if you don't mind me asking? I ping 15ms to your server but page load times are 500-600ms on most threads (10 or 3,000 replies doesn't make a difference). This is checking out the Rails app server response in dev tools.

drusepth 5y ago
Page load times around the site are probably pretty high because I don't do any caching (or, really, prioritize load speed in code), but right now I'm scaling between 1-4 of the $250/mo Performance-M dynos on Heroku (2.5GB RAM but other specs are hand-wavy) whenever my p95 goes above 1000ms. I have had some occasional backend issues in the bigger threads from things like notifying all users of responses in a 20k-post thread, but I think that's more on me for not having anything to scale up more workers as needed. In general though, most things Just Work.
- nickjj 5y ago
  Thanks, that's impressive and exactly what I was hoping to see. Pretty much zero effort into making it faster but it's still decently fast and could probably get literally 10x faster if you wanted to cache a few things. Also surprisingly not that much RAM usage. Are you using Sidekiq too where this is included in the number of dynos you run? What's neat is (and I'm not recommend switching) it sounds like you could host a massively popular forum and throw it onto a single $48 / month DigitalOcean server with 8GB of memory and 4 CPU cores if you wanted to. I get wanting to use Heroku but for folks who are ok with self hosting that's really affordable for such a popular site that has quite a lot of writes.
  - drusepth 5y ago
    Thanks! Glad the details are helpful. There's a lot of optimizations to be made on my end, for sure. I isolate Sidekiq to a separate worker dyno (a shared Standard-2X dyno with 1GB RAM for $50/mo) and typically run just 1, but up it to 2 if I ever notice a backlog of jobs that need done. Most of the main dynos's RAM needs are for the main site outside of the forums, which is way more resource-intensive. On Heroku: I'm admittedly very terrible with devops and their UI has made it really easy to scale resources for viral shares without the pressure being on me to figure out how to scale properly (and their support has been super helpful in cases where the DB failed, certs expired, etc). Thredded itself hasn't really required much resource scaling, so Heroku's probably overkill for it unless the rest of your app needs it. :)
- e12e 5y ago
  Having just added some fragment caching as well as cache headers (basically cache do...end around view fragments and some fresh_when in controllers) - at a glance it looks like there's a lot of low-hanging fruit for increasing performance in the thredded code-base. The project i adjusted was an old rails 3.2 code base, and in addition to fixing some missing db indeces - the caching sped things up significantly (10-100x, from atrocious to acceptable). I sometimes get the feeling that no-one using rails ever read the cache section in the guide. https://guides.rubyonrails.org/caching_with_rails.html https://guides.rubyonrails.org/caching_with_rails.html Caveat: there may be callbacks and authorization hooks in thredded that hamper this approach in practice. For a new project i would probably try and go with "fresh when" (http caching) and varnish or fastly.com in front. But fragment caching can make a lot of difference too. More than I expected. Ed: although I can see why it might be missing - the upstream demo feels plenty snappy - so for most uses, extra caching might just be extra complexity for little gain.
ksec 5y ago
I was expecting a much much faster site. Instead I thought the site was really slow. StackOverflow manages sub 20ms response on nearly all pages time with zero caching. While I dont expect Ruby Rails to ever achieve that performance, 500ms response time is just painful. The bar needs to be far higher. Even for non-caching web site. ( May be I got too used to HN's speed )
- nickjj 5y ago
  Personally if it were my site I would put in some time to cache a few things. Rails makes this fairly easy with https://guides.rubyonrails.org/caching_with_rails.html https://guides.rubyonrails.org/caching_with_rails.html. I say "fairly" because caching is never really easy because of what could go wrong but I would say this is as realistically easy as it can get with Rails. A cold page load on any old StackOverflow answer page is about 50ms for me. Keep in mind the hosting environments between both sites too. The forum site is on Heroku. StackOverflow is running on https://stackexchange.com/performance https://stackexchange.com/performance, basically hundreds of CPU cores and multiple terrabytes of RAM on dedicated hardware. There's no doubt .NET is going to crush Ruby even with the same hardware tho. > StackOverflow manages sub 20ms response on nearly all pages time with zero caching I'm not sure where you read they don't cache anything? They cache a lot of things. They have an in depth article on this at https://nickcraver.com/blog/2019/08/06/stack-overflow-how-we-do-app-caching https://nickcraver.com/blog/2019/08/06/stack-overflow-how-we.... They're also serving a lot from a CDN to give end to end low latency responses across the globe.
  - ksec 5y ago
    The 20ms is straight form the Stackexchange Performance page in your link, at the bottom of the page. That is server response time. I assume your 50ms is with latency, and paint delay included? They only cache static asset like images, they dont cache page in CDN. [1] There is probably a better tweet which I cant find right now, but they dont cache page on their server either, every thing is generated on demand. [2] StackOverflow is quite famous for not doing any cache and dont use CDN. HN doesn't use CDN either and uses minimal cache ( for non-logged in users ). But yes the hardware is quite far apart. My opinion is that I dont think we should settle for 500ms response time as acceptable. But then it is quite costly on Heroku...... [1] https://twitter.com/Nick_Craver/status/1318296453266231297 https://twitter.com/Nick_Craver/status/1318296453266231297 [2] https://twitter.com/Nick_Craver/status/1410549840493350915 https://twitter.com/Nick_Craver/status/1410549840493350915