이 문서 내용은 좀 낡았습니다.
60일이나 편집 안된 오래된 망한 문서니 개발 문서인 경우 참고할 때 조심하세요. 최신 정보를 알고 싶으면 게시판에 글 써주세요

목차

1. 서론
2. 본론
2.1. 실제로 문제가 벌어졌다
2.1.1. 원인 분석
2.1.1.1. 임시 해결
3. 그래서 어떻게 개선을 해야할까...
3.1. 예전처럼 캐싱을 추가하자

1. 서론 ✎ ⊖

  • 이제 렌더러는 어느 정도 완성되었으나... 느리다
  • 터지지는 않지만... 느리다

2. 본론 ✎ ⊖


사실 타임아웃이 존재하면 좀 느려도 알아서 작동 멈추니 상관이 없다. 그러나 현재 오픈나무 구조에서는 타임아웃이 없으며 도입하기도 까다롭다. 그 놈의 파이썬 GIL 문제 때문에(1)

일단 가장 간단한 해답은 인클루드 제한이랑 문서 길이 제한을 매우 보수적으로 테스트 결과 하에 잡는 거라고 생각하지만... 현 테스트 결과 20만 글자만 되어도 세월아 네월아 걸린다는 비관적인 전망만 접수하였다. 눈물만 흐른다 진짜 Go언어로 렌더러 짜야하나

일단 그래서 좀 최적화가 필요하다는 결론을 얻었다. 사실 이게 그냥 문서 작성에서는 순차적으로 차츰차츰 늘어나니 어느 순간 이상함을 느끼겠지만 이게 일반적인 문서 작성이 아니라 반달인 경우에는 음... 아마 알파위키-더시드위키 동시다발적 서버 장애 사건/경과 꼴 나지 않을까 매우 우려스럽다

2.1. 실제로 문제가 벌어졌다 ✎ ⊖

틀:발로란트/요원이 엄청나게 느리다...

아마 wiki 문법 때문일 것 같은데 wiki 문법은 include처럼 매우 비효율적인 렌더링 구조를 하고 있어서 그런 것 같다...

2.1.1. 원인 분석 ✎ ⊖

wiki 문법은 렌더링 되면서 wiki 문법 안 쪽의 문법을 다시 원래대로 복원하고 리스트에 저장해서 따로 뺀 다음 마지막에 다시 렌더링하는 재귀 구조를 가지고 있다

그렇다면 wiki 문법 안에 wiki 문법이 엄청 많은 경우라면? 안 쪽의 wiki 문법을 렌더링하고 다시 밖에서 복원되고 다시 렌더링되는 최소 O(N2)의 영 좋지 않은 구조가 된다

같은 문법이 계속 여러번 렌더링 된다
2.1.1.1. 임시 해결 ✎ ⊖
일단 그 리스트를 거꾸로 뒤집어서 제일 밖의 wiki 문법부터 렌더링 되도록 하고 실제로 wiki 문법 들어갈 곳이 있는 지 없는 지 먼저 확인하고 렌더링 하도록 구조를 바꿨다

그랬더니 좀 빨라지긴 했다... 여전히 6초 넘게 걸리긴 하는데... 그래도 이전은 1분이나 걸렸으니 10배나 개선되었다

acl_check가 계속 반복되는 문제가 설마 원인인가 하고 해결했더니 2초 안에 렌더링 된다...

3. 그래서 어떻게 개선을 해야할까... ✎ ⊖

... 아직 생각 중이다. 막막하다

3.1. 예전처럼 캐싱을 추가하자 ✎ ⊖

일단 적어도 캐싱을 추가하면 보는 건 느려질 일이 거의 없다
(1) 원래는 한 스레드에선 타이머 작동 시키고 한 스레드에서는 함수 동작 시켜서 다른 스레드가 반대 스레드를 메모리 상에서 슉슈슉 죽어라 하면서 견제 해야 하는데 파이썬은 멀티스레드가 GIL 때매 못 쓰니 답이 없다 멀티프로세싱은 메모리 공유를 안하니 견제가 불가능하다 내가 모르는 걸지도 모르지만