오픈나무에서 최근 개발하면서 연구하고 있는 그런 내용들을 적는 곳 입니다. 라고 하지만 걍 일기장 + 노가다 삽질 + 해명이다
2.1. 검색 느려짐 현상 (해결?) ✎ ⊖
SQL문을 쑤셔 넣으면 모든 문서를 향해서 돌리는데 문제는 문서수가 아주 많아지면 그 찾아야하는 용량도 방대하게 커지므로 문제가 된다.
아마도 문서 수가 5만 이상 넘어가면 그냥 문서 제목만 SQL문 돌리고 내용은 안 돌리면 되지 않을까? 생각 중
3만 넘어가면 제목만 돌리는 방식으로 최적화 완료
2.2. 검색 느려짐 현상 2 ✎ ⊖
제목만 돌려도 문서수가 70만이면 너무 느리다 더 개선 필요.
2.2.1. 대충 해결 예상 (불가능) ✎ ⊖
그냥 모든 문서 이름을 저장한 파일을 하나 만들어서 거기서 불러오면 어떨까... 그런데 이것도 문제인가 문서수가 20만개고 한 문서당 이름이 5글자면 100만자라는 점이다.
2.2.2. 임시 다른 해결책 적용 (실패) ✎ ⊖
%% 검색이 원래 인덱싱을 사용안한다고 한다 그래서 일단 다른 쓸모없는 비교문을 붙여서 속도를 올리는 방법을 사용했는데 효과 있는지는 잘 모르겠다
효과가 없는 것 같다... 다른 방법을 연구해야겠는데 좋은 방법이 안난다.
2.3. 좀 더 효율적인 렌더링 방법 ✎ ⊖
2.3.1. JS 오픈나무마크 (중단) ✎ ⊖
이건 그냥 사용자에게 JS를 이용해서 렌더링을 전가해버리는 방식이다... 똥컴이 아니라면 파싱 속도가 확실히 개선되긴 하는 것 같다. 근데 역링크가 문제다. 이건 아래 참고
생각해보니 이것도 좋은 생각은 아닌 것 같다. 일단 역링크 렌더러를 또 따로 돌려야 하는 것도 문제고 생각보다 속도 개선이 빠르지 않다.
2.3.2. 캐싱을 통한 속도 상승 (완료) ✎ ⊖
HTML을 아예 통째로 저장해서 문서 렌더링 속도를 올리는 게 더 빠르고 편리할 것 같다. 이미 이 생각은 옛날부터 했지만 그 때는 기술력이 모자라서 구현하지 못 했지만 지금이라면 가능할 것 같다. 그런데 이것도 문제인게 만약 렌더러를 고쳤다면 이 HTML도 고쳐야하는데... How?
(1)렌더러 고쳤다면 DB 버전을 올려서 캐싱을 날려버리는 그런 알고리즘을 적용해놨다... 아마 문제 없을 것이다.
2.4. 좀 더 효율적인 역링크 방법 ✎ ⊖
현재 역링크 방법은 모든 링크를 그냥 DB에 다 때려 넣는 그런 방식이다. 물론 이 방식이 로드에는 가장 빠르고 편리...하진 않지만 어쨌든 쓸만하다
그런데 문제는 문서 수가 너무 많으면 이게 갱신이 세월아 네월아 수준으로 걸린다. 그래서 파서를 고칠 때마다 고민에 빠진다. 기능 구현도 문제고...
사실
JS 렌더러도 문제인게 이것도 역링크를 어떻게 구현해야할 지 사실 잘 모르겠다.
그리고 이게 또 다른 문제가 우리나라에 이런 기능을 가진 위키 엔진은
더 시드랑
모니위키 뿐인데 더 시드는 그냥 백엔드를 아예 C로 짜서 문제가 없는 것 같고 모니위키는 파일 기반이라 별로 도움이 되지 않는다.
지금 해보고 있는 방법이다. 비동기로 SQL을 슉슉 집어 넣으면 좀 더 빨라지지 않을까? 라는 발상에서 시작했다. 확실히 효과는 있다...만 이것도 여전히 그렇게 빠르진 않다.
그리고 속도랑 램 많이 먹는 건 역시 비례 관계다... 램을 최대한 적게 차지하게 하면서 빠르게 해보려고 좀 실험 해봤는데 역시 그냥 디비에서 하나씩 꺼내오는 것보다 램에 올리고 슈슈슉 하는게 빠른 건 어쩔 수 없는 것 같다. 그래도 뭐 어쩌겠나... 램이 꽉 차면 다른 일을 못하는데 그냥 좀 느려도 이게 한계인 것 같다.
음... 좀 더 연구를 해보니 이 방식은 별로 도움이 되는 것 같지가 않다. 가장 큰 원인은 파서 렌더링이 좀 느린게 문제인 것 같다. 어차피 SQL 삽입은 그렇게 오래 걸리지 않는 것 같다. 실험적으로 증명? 했다. 물론 미세하게 빨라지긴 했는데 비동기로 짜다보니 동기 비동기 섞여서 오류났다...
역링크 전용 렌더러를 만들어서 그걸 돌리는게 훨씬 도움이 될 것 같다.
그것보단 아예 지금 렌더러에서 병목 많이 걸리는 부분만 좀 고쳐도 훨씬 나아질 것 같다. 이미 신형 알고리즘을 생각 해놓긴 했다. 그게 쉽게 구현될 진 몰라도.
2.4.1.3. bulk insert 사용 (완료) ✎ ⊖
스택오버플로보다가 우연히 본 건데 이걸 쓰면 좋다고 한다.
사실 이건 가장 간단한 방법이기도 한데 이것도 문제가 모든 문서를 돌려서 해야한다는 것이다.
옛날에 모니위키도 그런 문제를 가지고 있었고 부정확한 결과를 얻었다고 한다.
(2)근데 지금 검색도 20만만 되도 꾸역꾸역 돌아가는 판국에 역링크를 이렇게 한다는건 말이 안되는 것 같다.
그냥 서버를 연 상태로 비동기로 웹 리퀘스트를 모든 문서에 날려서 역링크를 갱신하게 하면 더 쉽지 않을까?
근데 사실 이 위키 엔진은 문서 대략 몇백 몇천 정도를 생각하고 만든 엔진이라 그냥 이게 한계일지도 모르겠다... 대충 읽어보니
모니위키나
도쿠위키도 같은 문제를 겪은 것 같다.
근데 역링크란 게 필요하긴 한걸까... 난 위키하면서 역링크 거의 안 사용 했는데
얼마 전부터 역링크가 얼마나 느린가 테스트를 하기 위해서 나무위키 DB 파일 가져와서 모든 역링크를 따보고 있다... 아무래도 이거 역링크만 용량이 7기가가 될 것 같다. 벌써 2일 동안 작업하고 있는데 아직도 20~30만 문서다. 근데 하긴 한 문서당 역링크가 너무 많기도 하다. 20만 문서인데 역링크는 벌써 1100만개다... 세상에... 아무래도 1100만개는 파이썬으로 관리할 수 있는 범위 밖인 것 같다.
아무래도 문서수가 10만 이상이면 역링크 기능을 정지 해놓던지 해야겠다.
2.5. 오픈테섭 이미지 손실 ✎ ⊖
멍청하게 서버 이전하면서 DB만 이전하고 이미지를 까먹었다
이건 복구할 방법이 없어서 그냥 파일을 날렸다... 다시 업로드 해야겠다.
어떻게 하면 효율적으로 구현할까?
클래스를 많이 이용하는 방향으로 구현하고 있다. 하지만 생각보다 마크다운에서 HTML을 빼버리니 남는 게 없다...
2.6.2. 일부 HTML을 지원해볼까? (확정) ✎ ⊖
이렇게 된다면 기존에 만든 render_html을 재활용해봐야겠다.
아무래도 이 부분이 기존 마크다운의 취지에 가장 비슷한 것 같다.
2.6.3. 아니면 나무마크 매크로 방식으로 지원해볼까? ✎ ⊖
이것도 사실 괜찮은 것 같긴 한데 자칫하면 문법이 섞어서 더럽게 구현될 것 같다 사실 지금 나무마크 렌더러 자체가 더럽지만
2.7.1. gzip || minify ✎ ⊖
gzip을 이용하면 사용자 입장에선 더 적은 데이터로 동일한 내용을 볼 수 있으니 좋을 것이긴 하다... 하지만 서버 CPU 부담이랑 사용자 CPU의 부담이 늘어날텐데 정말 좋은건지는 모르겠다.
전송하는 데이터에 공백을 없애는 방식으로 데이터를 줄이는 방법이다. 사용자 CPU에는 부담이 안 가겠지만 서버 CPU 부담은 여전히 존재할 것이다.
그리고 가장 큰 문제는 textarea의 공백조차 없애버린다는 점이다... 이건 좀 어떻게 해결을 해야겠다.
gzip이나 minify가 의외로 서버 속도를 많이 잡아먹는 것 같다;; 이상하게 끄니까 점수가 더 좋게 나온다.
아마 서버 반응속도 때문인 것 같다. 충분히 빠른 서버라면 켰을 때가 점수가 더 좋을 것이라 예상된다.
하지만 누가 오픈나무를 충분히 빠른 서버에 올리겠어?
이상하게 pythonanywhere에 올린 오픈나무는 오랫동안 접속 안하면 느려지길래 원래 mysql용으로만 쓰이던 자동 접속을 sqlite에도 적용하니 속도가 훨씬 빨라졌다. 도대체
2.8. 일부 기능 변경 예정 ✎ ⊖
편집 요청 기능은 현재 구현이 너무 엉성하고 코드 꼬임도 발생하므로 통째로 날리고 코멘터리라는 개인적으로 생각한 기능으로 변경할 예정이다.
편집이 불가능한 유저들이 자기들이 원하는 편집 내용을 적을 수 있는 공간 같은 것을 만들 것이다.