4 ms·

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 b

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.

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.