- 이제 렌더러는 어느 정도 완성되었으나... 느리다
- 터지지는 않지만... 느리다
사실 타임아웃이 존재하면 좀 느려도 알아서 작동 멈추니 상관이 없다. 그러나 현재 오픈나무 구조에서는 타임아웃이 없으며 도입하기도 까다롭다.
그 놈의 파이썬 GIL 문제 때문에(1)일단 가장 간단한 해답은 인클루드 제한이랑 문서 길이 제한을 매우 보수적으로 테스트 결과 하에 잡는 거라고 생각하지만... 현 테스트 결과 20만 글자만 되어도 세월아 네월아 걸린다는 비관적인 전망만 접수하였다.
눈물만 흐른다 진짜 Go언어로 렌더러 짜야하나일단 그래서 좀 최적화가 필요하다는 결론을 얻었다. 사실 이게 그냥 문서 작성에서는 순차적으로 차츰차츰 늘어나니 어느 순간 이상함을 느끼겠지만 이게 일반적인 문서 작성이 아니라 반달인 경우에는 음... 아마
한마음위키:알파위키-더시드위키 동시다발적 서버 장애 사건/경과 꼴 나지 않을까 매우 우려스럽다
2.1. 실제로 문제가 벌어졌다 ✎ ⊖
틀:발로란트/요원이 엄청나게 느리다...
아마 wiki 문법 때문일 것 같은데 wiki 문법은 include처럼 매우 비효율적인 렌더링 구조를 하고 있어서 그런 것 같다...
wiki 문법은 렌더링 되면서 wiki 문법 안 쪽의 문법을 다시 원래대로 복원하고 리스트에 저장해서 따로 뺀 다음 마지막에 다시 렌더링하는 재귀 구조를 가지고 있다
그렇다면 wiki 문법 안에 wiki 문법이 엄청 많은 경우라면? 안 쪽의 wiki 문법을 렌더링하고 다시 밖에서 복원되고 다시 렌더링되는 최소 O(N2)의 영 좋지 않은 구조가 된다
같은 문법이 계속 여러번 렌더링 된다
일단 그 리스트를 거꾸로 뒤집어서 제일 밖의 wiki 문법부터 렌더링 되도록 하고 실제로 wiki 문법 들어갈 곳이 있는 지 없는 지 먼저 확인하고 렌더링 하도록 구조를 바꿨다
그랬더니 좀 빨라지긴 했다... 여전히 6초 넘게 걸리긴 하는데... 그래도 이전은 1분이나 걸렸으니 10배나 개선되었다
acl_check가 계속 반복되는 문제가 설마 원인인가 하고 해결했더니 2초 안에 렌더링 된다...
3. 그래서 어떻게 개선을 해야할까... ✎ ⊖
3.1. 예전처럼 캐싱을 추가하자 ✎ ⊖
일단 적어도 캐싱을 추가하면 보는 건 느려질 일이 거의 없다