rake posts:rebake(이전 후 실행)와 같은 명령어가 있습니다.
포럼의 속도를 높이는 다른 명령어나 방법이 있을까요? RAM이 더 큰 호스팅으로 이전했는데 오히려 더 느려진 것 같습니다. 트래픽이 전혀 없을 때 측정해 보았지만, 용량(GB)이 늘어나도 도움이 되지 않았습니다. 링크를 따라 이동할 때 1~2초씩 걸리는 등 매우 느린 이유가 데이터베이스 최적화 명령어가 없어서 그런 건 아닌지 궁금합니다. 예를 들어 nodebb와 비교하면 다소 불만족스러운 수준입니다.
서버의 RAM을 변경했다면 메모리 설정을 조정하기 위해 discourse-setup을 다시 실행해야 합니다.
데이터베이스 크기는 어느 정도인가요? 이는 데이터 가져오기(import) 작업인지, 아니면 새로운 커뮤니티인지요? 프로세서 속도는 어떻게 되나요? 단일 코어 CPU 속도가 매우 중요합니다. 회전 디스크가 아닌 SSD를 사용 중이시죠?
RAM 2GB, vCPU 1개, SSD 60GB의 Lightsail 인스턴스를 테스트했습니다.
설정이 올바른 것 같습니다:
UNICORN_WORKERS: 4
db_shared_buffers: "256MB"
좀 더 자세히 설명해 주실 수 있나요?
Lightsail은 단순한 웹 앱과 웹사이트를 위해 실제로 설계되었습니다.
CPU 코어가 하나이므로 2개의 unicorn 워커를 사용할 수 있으며, shared_buffers는 최대 512MB까지 늘릴 수 있습니다. app.yml 파일에는 다음 주석이 포함되어야 합니다:
2GB인 경우 3~4개의 워커를, 1GB인 경우 2개의 워커만 권장합니다
즉, 권장 버퍼 크기의 절반을 사용하면서 워커 수는 두 배로 늘린 상태입니다.
Spinning discs는 SSD 이전의 기술로, 하드 드라이브 또는 HDD라고도 알려져 있습니다. Discourse에는 너무 느립니다.
이러한 설정은 일반적으로 discourse-setup 스크립트가 실행될 시점의 시스템 사양(CPU 코어 수, RAM 용량)에 따라 자동으로 설정됩니다. 서버 사양이 변경된 경우에도 스크립트를 다시 실행하는 것이 안전합니다.
두 코어가 있는 가장 저렴한 EC2에 투자하는 것이 훨씬 낫다는 말씀이신가요? (나중에 ELB와 결합할 수도 있고요?)
제가 볼 때, AWS의 모든 서버가 HDD가 아닌 것 같습니다.
AWS 인스턴스 유형에는 많은 차이가 있습니다. 일부는 EBS 기반 디스크를 사용하며, 이는 디스크 접근 시 네트워크를 통해 이루어지기 때문에 지연 시간이 높아집니다. 반면 일부는 빠른 로컬 NVMe 드라이브를 갖추고 있지만, 데이터가 영구적으로 저장되지 않습니다. 또한 Z와 C 인스턴스 유형 계열은 훨씬 더 빠른 데이터 처리 성능을 제공합니다.
그러나 이러한 구성은 모두 $5에 합리적인 성능을 제공하여 소규모 커뮤니티에 적합한 Digital Ocean 드롭렛보다 더 복잡하고 비용이 많이 듭니다. Digital Ocean은 $40의 CPU 최적화 옵션에서 상당히 빠른 CPU 성능을 제공합니다.
정확히 어떤 최적화 옵션을 말씀하시는 건가요?
참고로 제 질문은 명령어 자체에도 해당됩니다. 즉, 포스트를 최적화/재구축하거나 불필요한 파일을 삭제하는 등의 작업을 위해 어떤 명령어(예: “rake” rebake posts)를 실행해야 하는지 궁금합니다.
그런 건 없어요 
.
왜 속도를 높여주는 비밀 명령어가 있겠습니까? 어째서 기본 모드가 느린 상태로 되어 있겠습니까?
성능 문제를 겪고 계신다면 확실한 데이터를 제시해 주셔야 합니다. 어떤 경로가 느린지, 커뮤니티 규모는 어느 정도인지, 데이터베이스 크기는 얼마인지, 모든 플러그인과 테마를 제거해 봤는지, $5짜리 DO 드롭렛에서 실행해 봤는지 등을 알려주세요.
이미 비슷한 사례가 있습니다 
누구를 탓하려는 의도는 없어요. 특히 제가 직접 확인해 보지도 않았고, postgres 인스턴스나 설정 같은 부분은 더더욱 그렇죠… 하지만 discourse는 정말 느립니다. 그 원인이 무엇인지는 정확히 모르겠지만, ruby ORM도 어느 정도 영향을 줄 것 같네요.
물론 더 큰 하드웨어를 추가하거나, SSD를 더 달거나, RAM을 늘리는 방법도 있습니다… 다만 어느 정도 한계는 있죠. 하지만 근본적인 문제는 변하지 않습니다: discourse는 꽤 요구 사양이 높고 느리거든요. 아주 작은 규모의 설치라도 상당한 성능의 호스트가 필요합니다.
정말인가요? 수치로 뒷받침해 주실 수 있을까요?
무엇과 비교해서, 어떤 상황에서 느리다는 건가요?
Meta는 느리다고 보시나요?
나는 이 주장에 정말로 동의하지 않는다. $5짜리 VPS로 운영되는 수많은 소규모 커뮤니티를 알고 있다. 느린 Discourse 설치 환경은 일반적으로 호스트 선택의 문제나 잘못된 구성을 나타낸다.
Discourse는 웹사이트가 아니라 애플리케이션이라는 점을 기억해라. 브라우저에 로드된 후에는 오고가는 데이터량이 극히 적다.
여기서 지원하는 유일한 설치 방식인 표준 설치 가이드를 따랐다면, CPU/RAM 튜닝은 모두 자동으로 수행된다. 여기서는 어떤 예시나 비교 자료도 제공하지 않았다. 구체적인 내용을 제공해 줄 것을 강력히 권고한다.
벤치마크를 몇 가지 돌려볼 수는 있겠네요. 저는 $5짜리 가상화 환경에서 돌리고 있는데, 요즘 기준으로 보면 정말 최소한의 하드웨어라는 점은 잘 알고 있습니다. 그리고 다른 포럼 솔루션과 비교한 건 아니지만, 도커 컨테이너 안에서 가상화 환경으로 실행하더라도 포스트그레SQL이 얼마나 처리하고 제공할 수 있는지 잘 알고 있습니다. 데이터베이스 개발 경력으로 거의 20년 가까이 됐거든요.
음, 음, "지난 세기의 하드웨어, 즉 스피닝 드라이브를 쓰고 있냐"는 식의 태도에 살짝 자극을 받은 건 사실입니다 
"디스코스는 더 단순한 시스템보다 요구 사양이 높다"로 표현을 바꾸겠습니다.
댓글이 좀 너무 가혹했네요. 동의합니다. 위에 내용 참고하세요.
잘못된 구성(misconfiguration)이라는 말이 무슨 뜻인지 설명해 주실 수 있나요. 그것은 깨끗한 포럼을 설치하고 최대 1~2개의 플러그인을 추가했을 때 실제로 잘못할 수 있는 것을 의미합니다. 어떤 구성을 말씀하시는 건가요?
@eextra 몇 가지 생각이 듭니다…
적절한 성능 수준을 어떻게 정의하시나요?
성능 저하가 발생하는 시나리오를 설명해 주세요.
디스코urs 플랫폼(또는 호스팅 환경)이 성능 저하의 원인임을, 그리고 데이터베이스가 병목 요인임을 어떻게 파악하셨나요?
시작점으로 webpagetest.org 링크를 몇 개 공유해 주시면 어떨까요?
기술적으로는 타당한 의견이지만, 커뮤니티 성장과 사용자 경험(UX) 측면에서는 핵심을 놓치고 있다고 생각합니다. 검색을 통해 우리 커뮤니티가 유치하는 트래픽의 양에 대해 할 말이 많습니다.
제 생각에는 해당 링크에 대한 첫 방문이 빠르게 로드되는 것이 중요합니다.
그렇습니다. NPN과 같은 자산이 많은 커뮤니티를 제외하면, 완료된 로딩 시간이 2초를 초과하는 Discourse 커뮤니티는 거의 보이지 않으며, DOMContentLoaded는 일반적으로 1000ms를 훨씬 밑돌고 있습니다.
WebPageTest는 형편없는 지표입니다. 브라우저를 열고 페이지 소스를 검사한 후 네트워크 탭으로 전환하세요. 캐시를 비우고 강제 하드 리로드를 실행하면 모든 수치가 바로 눈앞에 나타납니다.
문제가 있다고 주장하고 계시지만, 그 어떤 예시도 제시하지 않고 있습니다. 이러한 주장을 뒷받침할 수 있다면 정말 좋겠습니다.
WebPageTest는 시작점으로 사용하거나, 원한다면 특정 시나리오(OS, 위치, 대역폭, 지연 시간)를 더 깊이 파고들 때 사용할 수 있는 완전히 유효한 도구입니다. 또한 제어된 시나리오의 결과를 다른 사람들이 볼 수 있도록 공유하는 편리한 방법이기도 합니다.
네트워크 탭도 유효한 방법이지만, 이것이 문자 그대로 '당신’의 경험, 즉 당신이 사용하는 데스크톱과 현재 연결된 네트워크 환경에서의 경험임을 이해해야 합니다. 이는 좋은 검증 수단이며 몇 초밖에 걸리지 않지만, 방문자를 위해 최적화해야 할 내용을 제공해 주지 않을 수도 있습니다.
두 방법 모두 장점이 있습니다. 어느 쪽도 '끔찍한 지표’가 아닙니다.
@eextra 관리자 권한으로 discourse에 로그인할 때 응답 시간 카운터가 표시되도록 설정해 두는 것도 언급할 가치가 있습니다. 또한 관리자 패널을 통해 NGINX 성능 보고서를 기록할 수도 있습니다.
웹사이트 속도 테스트 사이트가 그렇게 나쁜 건가요?
이런 사이트들을 자주 사용하면서 유용하게 느끼고 있어서 제 생각을 좀 나누고 싶었습니다. 특히 여러 위치에서 여러 번 테스트를 실행하는 사이트들이요.
100~200ms 수준의 최적화 관련해서는 브라우저와 테스트 사이트 간에 결과가 다르게 나오는 경우가 있는데, 그보다 큰 시간대에서는 정확도가 높아 보입니다.
때로는 웹사이트 속도 테스트 사이트들의 만족도를 높이는 최적화를 선택하기도 합니다. 모든 사이트가 비슷한 측정값을 보고한다면 구글도 마찬가지일 거라고 추측하기 때문이죠. 물론 구글의 알고리즘이 비공개되어 있어 제 추측이 틀릴 수도 있습니다.
Ruby는 악명 높게 느린 언어이고, Discourse는 방대한 양의 JavaScript를 사용하며, Discourse 포럼의 초기 로딩 시간이 길고 모바일 속도가 좋지 않다는 점은 논쟁의 여지가 없습니다. 적절한 하드웨어만 있으면 뛰어난 속도 결과를 얻을 수 있다는 말은 사실과 다르다고 생각합니다. 지금 메타(Meta)를 접속해서 보고 있는데, Go로 작성된 포럼과 비교하면 확실히 느리거든요. ㅋㅋ. 저는 Discourse가 잘 작동하고, 스팸 방지 기능이 뛰어나며, 기능도 훌륭하고 유지보수가 쉬워서 사용하고 있습니다. 다만 Discourse가 빠르다고 생각해본 적은 없으며, 대부분의 포럼 방문자들도 구글 검색 결과의 첫 번째 링크를 클릭해 사이트를 방문할 때 이를 "앱"으로 인식하지 않습니다.