최근 Discourse를 재구성(self-hosted)한 후, 사이트의 활동량이 매우 낮은 상태(동시 사용자 1~2명)임에도 불구하고 메인 Full Calendar Version 6를 볼 때 사용자 측에서 일관되게 속도 제한(rate limiting)을 경험하고 있습니다. 이 현상은 지난 두 번의 재구성 이후에 나타나기 시작했습니다.
제 속도 제한 설정(app.yml에서 설정된 값):
DISCOURSE_MAX_ADMIN_API_REQS_PER_MINUTE: 기본값의 4배
DISCOURSE_MAX_REQS_PER_MINUTE: 기본값의 4배
DISCOURSE_MAX_REQS_PER_DAY: 기본값의 4배
IP별 속도 제한은 지정되어 있지 않습니다.
관찰 사항
/logs에 오류가 표시되지 않습니다.
리버스 프록시를 사용하지 않고 있습니다(표준 Let’s Encrypt 컨테이너와 도메인의 A 레코드 사용).
캘린더 뷰에서만 이러한 예기치 않은 속도 제한이 발생하는 것 같습니다.
사용자 활동에 변경 사항은 없습니다.
모든 플러그인과 테마 컴포넌트는 공식적인 것입니다.
이는 최근 Discourse 재구성 이후에만 시작되었습니다. 오늘 밤의 재구성 이후에도 지속되었습니다.
사고 발생 시점에 Admin > Logs는 깨끗한 상태였습니다.
지금까지의 문제 해결 시도
사용자 정의 속도 제한 설정이 존재하며 기본값보다 훨씬 높다는 것을 확인했습니다.
여러 브라우저를 시도하고 캐시를 삭제했습니다.
meta.discourse.org 주제에 따르면, 업그레이드 이후 사용자 정의 값을 덮어쓰는 추가적인 문서화되지 않은 내부 속도 제한이 있을 수 있다고 합니다.
이 문제는 Re-add full ics export - #9 by kelv 와 관련이 있을 수 있습니다. 100개의 이벤트가 표시된 후 약 2분 뒤에 또 다른 대량의 이벤트가 표시되며, 이벤트가 점진적으로 나타나는 것이 아니라 큰 덩어리로 한꺼번에 나타나는 경향이 있기 때문입니다.
수정: 이 속도 제한 동작은 현재로서는 관리 가능하지만, 기간을 크게 앞당기면 문제가 드러납니다. 현재 주와 다음 주에 있는 모든 이벤트를 볼 수 있지만, 그다음 주로 이동하면 하드 리밋에 도달합니다.
저는 그게 그런 종류의 레이트 리밋이라고 생각하지 않습니다. API 스로틀링 설정에 대해 언급했을 때, 실제로 말한 것은 제 Discourse가 많은 이벤트 토픽을 처리하도록 구성되어 있다는 것이지만, 코드가 병합된 이후로 FullCalendar 뷰가 예전만큼 잘 작동하지 않고 있습니다.
제 Discourse 인스턴스는 tests-passed 상태이며 최신 버전으로 업데이트되어 있습니다. 어제 제 인스턴스를 사용하는 다른 사용자로부터 미래 주视图(week view)에서 모든 이벤트가 로드되지 않는다는 보고를 받았습니다. 현재 주视图(Current week view) UI에 이 오류가 더 이상 영향을 주지 않는다는 점을 이미 인지하고 있었기 때문에, 제 노트북에서 오류를 정확히 파악하기 위해 시도했습니다. 아래는 오류 재현 영상입니다.
미래 주에서 발생하는 동일한 “이벤트 누락” 문제는 제 스마트폰에서도 동일하게 재현됩니다.
