저희는 500만 개의 게시물을 보유하고 있으며 검색 속도가 꽤 빠릅니다. 2.8GHz Xeon E5-2680의 6개 공유 v코어, 16GB RAM, SSD 스토리지를 갖춘 환경에서 호스팅하고 있습니다. 다만 사용자들이 동시에 게시물을 생성하는 횟수에 대한 메트릭은 가지고 있지 않아, 잠금(locking) 문제가 있을 수 있습니다.
반면에 게시물 작성은 종종 꽤 느립니다. 게시물이 처리되는 데 6~7초가 걸릴 수 있습니다. Discourse는 이러한 처리를 비차단(non-blocking) 방식으로 수행하므로 사용자 경험에 치명적인 영향을 주지는 않습니다.
이건… 정상적인 상황이 아닙니다.
100개나 1000개 이상의 게시글이 있는 주제라면 대부분 이런 경우가 아닐까 싶습니다. 짧은 주제에서는 이런 일이 일어나지 않아야 합니다.
@Wingtip의 포럼에는 매우 긴 주제들이 정말 많았던 것으로 기억합니다.
네, 저희는 확실히 하고 있습니다.
6~7초의 게시 시간이 메가 토픽에 특화된 건가요? 100개의 답글이 있는 토픽에 답글을 달면 이 경우에도 6~7초가 걸리나요?
방금 테스트를 해봤는데 재현이 안 됐어요. 게시글 등록이 간헐적으로 느려지는 현상이 발생하고 있거든요. 스레드 내 게시글 수와 상관관계가 있는 것 같지는 않아요. 다른 사용자가 동시에 게시글을 등록할 때 발생하는 잠금(locking) 문제일 수도 있고요.
7개 게시글 = 매우 빠름, 여기 메타(meta) 사이트와 거의 동일한 속도
500개 게시글 = 약간 더 느릴 수 있음, 너무 나쁘지는 않음. 약 1.5초 정도?
16,000개 게시글 = 500개일 때와 거의 동일한 것으로 보임
그리고 많은 사람들이 메가 토픽에 동시에 접근하면 대기열에 쌓인 요청으로 인해 PG 서버 전체가 느려져 성능에도 영향을 미친다고 생각합니다.
그렇게 하는 것이 합리적입니다. 스레드를 보는 다수의 경험을 우선시하고, 게시글을 작성하려는 1~2명의 사용자는 그다음으로 고려하라는 뜻이니까요.
이를 활성화하면 전체 성능에 얼마나 큰 영향을 미치나요? 그리고 사이트 재빌드 없이 활성화할 수 있나요? Postgres 12 변경 이후로 재빌드가 성공한 적이 없었습니다. pg10으로 유지하도록 설정해도 마찬가지입니다.
app.yml 파일에서 개발자 이메일로 이메일 주소를 설정해야 합니다. 컨테이너를 종료하고 다시 시작하면 재빌드 없이 적용할 수 있습니다. discourse docker를 사용하여 업그레이드하는 등 컨테이너에 변경 사항을 가했다면 해당 변경 사항은 사라집니다.
컨테이너 내부의 config/discourse conf를 편집한 다음
sv restart unicorn
을 실행할 수도 있습니다.
재빌드가 실패하고 있는 상황에서, 컨테이너를 삭제하면 완전히 문제가 생길까 봐 걱정됩니다. 어제 pg12 업그레이드를 시도하면서 너무 많은 오류가 발생해서, 사이트가 장기간 다운되지 않을 것이라는 확신이 들기까지는 변경 작업을 진행하기가 꺼려집니다.
음, 공짜 조언은 그 가치를 알아주는 것이지만, 꽤 안전하다고 볼 수 있습니다.
cd /var/discourse
./launcher enter app
vi config/discourse.conf
# vi에서 developer_emails 줄을 찾아 이메일 주소를 추가하고 vi를 종료합니다
sv unicorn restart
# 웹 서버가 재시작되고 페이지 서빙을 시작하기까지 30~90초 동안 패닉 상태가 됩니다
이렇게 하더라도 문제를 일으킬 수 있습니다. 그 설정 파일을 잘못 수정하면 discourse가 시작되지 않을 수 있다고 생각합니다.
sv restart unicorn은 작동했지만, sv unicorn restart는 작동하지 않았습니다.
이런 뒤집힌 표현을 3분의 1 정도는 쓰게 돼요. 
그래도 개선된 거예요. 예전에는 절반은 틀리곤 했으니까요.
이게 필요하신 내용인가요? 16,000개의 게시물이 있는 스레드에 게시한 것입니다. 이는 일반적인 게시 시간으로, 특별히 느리지는 않았습니다.
전체 출력 결과는 다음과 같습니다:
https://paste.mozilla.org/f5nJrPag
app/models/user_stat.rb:159의 update_topic_reply_count에서 발생한 2초짜리 쿼리입니다.
즉, @riking이 현재 작업 중인 내용과 정확히 일치합니다.
좋아요! 게시 시간의 실질적인 개선은 사용자를 정말 만족시킬 것입니다. 현재 가장 많이 불만사항이 제기되고 있는 부분이니까요. 물론 곧 다른 불만거리도 찾아내겠지만요.
좀 위로가 된다면, 나도 그 쿼리에 대해 불만을 제기했어요. 여기 메타에 읽기 상태(read state)가 너무 많거든요. 모든 답글마다 쓸데없이 개수를 세는 작업을 하고 있거든요…
다른 소프트웨어에서 테스트로 가져온 항목 중 20만 개가 조금 넘는 게시글이 있는 주제가 있었는데, 저는 거기에 게시글을 작성하는 데 아무 문제가 없었습니다. 따라서 중요한 것은 주제 자체의 크기가 아니라, 게시글을 작성하는 사용자일 것입니다.
