아직은 렌더러에 대해서 마이너한 개선이 이루어지고 있지만 근본적으로 파이썬 위에서 작동하고 있다
이러한 구조에선 성능을 마이너하게 개선해도 아예 구조를 갈아엎지 않는 이상 솔직히 성능을 크게 개선하기 어렵다
그래서 이러한 문제를 잠시 완화하고 Golang으로 넘길 타이밍을 찾기 위해서 일단 우선 캐싱을 도입하려고 한다
2. 캐싱 예전에 있었잖음? ✎ ⊖
맞다
캐싱 예전엔 있었다 그러나 없앤 이유는 후술하겠지만 모든 캐싱이 그렇듯이 장점만 존재하는 게 아니라서 딜레마이다
그래서 이러한 캐싱 간의 상호 장단점을 평가하고 임시 보완책을 찾으려고 쓰는 문서가 이 문서이다
- 단어는 내가 임의로 붙인거라 공식 용어는 아니니 어디가서 쓰면 망신 당할 수도 있다(...)(1)
문서를 저장할 때 전체 구조를 캐싱하고 보여준다 갱신이 필요할 땐 문서 위에 있는 갱신 버튼으로 갱신한다
장점- 단순하고 구현하기 쉽다
- 자동 갱신을 안하니 성능상 가장 우월하다
단점- include가 바뀌어도 자동 갱신을 안하니 문제가 생긴다(2)
- 링크의 문서가 삭제되거나 새로 생겨도 자동 갱신을 안하니 문제가 생긴다(3)
개인 생각- 토론이나 게시판엔 이걸 적용하는 게 가장 깔끔한 것 같긴하다
기본 구조는 문서 저장 캐싱과 동일하나 역링크를 참조해서 다른 include, 링크가 편집된 경우 알아서 캐싱을 파기한다
장점단점- 저장할 때 역링크 문서를 전부 건들여야해서 역링크가 무진장 많으면 저장시 극단적으로 느려질 수도 있었다
- 물론 근데 단순 delete라서 그렇게 느려질까...? 싶긴하다 테스트를 안해봤으니
- 역링크가 제대로 안 되어 있으면 오인 사격이 가능하다
- 문서 규모 크고 문서 내에 링크나 include가 많고 편집이 자주 일어나면 캐싱이 없는거나 마찬가지일 수도 있다
개인 생각- 현실적으로 이게 그래도 가장 타협 가능한 캐싱 방법인 것 같다
3.3. 일부 자주 바뀌는 부분만 CSR 캐싱 ✎ ⊖
기본 구조는 문서 저장 캐싱과 동일하나 include와 링크 등등은 따로 빼서 클라이언트 사이드 렌더링을 적용한다
장점- 이것저것 해본 바로는 성능상 가장 나은 방안이긴 하다
단점- 코드가 파이썬과 JS로 나눠져서 일관되지 못하다
- 아래에 더 기술하겠지만 CSR의 단점을 일부 공유한다
- 다른 걸 다 제쳐놓고 가장 큰 문제는 UX 경험이 별로 안 좋다
기본 구조는 동일하나 자동으로 n시간 정도마다 내용을 알아서 갱신한다
장점- 문서 저장시 캐싱의 단점을 어느 정도 커버할 수 있다
단점- 문서가 많아지면 타이머 작동 시켜야할 문서가 너무 많아진다
- 파이썬은 병렬스레드가 안되서 이러면 렌더링마다 block 걸려서 최악을 달릴 수도 있다
3.5. Lazy 갱신 캐싱 ✎ ⊖
기본 구조는 동일하나 사용자에게 보여줄 때 캐싱한 내용 보여주면서 뒤에선 캐싱을 최신으로 갱신한다
장점- 성능 상 그렇게 나쁘지 않다
- 적어도 다음에 들어오는 사람에겐 최신 캐싱 결과를 보여줄 수 있다
단점- 결국 뒤에서 렌더러를 돌리고 있으니 서버 부하는 딱히 안 줄어든다
- 처음 들어오는 사람은 최신 캐싱이 아니니 옛날 문서 보는 것과 똑같다
4. 그 외 기타 ✎ ⊖
4.1. 왜 CSR을 안하는가? ✎ ⊖
가끔 렌더링을 서버 사이드에서 안하고 클라이언트 사이드에서 하면 되는 거 아니냐라는 말이 있다
그러나 이것도 예전에 오픈나무에서 도입해서 해봤는데 크게 4가지 문제가 있었다
- 1. 사용자의 기기 사양마다 성능이 너무 천차만별이다
- 2. 역링크 구조를 파악하려면 어차피 서버 사이드에서 한번 렌더링을 해야한다
- 3. SEO에서 디버프가 너무 쌔다(4)
- 4. UX 경험이 별로 안 좋다(5)
한동안 이 구조를 유지하면서 개선할 방안을 찾아봤는데 뾰족한 방안을 못 찾아서 결국 원래대로 돌아왔다