OnlyOffice 공동 편집 지연 현상 해결: 병목 현상 찾기

자체 호스팅 Docker 서버에서 ONLYOFFICE 공동 편집 속도가 느리게 느껴질 경우, 먼저 지연의 원인이 서버, 네트워크 경로 또는 특정 문서에 있는지 확인하십시오. 설정을 변경하기 전에 동일한 편집 세션을 측정하여 컨테이너 및 호스트 리소스 사용량을 확인하고, 리버스 프록시가 라이브 편집기 연결을 올바르게 전달하는지 확인하십시오. 이러한 측정 결과 용량 한계가 나타날 때만 CPU, 메모리 또는 기타 인프라를 추가하십시오.

1. 렉 현상을 재현하고 서버를 점검한 후 설정을 조정하세요.

두 명의 편집자에게 동일한 문서를 열고 동시에 간단한 변경을 하도록 요청하십시오. 두 사용자 모두 타이핑 속도가 느려지는지, 한 사용자가 업데이트를 늦게 확인하는지, 그리고 문제가 모든 파일에서 발생하는지 아니면 특정 대형 또는 복잡한 파일에서만 발생하는지 기록하십시오. 이 간단한 비교를 통해 일반적인 서비스 문제와 문서별 작업 부하 문제를 구분할 수 있습니다.

Docker 호스트에서 문서 서버 컨테이너를 찾고 지연 현상이 발생하는 동안 해당 컨테이너의 리소스 사용량을 확인합니다.

docker ps
 docker stats <container_name_or_id>

CPU 포화 현상이 지속되거나, 호스트 또는 컨테이너의 메모리 사용량이 한계에 근접하거나, 스왑 활동이 활발하거나, 컨테이너가 재시작되는 현상이 발생하는지 확인하십시오. 저장 또는 문서 로딩이 일시 중단되는 경우 호스트 디스크 공간 및 I/O 사용량도 확인하십시오. 짧은 시간 동안 사용량이 급증하는 현상보다는 느린 편집 작업과 동시에 발생하는 병목 현상을 파악하는 것이 더 중요합니다. ONLYOFFICE Docker 문제 해결 페이지에서는 열려 있는 문서와 동시 사용자 수가 증가함에 따라 메모리 사용량이 증가한다고 언급하며, 수십 명의 활성 사용자가 있는 서버의 경우 정상적인 사용량은 2~4GB라고 제시하지만, 이는 모든 경우에 적용되는 적정 용량은 아닙니다.

ONLYOFFICE는 문서를 편집하거나 보고 있는 모든 사용자를 동시 활성 사용자로 계산한다는 점을 기억하십시오. 최대 동시 접속 사용자 수를 에디션별 커뮤니티 Docker 시스템 요구 사항 과 비교하십시오 . 공개된 수치는 참조 구성이며, 실제 용량은 문서 유형 및 크기에 따라 달라진다고 설명서에 명시되어 있습니다.

2. 편집자가 다시 연결되면 프록시 및 네트워크 경로를 검사하십시오.

에디터가 로드되지만 공동 편집자의 연결이 반복적으로 끊어지거나, 지연 현상이 공개 URL에서만 발생하는 경우, 서버 리소스를 추가하기 전에 리버스 프록시를 점검하십시오. WebSocket은 실시간 에디터 트래픽에 사용되는 영구 연결입니다. 해당 연결을 닫거나 업그레이드하지 못하는 프록시로 인해 편집이 지연되거나 재연결 문제가 발생할 수 있습니다.

지연이 발생하는 세션 동안 프록시의 액세스 및 오류 로그를 확인하십시오. 구성에서 HTTP Upgrade 및 Connection 헤더를 전달하고 원래 호스트 및 프로토콜을 유지하는지 확인하십시오. NGINX의 경우 ONLYOFFICE의 공식 프록시 예제 와 설정을 비교하십시오 . 해당 문서에는 전달되는 헤더 X-Forwarded-Proto에 대한 내용이 명시되어 있습니다 X-Forwarded-Host. TLS 종료, 경로 접두사 또는 프록시 토폴로지가 다른 경우 샘플을 그대로 붙여넣지 마십시오.

동일한 LAN에 있는 클라이언트와 일반 원격 경로에서도 테스트를 진행하십시오. LAN 세션은 응답이 빠른데 공용 경로가 느리다면 프록시, 방화벽, VPN, DNS 또는 WAN 지연 시간을 조사하십시오. 두 경로 모두 동시에 지연이 발생한다면 서버 측 부하 문제일 가능성이 높습니다. 브라우저 개발자 도구를 활용하면 도움이 될 수 있습니다. WebSocket 연결이 반복적으로 끊어지는 것은 연결 처리 문제일 수 있으며, 연결이 안정적인데도 호스트가 포화 상태일 때 편집 속도가 느리다면 용량 부족이나 작업 부하 문제일 수 있습니다.

3. 서버 설정을 변경하는 것이 아니라 워크플로에 따라 '빠름' 또는 '엄격함'을 선택하세요.

ONLYOFFICE는 기본 설정인 빠른 공동 편집과 엄격한 공동 편집을 제공합니다. 빠른 공동 편집은 다른 사용자의 편집 내용을 실시간으로 보여주며, 엄격한 공동 편집은 사용자가 저장하기 전까지 변경 사항을 보류합니다. 공동 편집 설명서에는 변경 사항 표시 방식의 차이점이 자세히 설명되어 있습니다. 엄격한 공동 편집은 일괄적으로 변경 사항을 검토하고 적용하는 것을 선호하는 팀에 적합하며, 빠른 공동 편집은 모든 변경 사항을 즉시 공유하는 것이 중요한 경우에 적합합니다.

모드를 변경한다고 해서 CPU 포화 상태, 메모리 제한 또는 WebSocket 경로 오류가 해결되는 것은 아닙니다. 모드 선택은 협업 환경 설정의 일부로 간주하고, 팀에서 어떤 워크플로가 적합한지 결정할 때만 각 모드에서 동일한 파일과 사용자 수를 비교하세요. 모드 전환이 성능 향상을 보장하는 것처럼 제시하지 마십시오.

4. 용량 압력을 측정한 후에만 스케일을 조정하십시오.

CPU 사용률이 포화 상태에 이르거나 메모리가 부족하거나 컨테이너가 재시작되는 동안 문서 및 사용자 간에 지연이 발생하는 경우, 먼저 문서 서버에 충분한 호스트 리소스를 할당하고 Docker 제한으로 인해 호스트 리소스가 부족해지지 않는지 확인하십시오. 그런 다음 다시 테스트하십시오. 커뮤니티 에디션 Docker 참조 문서에는 동시 사용자 수에 따라 달라지는 4GB RAM 및 스토리지 요구 사항이 명시되어 있습니다. 400명 이상의 동시 활성 사용자가 있는 경우 클러스터 배포를 권장하며 Kubernetes를 참조하도록 안내합니다. 이러한 수치는 계획 수립 시 참고 자료로 활용해야 하며, 특정 서버가 특정 워크로드를 지원한다는 보장은 아닙니다.

소규모 설치 환경에서는 일반적으로 서비스를 호스트 간에 분산하는 것보다 사용 가능한 CPU 또는 메모리를 늘리는 것이 더 간단합니다. 지속적으로 높은 동시성을 유지해야 하는 경우, 분리된 서비스 또는 클러스터링된 서비스를 사용하면 여유 공간이 더 많아지지만, 네트워크 종속성, 구성, 모니터링 및 장애 발생 가능성이 증가합니다. ONLYOFFICE의 현재 공식 Compose 예제에는 문서 서버 엔드포인트에 대한 상태 확인 기능이 포함되어 있습니다. 실행 중인 컨테이너가 정상적인 편집 경로를 의미한다고 가정하기보다는 컨테이너 상태와 애플리케이션 응답성을 함께 확인하십시오. 진단 중에는 배포 업데이트로 인해 전후 측정값이 혼동되지 않도록 이미지 버전을 고정해 두십시오.

동일한 편집 테스트를 통해 수정 사항을 확인하십시오.

동일한 문서, 클라이언트 경로 및 대략적인 부하를 사용하여 원래 두 사용자 편집 환경을 다시 실행합니다. 두 편집자 모두 타이핑 반응이 빠르고, 선택한 공동 편집 모드에서 변경 사항이 일관되게 표시되며, 재연결 또는 컨테이너 재시작이 더 이상 발생하지 않는지 확인합니다. docker stats재테스트 중에 상황을 모니터링하고 연결 관련 문제인지 확인하기 위해 프록시 로그를 확인합니다. 소규모 테스트에서는 문제가 없지만 피크 시간대 세션에서 여전히 지연이 발생하는 경우, 추가 설정을 변경하기 전에 컨테이너 이미지/버전, 호스트 및 Docker 버전, 마운트된 볼륨, 리소스 그래프 및 관련 로그를 수집합니다. Docker에서 임시 디버그 로그를 활성화하는 방법은 공식 디버그 로깅 가이드를 참조하십시오. 증거를 수집한 후에는 로그 용량이 증가하므로 상세 로깅을 다시 비활성화합니다.

결과를 바탕으로 절충안을 선택하십시오. 연결이 끊어지면 프록시를 수정하고, 측정 결과 지속적인 리소스 압박이 나타나면 용량을 추가하고, 복잡한 문서 하나만 영향을 받는 경우에는 해당 워크로드를 격리할 때까지 서버를 그대로 두십시오.