Dump Cookie

PHP 경험이 많은 분들이라면 한번정도는 PHP 확장 모듈을 만들어 보았을 것이다. 본인의 경우는 비로서 최근에 PHP 확장 모듈을 만들어 보았는데 다음의 내용이 게중에 가장 쉬웠다. 뚝딱 테스트 해보는데에 20분이면 충분했다.

http://devzone.zend.com/303/extension-writing-part-i-introduction-to-php-and-zend/

위 사이트에서 복사해서 붙이기만 하고 최초 작동 테스트 완료 하는데에 20분 걸렸으니, 더 간단하고 쉬운 문서를 만들면 좋겠다 싶어서 문서를 더 찾아보았다. 그래서 찾은 문서는 exman으로 유명한 박준철님이 작성하신 다음 문서이다. (박준철님의 사이트는 닫혀있었으나 문서는 다른 곳에서 찾을 수 있었다)

http://srctalk.imfree.co.kr/view.ife?seq=268

이 문서의 특징은 PHP로 확장모듈을 만드는 프로그래머가 실제로 확장 모듈을 만들게 될 상황에 맞춰서 구성되었다는 점이다.

그리고 또 찾은 문서는 다음과 같은데, 문서가 길지 않고 매우 짧고 쉬워서 그대로 따라하기 쉽다.

http://eddmann.com/posts/introduction-to-creating-a-basic-php-extension/

이정도 문서만 참고하더라도 10분안에 나만의 PHP 확장을 만들고 최소한의 테스트를 완료할 수 있을 것 같은데, 열거한 문서를 읽어본 사람이라면 다음의 내용을 따라해서 좀 더 빨리 확장 모듈을 만들어보고 테스트 할 수도 있다.

스크립트 실행 준비

먼저 원하는 디렉토리로 위치로 가서 새로 디렉토리를 만든다음 그곳에서 스크립트를 실행시킬 준비를 한다. 이때에 적절한 프로젝트 이름을 생각해둔다. 여기서는 그 이름을 foobar로 하겠다.

cd ~/home
mkdir php-foobar
cd php-foobar

스크립트 받기

디렉토리에 들어가서 (여기서는 php-foobar) 다음과 같이, 복사하고 붙이기를 최소화 하기 위하여 미리 만들어둔 쉘 스크립트를 다운로드 받아서 압축을 푼다.

php_ext.sh.gz

이 스크립트는 PHP 소스에 포함되어있는 ext_skel 스크립트와 하는 기능은 거의 같지만, 더 단순한 기능만 하고, 실행 즉시 곧바로 아무것도 건드리지 않고 phpize를 통해 컴파일 할 수 있다는 점이 다르며, skeleton 디렉토리에 의존하는 스크립트가 아니기때문에 아무데서나 사용할 수 있다.

스크립트 압축 풀기

스크립트의 압축을 푼다.

gunzip php_ext.sh.gz

스크립트 실행

디렉토리에 들어가서 (여기서는 php-foobar) 다음과 같이 스크립트를 실행시킨다.

sh php_ext.sh foobar

그러면 config.m4, foobar.c, php_foobar.h 세개의 파일이 생성된다.

컴파일하기

콘솔에서 phpize를 실행하면 각종 파일이 자동으로 생성되며, configure를 실행하고 난 후에 make 한다.

phpize
sh configure
make
...

테스트하기

콘솔에서 다음의 명령을 실행시켜보자

php -dextension=.libs/foobar.so -r "foobar_world('hello');"

화면에 "Hello hello"라고 뜨면 정상 작동한 것이다. 테스트 종료.

아마 이대로만 정확히 따라했다면 5분안에도 만들고 테스트 완료 했을 것이다. 그러나 원하는 기능을 만들기 위해서는 이제 몇십배 더 많은 시간을 투자해야 할지도 모른다!!

그간 몇차례 그누보드4를 설치하고 사용자 모듈을 만들어보려고 시도를 했었습니다. 그런데 그누보드4가 short open 태그여서 수정하기 귀찮음으로 그만두고는 하다가, 이번에 간단한 스크립트를 돌려서 short open 태그를 모두 고친 후에 설치를 하고 사용자 모듈을 만들어 봤습니다.

사용자 모듈은 다음과 같은 형태입니다.

<?php

class User_g4 extends WikiUser {

    function g4_init() {
        global $g4, $member, $g4_root_dir;

        $g4_root_dir = !empty($DBInfo->g4_root_dir) ?
                $DBInfo->g4_root_dir : __DIR__.'/../../../gb4';

        require_once('g4.common.php');
        $member = g4_get_member();
    }

    function User_g4($id = '') {

여기서 g4.common.php는 그누보드의 루트 디렉토리에 있는 common.php를 간소화시킨 버전으로 다음과 같은 형태입니다.

<?php
/**
 * simplified common.php by wkpark @ gmail.com
 * 2015/04/29
 */

function g4_get_member() {
    global $g4, $g4_root_dir;
...
include_once("$g4_root_dir/lib/constant.php");  // 상수 정의
include_once("$g4_root_dir/config.php");  // 설정 파일
include_once("$g4_root_dir/lib/common.lib.php"); // 공통 라이브러리
include_once("$g4_root_dir/dbconfig.php");

$connect_db = sql_connect($mysql_host, $mysql_user, $mysql_password);
$select_db = sql_select_db($mysql_db, $connect_db);
...

이런 식으로 연결을 한 후에 그누보드 함수 get_menber()로 사용자를 가져오게 됩니다. 자세한 내용은 소스를 참고하시기 바라며, 소스 다운로드 및 사용 설명은 http://moniwiki.kldp.net/wiki.php/G4UserPlugin.를 참조하시기 바랍니다~

리그베다위키의 전신 엔하위키를 본인이 처음 봤을때가 아마도 2008년정도 였을것이다. 그때는 "아... 이런 희안한 사이트도 있구나"라는 정도로 스쳐지나갔다가, 한 2년 후에 다시 보게 되었을때는 거의 ~8만여 페이지 규모의 국내 최대 모니위키 사이트가 되어있었다. 규모에도 놀랐지만 너무 너무 느려서 더 놀랬던 것으로 기억한다. 검색은 당연히 먹통이고, 반응 속도가 너무 느려서 이대로 두면 안되겠다 싶어서 위키 게시판에 글을 올렸고, 병목현상을 일으키던 부분을 찾아내어 수정하고 모니위키 1.1.5 개발자판으로 판올림을 했던 것으로 기억한다.(2010년 10월) 그 당시 엔하위키는 모니위키 렌더러에 자잘한 수정을 하고 (버그 수정 포함), 일부 사용자 관리/필터링 등등의 일부 기능을 추가 했을 뿐이라서, 엔하위키측에서 제공한 모니위키 변경분에 대해서 선별적으로 적용하고 추가적으로 여러 수정을 해서 모니위키 1.1.5 버전이 나왔고, 엔하위키 관리/운영진은 이를 바탕으로 어렵지 않게 판올림을 하였고 정상적인 속도도 나오게 되었다. 그 뒤에 엔하위키 사용자의 피드백을 받아서 모니위키 1.1.6CVS 개발판이 나왔다.

https://kldp.org/node/118619 참조

1.1.5 판올림 당시 구 엔하위키게시판에 올라온 짤방

그러다가 다시 15만~20만 페이지 규모가 되었던 시점이었을때에 또 다시 엔하위키는 느려져 있었고, 또 다시 병목현상의 원인을 찾아 수정하고 모니위키 1.2.0 판올림도 같이 병행하였다. (2013년 8월)

당시 병목 현상의 원인은?

2010년 당시 5만여 페이지 규모였을때에, 병목현상의 원인은 사실 별거 없었다. 매크로중에 페이지 개수를 카운팅하는 기능이 너무 느렸던 것이었다. 엔하위키의 경우 페이지 개수 표시가 오른쪽 사이드바에 항상 표시가 되었다. 그런데 카운팅 매크로는 5만여 페이지의 목록을 모두 가져오고 그것의 개수를 매번 세었던 것이였다. 그래서 이 부분에 대해서 페이지 개수를 보다 효율적으로 세도록 고치고, 페이지 개수 정보를 캐싱하게 만들었다. 그밖에 여러 개선과 수정이 물론 있었지만 이 변경이 구 엔하위키의 속도를 원상복구 시키는 주요한 고침이였다. 그밖에 5만여 페이지 규모에서도 문제없도록 간단한 n-gram 인덱서를 추가해서 5만여 페이지 규모의 위키에서도 본문 검색을 할 수 있도록 만들었다.

2013년 8월의 고침도 사실 따지고 보면 대동소이했다. 페이지 개수 세는 부분을 보다 영리하게 만들고, 전체 페이지 목록을 매번 가져올 것이 아니라 주기적으로 업데이트 하고, 페이지 삭제/추가시 페이지 개수를 부분 업데이트 하도록 고쳤다. 물론 1.2.0 판올림의 경우에는 모니위키의 캐싱 방법을 더 뜯어고쳐서 대규모 위키에 문제 없도록 하는 등등의 여러 고침도 함께 포함하고 있었다.

DBMS vs 파일 시스템

많은 사람들이 말하기를 모니위키가 DBMS 기반이 아니라서 대규모 위키 대응이 불가능할 것이라 하지만, 사실 위키의 경우에는 flat한 key-value 구조라서 DBMS보다는 NoSQL이 더 유리하고, key-value구조는 파일 시스템 친화적이다. git/cvs/rcs같은 훌륭한 버전컨트롤 시스템이 모두 파일 기반이며 이를 그대로 써먹을 수 있다. 특히 RCS의 경우는 각 페이지별로 버전 히스토리가 별도로 저장되므로 위키엔진의 버전 컨트롤용으로 적합하다. 미디어위키처럼 DBMS로 구현하는 경우에는 버전 컨트롤을 다시 구현해야 한다. (또한 미디어위키는 여러 이미지 자료들을 DBMS로 저장하거나 하지는 않으며 이미지 자료는 파일시스템에 저장하는 방식을 여전히 쓰고 있다.) 그러나 모니위키의 경우처럼 파일기반인 경우에는 버전컨트롤을 RCS와 같은 외부프로그램이 별도로 담당하고 있어서 따로 구현할 필요가 없다. 위키엔진은 페이지 이름에 해당하는 페이지의 최종 버전을 가져와서 렌더링해서 뿌려주면 그만이다. 페이지 이름이 고유한 key-value구조라서 NoSQL에 대응하기 어렵지 않다. 위키 규모가 100만페이지 이상이 되더라고 대응이 그리 어려운 일이 아니라는 얘기다. 리눅스의 경우 파일시스템의 성능이 비약적으로 좋아졌다는 사실도 한몫 하고 있다. 버전 정보는 파일시스템으로 저장하고, 프론트엔드 단에서는 NoSQL을 써서 최종 버전을 저장하고, 검색은 elastic 검색 엔진을 쓰면된다. (모니위키는 이미 개발판에 elastic 검색 엔진을 실험적으로 넣었다. 가까운 미래에 NoSQL 백엔드를 만들게 될지도 모르겠다)

미디어위키는 훌륭한 위키엔진이다. 그러나 이것을 개인사용자가 사용하기 적합할까? 미디어위키를 처음 설치해보고는 그 속도가 생각보다 느리다는 사실에 놀랬었다. 미디어위키의 경우 자신의 위키 규모에 맞춰서 적절하게 설정을 해주어야 한다. (미디어위키의 속도를 향상시키는 법은 다른 글 #1 #2 참조.) 도쿠위키도 아주 좋은 위키엔진임에 분명하다. 파일기반이라서 단촐하고 개인사용자에게 적합하다. 그런데 본인의 테스트에 의하면 5천 페이지 정도만 되어도 쉽게 대응할 방법을 찾지 못하였다. 물론 개인위키 사용자라면 1천 페이지 만들기도 어렵기때문에 사용하는데 지장이 없을 것이다.

엔하 미러의 속도와 비교

종종 리그베다 본관의 속도와 엔하미러의 속도가 비교대상이 되고는 하였다. 사실 엔하미러의 속도는 상상을 초월할 정도로 빠르다. 엔하미러가 얼마나 빠르냐 하면, 로컬에서 아파치 벤치로 속도를 측정한다고 했을때에 거의 static html 페이지 속도급으로 빠르다. 이정도로 빠르기때문에 사실 엔하미러 속도를 다른 위키엔진과 비교하는 것은 무의미할 수 있다. 모니위키의 속도는 여러 최적화 옵션을 키면 엔하미러의 속도의 1/10에 해당한다 보면 된다. 사양에 따라 다르겠지만 로컬에서 static html 속도가 ~2000RPS 정도라고 한다면 모니위키의 경우에는 ~200RPS이다. (만약 모니위키를 아파치서버 + varnish 캐싱 서버와 함께 사용하면 ~7000RPS 정도로 올라가게 된다.)

그렇다면 미디어위키의 속도는 어떨까? 기본 설정으로 설치가 끝난 상태에서는 서버사양에 따라 달라지겠지만 위에서 언급한 것처럼 static html이 ~2000RPS정도 나온다고 했을때에 미디어위키는 ~5RPS도 안된다. 최적화 옵션을 켜면 ~10~15RPS 수준으로 올라간다. (이 경우도 아파치 + varnish캐시서버를 사용하면 비약적으로 빨라지게 되는데 자세한 내용은 미디어위키의 문서를 참고하라)

마치며

지금은 상당히 좋은 위키 엔진이 많이 있기때문에 모니위키의 인기가 많이 사라진 편이지만, 모니위키가 최초 나왔을 무렵 노스모크의 위키 엔진이었던 python으로 구현된 모인모인의 클론을 표방하고, 웹 호스팅에 좀 더 유리했던 PHP로 새롭게 작성했었다. 모니위키는 기존의 모인모인을 금방 대신하여 자리를 차지하게 되었고, 한동안 모니위키는 개인위키 사용자들의 대세였던 적도 있었다. 뿐만 아니라 지인의 증언(?)에 의하면 모니위키는 많은 회사 인트라넷에서도 사용되어졌고 처음 위키위키를 사용하는 사용자들에게 영향을 끼쳤다.

모니위키는 여전히 개인위키를 지향하며, 코어 코드를 좀더 줄이려고 노력하고 있다. 그러면서도 리그베다위키의 규모에 대응하기 위해서 확장이 보다 손쉽도록 개선하고 있으며, 최근에는 마크다운의 문법과 거의 유사한 것에 착안하여 마크다운 문법을 섞어서 쓰더라도 문제가 없도록 MixDown 파서를 개발하고 테스트하였고 한편으로는 기존 모니위키 문법 파서를 재작성 및 테스트 하였다.

개인 사정으로 2014년 거의 개발 중단 상태였다가 다시 모니위키 소스를 건드리고 있는데, 모니위키가 앞으로 어떠한 방향으로 개발되게 될지는 나도 장담하지 못하겠지만, 리그베다위키가 사라지지 않는한, 일부 개인 사용자의 피드백이 지속되고 있는 이상 계속 개발하게 되지 않을까 생각한다.

다음에는 리그베다위키와 그 클론들에 대한 이야기와 전망에 대해 써보려 한다.