openNAMU/구 연구

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

The contents of this wiki are distributed in the same way as the license of openNAMU.