.jpg)
안녕하세요, 페미위키 개발팀 낙엽1124입니다. 지난 글 "서버를 도쿄에서 서울로 옮겼습니다"에서는 서버를 서울로 옮긴 이야기를 전해드렸습니다. 연재 마지막인 이번 포스트에서는 그래서 페미위키가 얼마나 빨라졌는지를 숫자로 소개드리려고 합니다.
배경
아쉬운 결론부터 말씀드리면 서버가 문서 하나를 그리는 시간은 거의 그대로입니다. 대신 서버가 덜 붐비게 되어 방문객이 오래 기다리는 일이 줄었고, 서버가 가까워진 만큼 응답이 빨라졌습니다.
아래 숫자는 웹 서버가 요청을 받아 응답을 내보내기까지 걸린 시간입니다. 인터넷을 오가는 시간이나 브라우저가 화면을 그리는 시간은 들어 있지 않고, 크롤러가 섞여 있어서 사람이 겪는 시간과 꼭 같지는 않습니다.
기다리는 시간
사람이 볼 법한 문서 요청의 응답 시간을 날마다 같은 시간대(오전 9시~오후 3시)로 견줬습니다.
| 날짜 | 서버 | 중앙값 | 느린 5% |
|---|---|---|---|
| 9월 22일 | 도쿄 | 0.36초 | 4.27초 |
| 9월 24일 | 도쿄 | 0.42초 | 6.43초 |
| 9월 26일 | 도쿄 | 0.17초 | 0.92초 |
| 9월 27일 | 서울 | 0.20초 | 1.80초 |
| 10월 12일 | 서울 | 0.20초 | 1.22초 |
느린 쪽이 수 초에서 1초 안팎으로 내려왔습니다. 가장 큰 몫은 크롤러를 거른 것이고,[1] 그 밖에도 몇 가지를 바꿨습니다.
- PHP 워커를 10개에서 16개로 늘렸습니다. 워커가 모두 바쁜 일이 30분에 12번에서 하루 5번으로 줄었습니다.[2]
- 상태 검사가 바쁜 워커 뒤에 줄을 서다 실패해서 멀쩡한 서버가 재시작되곤 했으나 이제 상태 검사는 따로 둔 워커가 받게 되었습니다.[3]
- 새 버전을 배포한 직후 한동안 느려지던 증상이 있었으나 새 컨테이너가 코드를 미리 컴파일한 뒤에 요청을 받게 해서 고쳤습니다.[4]
반면 "2025년 가을부터 이어진 사이트 접속 문제 안내"에서 소개한 캐시 버그 수정은 속도를 크게 바꾸지 못했습니다. 페미위키에서는 같은 문서가 짧은 시간에 다시 요청되는 일이 드물어서 캐시가 아무리 커도 요청의 9%쯤만 캐시에서 나갈 수 있었습니다.[5]
아직 느린 곳
휴대폰에서는 여전히 느리게 느껴질 수 있습니다. 로그인하지 않은 방문객에게 페이지 하나를 보여 주는 데에 스크립트와 스타일까지 1.2MB쯤 되어서, 느린 모바일 환경을 흉내 내 재 보면 서버는 0.3초 만에 응답하는데도 본문이 다 보이기까지 7.7초가 걸립니다.[6]
(이상에서 구체적인 숫자는 바뀌었을 수 있습니다)
맺음말
다섯 편에 걸쳐 작년부터 이어진 접속 문제와 지난 추석 연휴에 한 일을 소개드렸습니다. 사이트가 멈추는 일은 막았지만 크롤러는 계속 모습을 바꿔 찾아올 것이고 휴대폰에서 느린 문제도 남아 있습니다. 할일이 많습니다.
끝까지 읽어 주셔서 감사합니다.
출처
- ↑ https://github.com/femiwiki/femiwiki/issues/586
- ↑ https://github.com/femiwiki/infra/pull/628
- ↑ https://github.com/femiwiki/docker-mediawiki/pull/1116
- ↑ https://github.com/femiwiki/femiwiki/issues/567
- ↑ https://github.com/femiwiki/femiwiki/issues/454
- ↑ https://github.com/femiwiki/femiwiki/issues/612