Update on forums

Part 2 & Alumni (2018)
1

It turns out that there are a couple of important settings to tune in Discourse (our forum software):

  • Amount of memory reserved for DB shared buffers
  • Number of server processes to launch

The defaults are only suitable for really small servers, so although I upgraded the server it wasn’t able to take advantage of it. I’ve now set them to the levels recommended by the Discourse team and the forum seems snappy again :slight_smile: We won’t really know if it can handle the load of all the simultaneous connections during class until next Monday, but hopefully it’ll be OK now…

19 Likes
2

Thanks @jeremy

I found it was impossible to discover the link to the video because the forum itself was completely unresponsive. Is it possible to email the link to the international fellows so we don’t get stuck like this?

3

I’ll try to do that - although it’s always hard on a Monday evening to get everything done in time! I’ll also try to have a link posted earlier - i.e. an hour or so before class, so there’s plenty of time to access it and without the rush.

BTW the edited video will be available online in a few hours.

12 Likes
4

What about a “special session” one of the next days? A special hour in which we go over the basics of the first lesson and conclude it before lesson 2, so that the forums get stress tested! I think it’s doable :smiley:

5

Thanks for bringing this back online. :clap:

was about to ask you yesterday, to increase the number for server(unicorn?) processes in use, since the server seemed quite beefy for not being able to handle ~ 600 users.

Seems all good now, but you might later want to look into

  • setting up a proxy(nginx) in front of discourse servers, if not already
  • setting up a cache(redis) server, if not already
  • allocate more memory to database instance (<- this most likely was the culprit yesterday)
  • setting up a cdn (fastly)
  • setting up ssl (let’s encrypt)
    (cdn+ssl could also possibly be mixed using cloudflare)
6

In fact the 504 errors where trow by nginx not because I guess discuss stoped working?

I thought it was a problem of a limit in nginx connections (because discuss seems like an ember app, and it opens some extra connections for pooling of data), so I guess there should be a tune parameter to check for long multiple connections in the side of nginx or discuss.

7

I’ve already allocated more mem to DB. Discourse is already behind nginx and using redis. I’m not sure that CDN will help much since static file serving isn’t a bottleneck (although I’m no expert on CDN use!)

I tried to set up let’s encrypt but got an unhelpful ‘something went wrong’ error from digital ocean, so I’ll leave that for now (it won’t help the load issue, obviously, so I’ll leave it until after the course).

1 Like
8

Not really - yes the nginx session timed out, but it’s because there wasn’t enough backend workers.

9

What about try to setup a little “event” so that people willing to check the forum load (before the next class)? just to double check.

10

:+1: More nginx backend workers/servers and more DB memory should do the trick. CDN+SSL def. wasn’t the issue yesterday. Let’s hope it goes all smooth for next Monday. :beers: