우리는 #Announcements 카테고리를 운영하고 있으며, 모든 회원은 이 카테고리의 첫 번째 게시글을 자동으로 구독하게 됩니다.
이를 통해 해당 카테고리의 게시글을 특정 날짜와 시간에 맞춰 게시할 수 있습니다.
그 결과, 공지사항이 약 25,000명의 회원에게 이메일로 발송됩니다.
우리가 직면한 문제는 이메일 발송에 1시간 이상 걸린다는 점으로, 시간적 시의성이 중요한 공지사항에는 이상적인 상황이 아닙니다.
Sidekiq를 모니터링하면 “Scheduled” 카운터가 개별 이메일을 하나씩 쌓아 올리는 것을 볼 수 있으며, 약 20,000개에 도달하면 “Enqueued” 탭으로 이동한 뒤 마침내 발송이 시작됩니다.
이 과정을 조금이라도 빠르게 만들 수 있을까요? 
시간적 시의성이 중요한 이메일의 경우, 현재 속도보다 약 100배 빠르게 발송할 수 있으면 좋겠습니다 
이 토론이 도움이 될 수 있습니다. DISCOURSE_MAX_DIGESTS_ENQUEUED_PER_30_MINS_PER_SITE를 설정하는 방법을 설명하며, 이 설정은 다이제스트의 전역 제한을 정의합니다.
저는 오늘 저녁에 시간을 재어보았습니다.
18:30에 #Announcements 카테고리에 게시글을 게시하도록 예약했습니다.
18:40에는 Scheduled 큐에 15,000개의 이메일이 있었습니다.
게시글 작성 15분 후인 18:45에는 Scheduled 큐에 22,000개의 이메일이 있었습니다.
18:48경에 해당 이메일들이 점차 Enqueued 큐로 이동하기 시작했습니다:
18:51에도 여전히 이동 중이었습니다:
19:03에는 이메일들이 발송되는 중이었습니다:
19:10에는 남은 이메일이 10,000개뿐이었습니다:
19:27에는 남은 이메일이 569개뿐이었습니다:
그리고 19:29에는 모든 이메일이 발송되었습니다:
결국 22,000개의 이메일 알림을 보내는 데 1시간이 걸렸습니다.
여기서 병목 현상을 파악하는 데 도움을 주실 수 있을까요?
현재 시간당 22,000개라는 속도보다 이 이메일들을 더 빠르게 발송할 수 있기를 매우 희망합니다.
감으로 말하자면,
인프라 부하 문제일 수도 있잖아요?
여기서 두 가지 일이 동시에 일어나고 있습니다:
첫 번째 경우, 이 부분은 100% 확신은 없지만 email_time_window_mins 값을 낮추면 알림이 더 빨리 큐에 추가되는 것 같습니다.
이메일 작업이 scheduled 상태가 되면, 여러분의 Sidekiq 워커들이 작업을 하나씩 순서대로 처리합니다. Sidekiq 워커 수를 늘리면(서버 용량에 따라 DISCOURSE_SIDEKIQ_WORKERS를 5에서 10, 15 또는 20으로 상향 조정) 동시에 처리되는 작업이 많아져 큐가 2배/3배/4배 더 빨리 비워집니다.
백엔드가 가장 세부적인 부분에서 어떻게 작동하는지는 정확히 알지 못하지만, email_time_window_mins는 첫 번째 이메일이 발송되기 전의 지연 시간 설정일 뿐입니다. 이 시간 동안 이메일을 수신하도록 설정된 사용자는 해당 기간 내 활동한 적이 있으면 이메일을 "포기"할 수 있습니다(공식 용어: 이메일 스킵; 스킵 사유: 최근 활동 감지됨).
기본 지연 시간은 10분이며, 이는 게시물이 10분 동안 라이브 상태여야만 이메일이 발송된다는 것을 의미합니다.
리치의 문제는 첫 번째 이메일과 마지막 이메일 사이의 시간 차이, 즉 1시간의 지연입니다. 이는 발송해야 하는 이메일의 양이 방대하기 때문일 가능성이 높지만, 이 역시 단정 지을 수는 없습니다.
위 설정을 변경하면 첫 번째 이메일의 발송은 빨라지지만, 22,000통의 이메일 전체 배치 처리 완료 시간은 단축되지 않습니다.
인프라 성능에 따라 달라지겠지만, 권장 설정은 어떻게 될까요?
높은 설정값이 부하 등 서버 문제의 원인이 될 수 있을까요?
"서버가 감당할 수 있는 최대치까지"입니다.
이는 OP(질문자)의 서버 용량에 100% 달려 있습니다. 너무 많으면 속도가 느려지고, 너무 적으면 처리에 시간이 더 걸립니다.
CPU 그래프가 40%까지 올라가는 것을 보면 (이것이 단일 CPU 기준인지 총 용량 기준인지?), 속도 저하에 대한 위험 허용도에 따라 2배(보수적) 또는 3배(공격적)로 늘려서 시작해 보는 것이 좋겠습니다.
훌륭한 통찰 감사합니다 
그 DISCOURSE_SIDEKIQ_WORKERS가 5의 배수여야 하나요? 예를 들어 7로 설정할 수도 있나요?
app.yml에 해당 매개변수 설정이 없으므로 어딘가에서 기본값 5로 설정되어 있다고 가정하겠습니다.
기존의 유니콘(unicorn) 워커 설정 아래에 해당 설정을 추가한 후 다시 빌드하면 되나요?
예를 들어:
expose:
- “443:443”
env:
UNICORN_WORKERS: 8
DISCOURSE_SIDEKIQ_WORKERS: 7
그렇게 간단하나요?
DISCOURSE_SIDEKIQ_WORKERS 파라미터가 현재 존재하지 않는 경우, 제 app.yml에 이 변경 사항을 적용하는 것이 올바른 방법인지 확인해 주실 수 있는 분이 있나요?
네, AI 봇에 간단한 질문을 하면 된다고 생각합니다.
고맙습니다 @TempAccount
흥미롭게도 DISCOURSE_SIDEKIQ_WORKERS는 meta 전체에서 단 11번만 등장합니다:
https://meta.discourse.org/search?q=%22DISCOURSE_SIDEKIQ_WORKERS%22%20order%3Alatest_topic
…그중 하나가 바로 이 토픽에 있습니다 
네, 맞습니다.
대부분의 설정은 이 방식으로 재정의할 수 있습니다. 기본값은 discourse_defaults.conf에서 가져옵니다.
@supermathie 감사합니다
제 app.yml 파일은 이제 다음과 같습니다:
env:
LANG: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## How many concurrent web requests are supported? Depends on memory and CPU cores.
## will be set automatically by bootstrap based on detected CPUs, or you can override
UNICORN_WORKERS: 8
## Added this line on 04/10/25
## REF: https://meta.discourse.org/t/is-there-a-way-i-can-send-email-notifications-faster/383103/12
DISCOURSE_SIDEKIQ_WORKERS: 7
이번 주 후반에 재빌드하고 이메일 전송 시간을 측정해 보겠습니다. 
제 변경 사항이 제대로 적용되었는지 확인하기 위해, 이 Threads 값이 5에서 7로 증가해야 한다는 제 추측이 맞습니까?
@Richie 문제를 해결하셨나요?
후속 조치해 주셔서 감사합니다.
아니요, 안타깝게도 아닙니다.
스레드를 5개에서 8개로 늘렸지만, 이메일을 처음부터 끝까지 보내는 데 여전히 1시간 가까이 걸립니다.
전체 처리량이 약 40% 증가할 것으로 예상합니다.
작업이 큐에 쌓여 있을 때, 사용률이 7/7로 나타나나요?
또한, 작업 처리 중 서버 부하를 확인해 보시고, 더 올릴 수 있다면 그렇게 하는 것을 권장합니다.
아, 잠깐. Discourse가 스스로를 제한하고 있는 건가요?
CPU 사용량을 제한하는 설정을 놓친 건가요?? 
Discourse가 스스로를 제한한다기보다는, 각 sidekiq 워커가 한 번에 하나의 작업만 처리하기 때문에 22,000통의 이메일이 대기 중이라면 그중 7통만 동시에 처리됩니다.
조금 극단적인 예를 들자면, 병렬 워커 수를 1,000으로 설정하면 서버가 이를 감당하지 못할 가능성이 큽니다. 따라서 모든 요구 사항을 충족하는 적절한 수치를 찾는 것이 중요합니다:
