리뉴얼 초반에 한번 의견을 냈었던 부분인데..



아주 기술 적인 부분이라, 언급을 자제하던 부분이지만,



와싸다의 속도 문제랑 직접적으로 관련이 있을 듯 하여 적어 봅니다.



현재 와싸다에서 매뉴의 상당부분이 happy_imgmaker.php라는 php를 통해서 그림으로 전달되고 있습니다.



매뉴뿐만 아니라, 여기저기 많이 사용되고 있는것으로 보입니다.



제가 보기엔 이 happy_imgmaker.php가 서버와 저사양 PC에 주는 부담이 상당합니다.



1. 이미지 생성 관련



우선 happy_imgmaker.php의 내부 구조를 모르기때문에 이 부분은 제가 틀릴 수도 있습니다.

다만, 신경써서 만들어 서 캐싱 구조를 정확하게 가진것이 아니라면,

일반적으로 이미지를 생성하는 php는 매번 동일한 그림그리기를 반복합니다.



특히 경험상 텍스트를 출력하는 소스코드는 CPU나 메모리의 점유율이 다른 그래픽 작업에 비해 높은 편이므로,

매번 그리고 있다면, 상당한 부하를 줄 것입니다.



그리고 매번 그리지 않는 다면, 굳이 happy_imgmaker.php를 통해서 전달을 받을 이유가 없습니다.



2. 통신 포트 관련



서버나, 클라이언트에서 통신을 위해 사용할 수 있는 포트는 제한된 자원 입니다.

따라서 이미지나, 받아야 하는 파일의 숫자가 늘어나게 되면, 기존의 연결을 해지하거나, 기존의 회선을 이용해 선형적으로 이미지를 전송하는 방식을 사용해야 합니다.



어느쪽이든지 서버의 포트를 잡아먹는 데.. 현재 제가 볼때 와싸다는 서버의 설정으로 keep-alive의 설정은 켜져있지만, 실제 TCP/IP레벨에서 통신 소켓을 매번 닫게끔 되어 있어서 Keep-alive가 적용되고 있지 않습니다.



이러한 경우 다수의 사용자가 접속을 시도하게 되면, 동시에 열리는 다수의 클라이언트 요구를 포트 부족으로 인해, 받지 못하는 문제가 발생하게 됩니다.



3. 캐싱 문제



현재 happy_imgmaker.php는 내부적으로는 알 수 없으나 외부적으로는 항상 동적인 페이지 입니다. 따라서 아무리 사소한 내용이지만, 변경사항만 체크하는 것이 아니라, 매번 이미지를 새로 전송받고, 이로인해 클라이언트에서도, 새로고침 혹은 링크를 열때 마다, 새로 디코딩하고, 열어줘야 하는 부담이 발생합니다.



구버전의 웹브라우저라면, 이러한 부분에 대한 내부적인 캐싱이 없었지만, 최근에는 속도 개선을 위해 변경되지 않은 이미지 파일은 바로 재활용하는 수준의 캐싱을 합니다. 따라서 클라이언트의 랜더링 속도나, 서버-클라이언트 간의 네트워크 부하, 서버 내에서 캐싱 체크의  이상 3가지의 프로세싱 처리 문제를 종합적으로 볼때, 현재의 구조는 캐싱을 방해하는 요소 입니다.



----



이상이 제가 보는 큰 문제점이고, 



아주 간단한 해법은 기존의 happy_imgmaker.php로 생성된 이미지를 그냥 파일로 서버에 저장한 다음,

저장된 파일의 이미지를 가지고 서비스 하면됩니다.



더 손쉬운 방법은 아예 이미지 대신 text로 서비스하면 서버의 부하는 급격하게 줄어 들 겁니다.



와싸다가 매뉴 구성을 수시로 바꾸는 것도 아니고,  동적으로 이미지를 생성해서 서비스 할 이유를 모르겠습니다.



ps. 그리고 저번에 디비 에러로 우연히 본것이지만, 현재 매뉴 구성을 사용자 권한별로 배번 DB에서 긇어와서 뿌려 주는 것으로 보이는데,... 아직도 그런지 모르겠군요..

로그인 여부에 따라서 쓰기와 수정하기 이런것들을 쿼리 하는 것은 일부 이해가 됩니다만, 모든 회원에게 동일한 매뉴를 쿼리하는 것은 이해가 안됩니다.