텍스트큐브 1.5의 세번째 이야기는 속도입니다.
많은 분들이 웹로그 프로그램으로서 가장 필요한 것이 무엇인가에 대한 고민을 합니다. 하지만 생각의 결과는 다양합니다. 편리한 기능들이 한가지 결론이 될 수가 있고, 텍스트큐브에도 그러한 고민의 결과가 담겨 있습니다. (앞의 소개 페이지들은 읽어 보셨죠?) 하지만 그것만이 전부는 아닙니다. 베타 버전 개발의 가운데에서 "앞으로 가장 중요한 것이 무엇이 될까"라는 질문을 하게 되었고, TNF의 개발 참여자들은 나름의 답을 얻었습니다.
개인 미디어는 지수적으로 성장하고 있습니다. 동시에 블로그 솔루션의 수요도 증가하고 있습니다. "블로그는 공공재여야 한다" 는 TNF와 니들웍스의 생각이 실제로 힘을 얻으려면 이후 급격하게 변화할 개인들이 주도가 될 웹에 대한 답을 내놓아야 했습니다. 그래서 베타 테스트의 중간 즈음부터 텍스트큐브에는 "설치형 블로그가 어떻게 엄청나게 빨리 증가하는 전송량과 연결 요구를 극복하고, 블로그의 주인들을 스스로 브랜딩하게 할 수 있을까" 라는 과제가 추가로 주어졌습니다.
그 결과로 텍스트큐브 1.5는 어느 정도의 성과를 얻었습니다. :)
수많은 사용자들이 소스를 편집하고 수정하는 텍스트큐브의 경우, 최적화는 굉장히 어려운 과제입니다. 소스 앞에서 이미 어떤 데이터가 읽혀졌는지 잘 모르기 때문에, 사람들마다 필요할 때 데이터베이스에 접속하여 정보를 읽어 사용하는 방식으로 소스를 작성하기 때문입니다. 플러그인의 경우까지 합치면 그 부분은 속도에 큰 영향을 줍니다.
동시에 텍스트큐브는 '범용성' 을 지향하고 있기 때문에 MySQL 3.23과 같은 오래된 데이터베이스 엔진도 '에뮬레이션'을 통해 지원하고 있습니다. 하지만 동시에 오래된 데이터베이스 엔진을 지원하기 위하여 더 나은 방향으로 최적화하지 못하고 있는 데이터베이스 요청 (쿼리) 명령들이 상당히 많이 있습니다. 오래된 데이터베이스 엔진들이 명령을 지원하지 않고 있기 때문입니다.
이러한 부분을 효율적으로 넘어보기 위하여 텍스트큐브에는 성능 개선을 위한 미리 읽기(캐시) 및 한 번만 읽기 기능이 추가 되었습니다. 몇몇 중요한 쿼리들의 결과를 메모리에 올려 놓고 재사용하여, 데이터베이스 접속의 수를 획기적으로 줄였습니다. 또한 블로그 페이지를 만들어 보여주기 위해 서버의 데이터베이스와 통신하는 경우, 각 요청들의 결과를 저장하여 이후 같은 요청이 올 경우 미리 읽어놓은 데이터를 사용하도록 변경되었습니다. 텍스트큐브의 데이터베이스 접속 클래스인 DBQuery를 사용하는 경우, 플러그인도 마찬가지로 미리 읽기의 효과를 얻을 수 있습니다.
이를 통하여 데이터베이스 엔진과의 통신량을 기존의 반 이하로 줄였으며, 통신에 소모되는 시간을 획기적으로 줄여 실제 페이지가 보여지는 응답속도를 크게 개선했습니다. 또한 이로 인하여 같은 시간동안 서버가 처리할 수 있는 량이 증가하였습니다.
데이터베이스 접속을 빈번하게 하여 생성하는 페이지의 경우에는 데이터 요청을 미리 저장하는 방식으로도 문제가 됩니다. 일례로 태그 페이지의 경우, 겹치는 데이터 요청이 거의 없습니다. 다중 사용자 지원을 위하여 태그와 태그 관계 테이블이 따로 관리되는 태터툴즈나 텍스트큐브의 경우 500개의 태그를 보여주기 위해서는 기존에는 1000번 이상의 데이터 요청이 필요했습니다.
이러한 페이지들의 경우 텍스트큐브는 페이지 캐시 기능을 이용하여 페이지를 만들어 파일 형태로 저장합니다. 태그 페이지를 예로 들면, 페이지를 보여준 후 그 페이지의 내용을 서버에 파일로 저장해 두고 이후에 요청이 있으면 데이터베이스 접속 대신 바로 그 파일을 이용합니다. 그래서 태그가 천 개든 이천개든, 처음 한 번만 요청하고 이후에는 데이터베이스와의 통신은 딱 한 번으로 줄어들게 됩니다.
이러한 기능을 컴포넌트로 내장하였으며, 플러그인에서도 필요한 경우 아주 쉽게 페이지 미리 읽기를 불러 사용할 수 있습니다. 예를 들어 블로그 센터를 플러그인으로 구현한다고 했을 때, 화면이 불러질 때 마다 플러그인이 매번 데이터베이스와 통신하여 화면을 만드는 대신 페이지 미리 읽기 컴포넌트를 불러 파일에서 바로 화면을 불러서 보여줄 수 있습니다.
원한다면 어떤 부분에도 페이지 미리 읽기 컴포넌트를 붙일 수 있지만 조심해야 할 부분이 있습니다. 가끔은 데이터베이스에서 읽는 것이 더 빠를 경우도 많습니다. 텍스트큐브 1.5에서는 페이지 미리 읽기 컴포넌트를 태그 출력 및 카테고리 리스트 출력과 같은 일부분에 대해서만 사용하고 있습니다. 이후의 버전에서는 테스트 후에 적용될 폭이 늘어날 것입니다.
텍스트큐브 1.5에는 텍스트큐브 전용의 디버그 도구가 내장 되었습니다. 플러그인을 개발하거나 사이트를 더 최적화 하고 싶은 경우, 텍스트큐브 소스를 고치고 싶은 경우에 동작 상황이나 에러 여부를 추적하고 싶은 경우에는 간단하게 루트 디렉토리의 config.php 안에
관리자 화면이 돌아가는 것을 보고 싶다면
이 기능 이후에 TNF/니들웍스의 크리에이터 분들은 데이터베이스 접속 수 줄이기, 더 많은 데이터를 미리 읽기로 만들기, 느린 부분 없애기에 한참을 빠져서 정작 기능 업그레이드가 늦어졌다는 후일담이 있습니다. 결과적으로 데이터베이스 요청 수가 거의 반이 되었습니다. 여러분도 한 번 시도해보세요! 참고로 회색으로 표시된 요청은 메모리에 미리 저장되어서 데이터베이스와 통신하지 않았다는 의미입니다.
이러한 문제를 해결하기 위하여 텍스트큐브 1.5에서는 각 모델과 컴포넌트, 뷰들간에서 최소한으로 필요한 모듈만을 호출하도록 작성되었습니다. 이러한 부분을 통해 페이지를 만들 때 읽어야 하는 파일의 수를 최소한으로 유지하였습니다.
또한 다른 대안으로, 공개되어 있는 많은 서버 가속기들과의 조합을 테스트 하였습니다. 텍스트큐브 1.5는 PEAR 패키지의 모듈인 APC (Alternative PHP Cache)와 함께 잘 동작합니다. 또한 fastCGI 모듈 환경에서도 설치 후 config.php에 한 줄을 추가하여 쉽게 사용할 수 있습니다. 텍스트큐브 1.5의 최소 요구 사양이나 권장 사양은 DOC 디렉토리 안의 문서들에서 확인하실 수 있습니다.
속도의 개선및 서버 부하의 감소를 위한 여러 노력들이 있었습니다. 텍스트큐브 1.5에서 시도된 기능들도 있고, 아직 계획에 있는 기능들도 있습니다. 텍스트큐브 1.5에는 아직 속도의 개션을 위한 여지가 많이 남아 있으며 몇가지를 계속 테스트하고 있습니다. 버전이 올라갈 수록 빨라지는 프로그램! 이라는 즐거운 이야기를 들을 수 있도록 노력하겠습니다.
다음 소개는, (만약 소개 페이지가 계속 있을 수 있다면!) 텍스트큐브를 즐기는 몇가지 간단한 팁들을 소개하도록 하겠습니다.
많은 분들이 웹로그 프로그램으로서 가장 필요한 것이 무엇인가에 대한 고민을 합니다. 하지만 생각의 결과는 다양합니다. 편리한 기능들이 한가지 결론이 될 수가 있고, 텍스트큐브에도 그러한 고민의 결과가 담겨 있습니다. (앞의 소개 페이지들은 읽어 보셨죠?) 하지만 그것만이 전부는 아닙니다. 베타 버전 개발의 가운데에서 "앞으로 가장 중요한 것이 무엇이 될까"라는 질문을 하게 되었고, TNF의 개발 참여자들은 나름의 답을 얻었습니다.
개인 미디어는 지수적으로 성장하고 있습니다. 동시에 블로그 솔루션의 수요도 증가하고 있습니다. "블로그는 공공재여야 한다" 는 TNF와 니들웍스의 생각이 실제로 힘을 얻으려면 이후 급격하게 변화할 개인들이 주도가 될 웹에 대한 답을 내놓아야 했습니다. 그래서 베타 테스트의 중간 즈음부터 텍스트큐브에는 "설치형 블로그가 어떻게 엄청나게 빨리 증가하는 전송량과 연결 요구를 극복하고, 블로그의 주인들을 스스로 브랜딩하게 할 수 있을까" 라는 과제가 추가로 주어졌습니다.
그 결과로 텍스트큐브 1.5는 어느 정도의 성과를 얻었습니다. :)
한 번만 읽기
수많은 사용자들이 소스를 편집하고 수정하는 텍스트큐브의 경우, 최적화는 굉장히 어려운 과제입니다. 소스 앞에서 이미 어떤 데이터가 읽혀졌는지 잘 모르기 때문에, 사람들마다 필요할 때 데이터베이스에 접속하여 정보를 읽어 사용하는 방식으로 소스를 작성하기 때문입니다. 플러그인의 경우까지 합치면 그 부분은 속도에 큰 영향을 줍니다.
동시에 텍스트큐브는 '범용성' 을 지향하고 있기 때문에 MySQL 3.23과 같은 오래된 데이터베이스 엔진도 '에뮬레이션'을 통해 지원하고 있습니다. 하지만 동시에 오래된 데이터베이스 엔진을 지원하기 위하여 더 나은 방향으로 최적화하지 못하고 있는 데이터베이스 요청 (쿼리) 명령들이 상당히 많이 있습니다. 오래된 데이터베이스 엔진들이 명령을 지원하지 않고 있기 때문입니다.
이러한 부분을 효율적으로 넘어보기 위하여 텍스트큐브에는 성능 개선을 위한 미리 읽기(캐시) 및 한 번만 읽기 기능이 추가 되었습니다. 몇몇 중요한 쿼리들의 결과를 메모리에 올려 놓고 재사용하여, 데이터베이스 접속의 수를 획기적으로 줄였습니다. 또한 블로그 페이지를 만들어 보여주기 위해 서버의 데이터베이스와 통신하는 경우, 각 요청들의 결과를 저장하여 이후 같은 요청이 올 경우 미리 읽어놓은 데이터를 사용하도록 변경되었습니다. 텍스트큐브의 데이터베이스 접속 클래스인 DBQuery를 사용하는 경우, 플러그인도 마찬가지로 미리 읽기의 효과를 얻을 수 있습니다.
미리 읽기 적용에 따른 데이터베이스와의 통신 횟수 차이입니다. 태그가 200개인 경우를 기준으로 하였습니다.
이를 통하여 데이터베이스 엔진과의 통신량을 기존의 반 이하로 줄였으며, 통신에 소모되는 시간을 획기적으로 줄여 실제 페이지가 보여지는 응답속도를 크게 개선했습니다. 또한 이로 인하여 같은 시간동안 서버가 처리할 수 있는 량이 증가하였습니다.
페이지 미리 읽기
데이터베이스 접속을 빈번하게 하여 생성하는 페이지의 경우에는 데이터 요청을 미리 저장하는 방식으로도 문제가 됩니다. 일례로 태그 페이지의 경우, 겹치는 데이터 요청이 거의 없습니다. 다중 사용자 지원을 위하여 태그와 태그 관계 테이블이 따로 관리되는 태터툴즈나 텍스트큐브의 경우 500개의 태그를 보여주기 위해서는 기존에는 1000번 이상의 데이터 요청이 필요했습니다.
이러한 페이지들의 경우 텍스트큐브는 페이지 캐시 기능을 이용하여 페이지를 만들어 파일 형태로 저장합니다. 태그 페이지를 예로 들면, 페이지를 보여준 후 그 페이지의 내용을 서버에 파일로 저장해 두고 이후에 요청이 있으면 데이터베이스 접속 대신 바로 그 파일을 이용합니다. 그래서 태그가 천 개든 이천개든, 처음 한 번만 요청하고 이후에는 데이터베이스와의 통신은 딱 한 번으로 줄어들게 됩니다.
응답속도의 차이입니다.
이러한 기능을 컴포넌트로 내장하였으며, 플러그인에서도 필요한 경우 아주 쉽게 페이지 미리 읽기를 불러 사용할 수 있습니다. 예를 들어 블로그 센터를 플러그인으로 구현한다고 했을 때, 화면이 불러질 때 마다 플러그인이 매번 데이터베이스와 통신하여 화면을 만드는 대신 페이지 미리 읽기 컴포넌트를 불러 파일에서 바로 화면을 불러서 보여줄 수 있습니다.
원한다면 어떤 부분에도 페이지 미리 읽기 컴포넌트를 붙일 수 있지만 조심해야 할 부분이 있습니다. 가끔은 데이터베이스에서 읽는 것이 더 빠를 경우도 많습니다. 텍스트큐브 1.5에서는 페이지 미리 읽기 컴포넌트를 태그 출력 및 카테고리 리스트 출력과 같은 일부분에 대해서만 사용하고 있습니다. 이후의 버전에서는 테스트 후에 적용될 폭이 늘어날 것입니다.
디버그 컴포넌트 : 최적화? 오류 잡기? 플러그인 만들기?!
텍스트큐브 1.5에는 텍스트큐브 전용의 디버그 도구가 내장 되었습니다. 플러그인을 개발하거나 사이트를 더 최적화 하고 싶은 경우, 텍스트큐브 소스를 고치고 싶은 경우에 동작 상황이나 에러 여부를 추적하고 싶은 경우에는 간단하게 루트 디렉토리의 config.php 안에
requireComponent("Needlworks.Function.Debug");
를 추가하시면 새로운 세상이 펼쳐집니다.혹자는 이 한 줄을 일컬어 판도라의 상자라고 하였고, 이후 TNF/니들웍스는 보고 싶지 않은 것들을 수없이 보게 되었습니다...
관리자 화면이 돌아가는 것을 보고 싶다면
가장 아랫쪽에 못보던 부분이 생깁니다. 뭐지?
데이터베이스 접속 여부와 상태, 페이지를 만드는 각 시점에 따른 소요시간이 시간과 호출 경로등과 함께 출력됩니다.
저 노란 부분이 '느린 쿼리 Top 5'에 드는 데이터베이스 읽기 명령입니다. 빨간 바는 전체 페이지를 만드는 시간 대비 현재 시점을 보여줍니다.
이 기능 이후에 TNF/니들웍스의 크리에이터 분들은 데이터베이스 접속 수 줄이기, 더 많은 데이터를 미리 읽기로 만들기, 느린 부분 없애기에 한참을 빠져서 정작 기능 업그레이드가 늦어졌다는 후일담이 있습니다. 결과적으로 데이터베이스 요청 수가 거의 반이 되었습니다. 여러분도 한 번 시도해보세요! 참고로 회색으로 표시된 요청은 메모리에 미리 저장되어서 데이터베이스와 통신하지 않았다는 의미입니다.
가속기
태터툴즈 1.1.3을 소스 버전으로만 내놓기로 한 후 실제로 테스트 하였을 때, 체감 속도가 너무 느려지는 현상에 참여자들은 깊은 시름에 빠졌습니다. 결국 태터툴즈 1.1.3은 예전과 동일하게 함수들을 정리한 최적화 버전으로 내보내기로 결정하였습니다. 소스판과 달리 배포판은 각 부분마다 필요한 함수들이 모두 들어있는, 소스를 쉽게 알아보기 힘든 상태로 배포되어야 했습니다.이러한 문제를 해결하기 위하여 텍스트큐브 1.5에서는 각 모델과 컴포넌트, 뷰들간에서 최소한으로 필요한 모듈만을 호출하도록 작성되었습니다. 이러한 부분을 통해 페이지를 만들 때 읽어야 하는 파일의 수를 최소한으로 유지하였습니다.
또한 다른 대안으로, 공개되어 있는 많은 서버 가속기들과의 조합을 테스트 하였습니다. 텍스트큐브 1.5는 PEAR 패키지의 모듈인 APC (Alternative PHP Cache)와 함께 잘 동작합니다. 또한 fastCGI 모듈 환경에서도 설치 후 config.php에 한 줄을 추가하여 쉽게 사용할 수 있습니다. 텍스트큐브 1.5의 최소 요구 사양이나 권장 사양은 DOC 디렉토리 안의 문서들에서 확인하실 수 있습니다.
속도의 개선및 서버 부하의 감소를 위한 여러 노력들이 있었습니다. 텍스트큐브 1.5에서 시도된 기능들도 있고, 아직 계획에 있는 기능들도 있습니다. 텍스트큐브 1.5에는 아직 속도의 개션을 위한 여지가 많이 남아 있으며 몇가지를 계속 테스트하고 있습니다. 버전이 올라갈 수록 빨라지는 프로그램! 이라는 즐거운 이야기를 들을 수 있도록 노력하겠습니다.
다음 소개는, (만약 소개 페이지가 계속 있을 수 있다면!) 텍스트큐브를 즐기는 몇가지 간단한 팁들을 소개하도록 하겠습니다.
Trackback URL : http://notice.textcube.org/teaser/trackback/4
-
궁금한게 있습니다. 여기 티저블로그의 '티저' 뜻이 '살 마음이 내키게 하는 광고'의 뜻인가요? '어려운 일[문제]'의 뜻인가요?
-
전자 입니다~ ;)
-
-
흠... 웬일인지 오픈아디 로긴이 안되는데 아무 생각 없이 왔다가 디버깅 기능이 있는걸 보곤 놀랬습니다 ^^