Rev. 2.73

사고 발생 후 그 원인을 파악하기로 하였습니다. 호스트의 CPU 사용률을 확인할 수 없는 관계로 페이지 로딩속도를 근거로 측정하였습니다. 페이지 토탈 익스큐티드 타임이 3, 4초가 나오는 것을 확인하고 다른 곳과 비교하니 0.2, 0.3초대가 정상이라는 것을 알 수 있었습니다.

처음에는 디비에서 뽑아오는 출력 개수를 전체적으로 조정해 보았습니다. 복잡한 연산을 수행하는 인기글과 랜덤태그에서 가장 큰 차이를 보였으며, 랜덤태그 출력 개수를 100개에서 50개로 줄이고 사용 빈도가 낮은 인기도순 정렬기능을 일괄 제거하였습니다. 이리하여 2.0초대로 로딩 시간을 줄일 수 있었습니다.

두 번째로 커스터마이징 된 기능을 하나 둘 제거해보며 과부하 정도를 측정하였습니다. 딱 걸린 것은 바로 그래픽 카운터였습니다. 실시간으로 방문객 수를 그래프로 드로잉해주는 이 카운터는 dbid정보만을 가지고 오기 위해 inc_function.php와 inc_global.php 파일을 또다시 include합니다. 이 부분의 include를 삭제 후 디비 가져오는 곳을 't3_tts_10ofmg_count'로 변경해 주었더니 로딩속도를 0.3, 0.4초로 줄일 수 있었습니다.

끝으로 사고가 일어나기 전 마지막으로 했던 작업은 동적으로 패비콘을 표시하는 작업입니다. 이것은 댓글이 달리면 작성자의 홈페이지에 있는 패비콘을 표시해 주는 기능입니다. 이미 태터툴즈 OR에는 기본 플러그인으로 채택되어 있기도 합니다. fsockopen함수로 방문객의 홈페이지에 일일이 접속하여 파일의 유무를 판단하고 패비콘이 있으면 표시해 주는 것으로 처리 과정에서 상대 서버의 응답이 없거나 원인불명의 상태에서 발생한 사고였습니다.

굳이 php로 구현하고자 했던 이유는 이미지 태그의 비표준 코드인 onerror 속성이 사용되고 있어서였습니다. onerror 속성이 하는 일은 이미지가 정상으로 표지되지 않는 것(액박)을 감지하는 역할을 하고 오류가 발생했을 경우 자바스크립트와 연동하여 안 보이게 하거나 다른 이미지로 대체할 수 있습니다. 편리한 속성이긴 하지만 w3c는 비표준 태그로 규정하고 있습니다.

결국, 이러한 방법으로는 실패하였지만, 나중에 자바스크립트만으로 구현하는 방향으로 다시 도전해야겠습니다. php를 이용한 fsockopen 함수는 잘못 사용하면 과부하가 생기고 다운까지 된다는 사실을 알았습니다. 그런데, 이것은 SQL 과부하와는 상관없지 않나요? 아무튼, 호스팅 관리자분과 호스팅 서버를 함께 사용하고 계시는 200여 분들께 대단히 죄송합니다. 덕분에 종전에 비하여 100% 페이지 로딩속도 증가효과를 보았습니다. 이 골칫거리는 곧 이사할 예정이니 이제 안심하셔요... ㅠ.ㅠ

발전은 언제나 시행착오로부터 비롯되나 봅니다.

Comments