선택적 세션 시작 (Proof of Concept)

[kijin]

#1598 및 #1613 과 달리, 필요할 때만 세션을 시작하면서도 서드파티 애드온, 모듈, 스킨, 레이아웃 등의 코드를 단 한 줄도 변경할 필요가 없는 패치입니다.

• 세션 쿠키가 이미 존재한다면 세션을 시작하고, 그렇지 않다면 시작하지 않습니다. 이 부분의 로직은 캐시서버를 위한 Cache-Control 헤더 제어 #1598 과 동일합니다.
• 세션을 시작하지 않는 경우 $_SESSION을 빈 배열로 초기화합니다.
• 모든 모듈과 애드온, 레이아웃, 스킨 등의 실행이 끝난 후에 $_SESSION을 다시 확인하여, 만약 1개라도 데이터가 들어가 있으면 "누군가가 세션 사용을 시도하고 있다"라고 간주하고 세션을 시작합니다.
• 즉, 서드파티 코드에서 $_SESSION에 데이터를 저장할 경우 자동으로 감지하여 세션을 시작합니다.
• 서드파티 자료에서 단순히 세션 데이터를 읽기만 할 경우에는 세션이 시작되지 않으며, 해당 자료는 NULL을 돌려받게 됩니다. 그러나 이것은 로그인 직후에도 마찬가지이므로, NULL을 돌려받는다고 문제가 발생할 가능성은 극히 희박합니다. 정말로 예전에 저장해 둔 데이터가 있다면 이미 세션이 시작되었을 테니 걱정할 필요도 없겠지요.
• 물론 세션을 많이 사용하는 서드파티 자료라면 애초에 세션을 선택적으로 시작하는 의미가 없겠지요. 그러나 그런 자료를 전혀 수정하지 않고 그대로 사용하더라도 최악의 경우 기존과 같은 성능을 얻을 뿐, 기능상의 문제는 발생하지 않을 것입니다.

이 PR은 개념 증명(POC)에 불과하므로, 사용자가 선택할 수 있는 옵션은 넣지 않았습니다. 필요하다면 나중에 추가하도록 하겠습니다. 일단 테스트를 위해 모듈 핸들러와 문서 모듈, 회원 모듈 등에서 세션에 데이터를 저장하도록 하드코딩되어 있는 곳만 일부 수정했습니다.

로그인시 별도로 세션 시작 처리를 해줄 필요는 없습니다. 로그인시 member 모듈에서 $_SESSION에 데이터 저장을 시도하기 때문에, 이것을 자동으로 감지하여 세션을 시작합니다.

로그인하지 않은 사용자가 세션을 시작하지 않고도 게시판 등을 이용하기 위해서는 더 많은 부분의 수정이 필요할 것입니다. 이것은 #1598 의 방법을 따라도 무방합니다.

[wkpark]

방금 간단히 테스트 해보니 잘 작동 하네요~!
세션 관련된 부분을 고치신 것은 다음과 거의 똑같네요. 어떻게 추적하셔서 고치셨나요?
wkpark/xe-core@27ef21c

그밖에, 여기에
wkpark/xe-core@6d61b0e
패치를 적용해야지 Set-Cookie가 모두 걷어내집니다. varnish 캐시서버의 효과를 그래야 볼 수 있지요.

이정도 패치 정도면 1.8.5에 충분히 받아들여질 만하다고 생각합니다.
제 패치는 장기적으로 봤을때에 $_SESSION을 완전히 걷어내어야 한다는 주장과 섞여있고,
1.8.5 / 1.8.6에도 들어갈 지 장담할 수 없다면 차라리 이게 낫겠네요~
이것만 해도 문제가 없다면 varnish 캐시효과를 충분히 볼 수 있을 것입니다. 수고하셨습니다~!

[wkpark]

Pragma: no-cache가 붙기때문에 varnish캐시 효과를 못보네요.

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache

아무튼 이 부분은 $_SESSION호환성과 별개 문제이고,
wkpark/xe-core@cd3d1b2
패치를 선택적으로 적용해야 하겠네요~

[kijin]

@wkpark 추적이라고 해봐야 별거 있나요... 저는 그냥 구닥다리식으로

cd classes
grep -rn "\$_SESSION"

이렇게 해서 세션 건드리는 파일을 다 찾았죠 뭐... 님의 커밋도 상당부분 참고했고요.

Cache-Control 헤더와 나머지 쿠키들은 아직 건드리지 않았는데, wkpark@6d61b0e 와 wkpark@cd3d1b2 를 merge 해서 천천히 작업해 볼 생각입니다. 단, 기존 방식으로 사이트를 운영하는 분들에게 영향을 주지 않기 위해 캐싱 관련 옵션을 별도로 추가하고, 해당 옵션 선택시에만 작동하도록 해야 하겠습니다.

문제는 문서모듈 및 댓글모듈에서 매 페이지뷰마다 세션을 건드린다는 건데... 이건 기능에 변화를 주지 않고는 고칠 수 없기 때문에, 위에서 언급한 옵션을 사용하여 사용자가 선택할 수 있도록 해야겠습니다.

장기적으로 $_SESSION 사용을 모두 걷어내야 한다는 님의 주장도 이해는 됩니다만, 현실적으로 XE 1.x는 거의 EOL에 가까운 상태입니다. 더이상 대규모의 구조적인 변화를 받아들이기는 어려울 거라고 생각합니다. 라라벨 기반으로 개발되는 XE3에서는 개선되기를 기대하는 수밖에요.

[wkpark]

XE3 논의가 여기서 왜 필요한가요
이름만 XE를 빌렸을 뿐이지 더이상 XE라 할 수 없지요.
무론 라라벨 기대하고 있고, 오히려 쉬워보입니다만

---

다시 논의로 돌아가서, XE는 충분히 안정적이고 조금만 더 최적화 하면 최적의 성능을 올릴 가능성이 많습니다. 당장에 랜더링 결과를 캐싱하고 있지도 않더군요. 당연히 랜더링 결과를 캐싱할줄 알았는데 한번 랜더링한 그 결과가 똑같은데 또 랜더링을 반복하고 저장도 안하고 있더군요. 이러니 ab 벤치가 100도 안나옵니다.

성능은 좋은 플레임워크와 사실 별 무관합니다. XE가 많이 비판받고 있는것이 플레임워크가 복잡해져서 성능이 안나온다는 선입견인데, 사실 그것과 별무관하고, 제대로 된 캐싱처리를 안하고 있습니다. memcached / wincache 다 지원하는데 정작 랜더링 결과를 파일캐싱하는 간단한 캐싱을 안하고 있으니^^;;;

아무튼 이 부분은 차차 고치기로 하고...

---

님께서 제안하신 $_SESSION을 후처리 한다는 부분도 상당히 좋은 아이디어 같습니다.
이 부분은 저도 별도로 생각해보기로 하겠습니다~

[kijin]

물론 XE 프레임워크의 성능을 최대로 끌어올릴 수 있다면 더할 나위 없이 좋겠습니다만, 개발팀에서 더이상 리소스를 투자하지 않고 XE3에 집중하겠다는데 어쩌겠어요 ㅡ.ㅡ;;

저도 실험해 보고 싶은 것이 엄청나게 많지만 그냥 묻어두고 있습니다. 차라리 관심있는 사용자들이 XE 1.x를 fork해서 다른 이름을 붙이고 다른 방향으로 나가버린다면 가능성이 있을지도 모르겠네요. 개발팀이 정말로 XE3에만 집중할 생각이라면 오히려 fork하는 것이 나을지도 모릅니다.

[kijin]

Proof of Concept를 실제 적용 가능한 방향으로 좀더 발전시켜 보았습니다.

• @wkpark 님의 Cache-Control 헤더 및 모바일 쿠키 처리 코드 적용
• 관리모듈의 고급 설정 페이지에서 "캐시 최적화" 옵션을 선택할 수 있도록 함
• 이 옵션을 선택한 경우 게시판에서 단순히 글을 읽는 것만으로는 세션이 시작되지 않도록 조치함 (조회수가 중복으로 집계될 가능성이 있으나, 실제 캐시서버를 사용한다면 오히려 조회수가 낮게 집계될 것입니다. 관리모듈에 주의사항으로 분명히 적어두었습니다.)

게시판 스킨이나 레이아웃에서 특별히 세션을 건드리지 않고, 비회원이 댓글을 쓸 수 있도록 설정하지 않았다면, 여기까지만 적용해도 캐싱 효과를 톡톡히 볼 수 있습니다. (글이나 댓글을 쓰기 위해 에디터를 로딩하거나 추천/비추/신고 등을 하면 로그인 상태와 관계없이 즉시 세션이 시작됩니다.)

[YJSoft]

@kijin 이 PR 적용후 Varnish 캐시서버를 적용하고 관리자 화면에 들어간 뒤 사이트 메뉴 편집을 누르면

이렇게 success라는 메세지가 뜹니다.

[kijin]

@YJSoft 방금 커밋한 것으로 다시 테스트해 보시겠어요?