Dump Cookie

최근에 엔하위키 속도 문제에 관련되어서 모니위키를 업데이트하게 되었고,

관련 작업이 모니위키 개발자 버전에 반영되었으며, 차일 피일 미루던 모니위키 1.2.0 릴리스 준비를 하고 있습니다.

엔하위키가 느린 점에 대해서 말들이 많았는데,

현재 엔하위키에는 간단한 몇가지 속도 패치가 적용된 상태입니다.

- 페이지 캐싱 활성화 - 모니위키 1.1.3부터 지원하였던 이 기능을 비로소 최근에 활성화 시켰습니다.

- 모니위키 1.1.5부터 지원했던 랜덤 페이지 전용 페이지 목록 인덱싱 기능을 활성화 시켰습니다.

- 기타 페이지 목록이 빈번하게 갱신되던 문제를 해결한 패치를 적용시켰습니다.

현재 엔하위키는 그나마 예전보다는 나은 속도를 내고 있습니다만 여전히 다음과 같은 문제가 있습니다.

1. 전체 페이지 리스트가 여전히 빈번하게 갱신되고 있다.

  - 현재 랜덤페이지에 의해서 사용되는 전체 페이지 목록을 가져오는 부분이 문제가 있는 듯 여전히 전체 페이지 목록이 자주 갱신되고 있습니다.

  - 이 문제는 패치 자체 버그로 보입니다. 그러나 예전보다 크기가 작고 빠른 속도로 갱신이 되어서 큰 문제를 느끼지 못하고 있는 듯.

2. 검색 - 역링크 / 제목검색 / 본문검색 포함

  - 현재 DBA 인덱서 패치가 추가로 엔하위키에 적용된 상태이지만 몇가지 문제로 사용되지 않고 있습니다.

  - DBA 인덱서를 적용한다 하더라도 역링크 및 제목검색은 상당히 빠르지만 본문검색은 적게는 수초가 걸리고 그 이상으로 느린 경우도 있습니다.

  - 인덱서 패치를 적용했는데 오히려 제목 목차가 느려졌습니다. (효율적이지 않은 제목 인덱싱)

이러한 문제를 해결하기 위해서

1. DBA를 사용한 본문/제목/링크 등등의 인덱싱 처리를 일차적으로 최적화 과정에서 배제시켰습니다.

2. 본문 검색보다는 제목 검색에 초점을 두었습니다. 본문 검색은 외부 검색엔진을 도입하는 것이 여러모로 나을 것으로 생각되며,

3. 전체 페이지 목록을 갱신하는 부분을 모듈화하고, 일단 매우 간단한 구현을 하였습니다. (기존의 페이지 목록 인덱서 개량)

4. 페이지 내용 검색(Fulltext search) 및 이와 관련된 느린 검색에 대해서 일단 시간 제한 혹은 개수 제한을 걸고 페이징 처리를 하도록 하였습니다.

이렇게 방향을 변경하고 다음의 작업이 진행되었습니다.

1. 전체 페이지 목록을 한꺼번에 갱신할 필요가 아예 없게 만들었습니다.

 - 랜덤 페이지 이외에 전체 페이지목록이 필요한 부분에 대해서 통합하고

 - 느린 전체 페이지 갱신을 아예 할 필요가 없게 만들었습니다. (페이지 추가/제거/이름 변경시에 전체 리스트를 업데이트만 함)

 - 이는 기존의 페이지이름 인덱서를 업데이트한 것입니다.

2. 역링크는 이제 검색이 아닙니다.

 - 역링크를 검색기능이 아니게 되었습니다.

  (그런데 모니위키의 역링크는 그 구현상 원래부터 검색이 아니였습니다 ^^;; 이번에 버그를 잡았습니다.)

 - 역링크는 페이지가 만들어지거나 갱신될 때에 즉각적으로 아주 빠르게 갱신됩니다.

 - 실제로 역링크를 사용시에는 그냥 역링크 정보를 가져오기만 합니다.

3. 페이지 이름검색이 빨라지고 유연해졌습니다.

 - 공백이 들어있거나 공백이 아예 없거나, 특수문자가 일부 들어간다고 해도 잘 찾아냅니다.

 - 특별히 이름 검색에 대해서 인덱싱 처리하거나 하지 않는데도 20만 페이지 규모에서도 매우 빠릅니다.

4. 본문 검색에 시간 제한을 걸고, 페이징처리를 하였습니다.

 - 일단 본문검색에 대해서 이러한 방식으로 처리하여 서버에 줄 수 있는 부담을 최소화했습니다.

일단 이러한 일련의 대규모 위키사이트에 대한 작업은 모니위키 1.2.0 개발자 버전에 대해서 진행중입니다.

참고적으로 로컬로 측정한 아파치 벤치마크 값입니다.

- 모니위키의 경우 19만 페이지가 있습니다. / 도쿠위키는 전체 10페이지 미만.

- 페이지는 단순한 HelpContents 페이지를 기준으로 삼았습니다. (static html은 그 랜더링된 결과)

- ab -c 2 -n 500을 기준으로 했습니다. (단순 측정값입니다.)

- 서버사양 AMD dual core 5200 / 2GB 램

static html의 경우 ~1000RPS

모니위키 1.2.0 개발판의 경우 ~300RPS (eaccelerator + 내장 캐시 사용)

모니위키 1.1.5 구버전의 경우 ~220RPS (eaccelerator + 내장 캐시)

도쿠위키 2012-10-13일 판 ~120RPS (eaccelerator + 내장 캐시 사용)

(미디어위키는 기본 설치 설정으로는 너무 느려서 논외.)

모니위키 1.2.0 최신 개발자 버전 맛보기 (임시적으로 엔하위키 19만 페이지가 읽기 전용으로 되어있음)

http://moniwiki.kldp.net/moniwiki/wiki.php

및 모니위키 github 사이트

https://github.com/wkpark/moniwiki

http://moniwiki.kldp.net/wiki.php/MoniWikiFeatures/1.2.0 그밖에 모니위키에 포함될 새로운 기능들

XE 게시판과 위키를 연동하는 경우

위키 링크라던지 위키에 관련된 기능이 게시판에도 필요한 경우가 종종 있습니다.

([[위키백과]]같은 위키 링크)

이 애드온은 위키의 링크를 손쉽게 연결시켜 주는 xe 게시판용 애드온입니다

이와 관련된 기능은 xe 사이트의 애드온을 찾아보면 이미 있습니다. (wikilink로 검색하면 몇 개 나옴)

여기서 소개하는 애드온은 위키네임을 링크시켜주는 기능 말고도 모니위키에서 지원하는 일부 기능인 URL을 고쳐주는 기능이 같이 들어있습니다.

예를 들어서 http://rigvedawiki.org/r1/wiki/FrontPage 같은 식으로 예전 링크가 있다면 이것을 rigvedawiki.net으로 고쳐서 자동으로 보여줍니다.

급조한 것이지만 xe 1.7에서 아무런 문제없이 동작하는 것을 확인하였습니다~

1.5에서도 문제없이 될 것으로 생각됩니다.

아직 urlmapping은 xe 사이트에 정식등록한 상태가 아닙니다.

urlmapping 애드온은 위키 관련된 링크를 고쳐주거나 하는 애드온이므로 이것과 관련된 기능 제안을 환영합니다~

TODO

- 인터위키 연결 지원 외

스크린샷 (관리자 메뉴)

다운로드

urlmapping-0.1.tar.gz

어나니머스의 우리민족끼리 해킹으로 소란스럽습니다. 관련 링크를 한번 모아보았습니다.

• http://htmlpaste.com/a632c09068de1af2ea20d2f4f74cd081a74b3000 최초 공개 예고
• http://pastebin.com/4g44jfNF 최초 1차 공개 (아래 1차공개 링크)

1차 공개

• http://pastebin.com/C91UxMSW
• http://pastebin.com/tz81U2FM
• http://pastebin.com/pqz68sd9

2차 공개

• http://pastebin.com/NheFNZ36
• http://pastebin.com/QtDSc5v6

1차 공개된 회원 리스트 포맷은 다음과 같습니다. 맨 상단의 몇줄만 여기에 써보면 다음과 같습니다.

userID,sex,name,email,birth,country,signDate,password
adminkus,M,관리자,urimanager@xxxxxxxx.com,19771224,8,20040414,9db81750e9058a339f3dbee7f4a19390 (kusxxxxx)
1234567890,M,아침,133@q.com,19720103,8,1088641164,827ccb0eea8a706c4c34a16891f84e7b (12345)
sgxxxx,M,ㅅㄱㅎ,jshxxxxxxx@hotmail.com,19790812,9,1087541426,3eeec6e35b8d779ce5caebc70c6be89b

맨 첫번째로 공개된 사용자가 관리자!! 생년월일과 signDate 그리고 비밀번호에 해당 비밀번호를 크랙한 비밀번호까지 나옵니다 -_-;; (엉터리 이메일 주소는 그대로 두고, 의미 있는 듯한 이메일주소는 지웁니다)

그런데 두번째 라인의 사용자 ID는 "1234567890"이라는 엉터리 아이디에 메일 주소또안 133@q.com과 같은 엉터리 이메일 주소, 비밀번호도 "12345"라고 되어있어 이 사용자는 "가짜 사용자"라는 것을 보여주고 있습니다.

여기서 잠깐. signDate는 무엇을 의미할까요?

세번째 사용자의 비밀번호는 크랙이 되지 않아있고 실명일 가능성이 있는데 (이메일 및 아이디는 x로 처리했습니다.) 세번째 사용자의 signDate는 1087541426이며, 이 값은 unix timestamp로서 "Fri, 18 Jun 2004 06:50:26 GMT" 입니다. 2004년도에 등록을 했다는 뜻 같습니다.

엉터리 이메일주소의 가짜 회원들

그런데 쭈욱 보다보니 다음과 같은 엉터리도 많습니다.

kooma77,M,원빈,ljlfajglajk@dfklghsdflajgkal.com,20001010,9,1088912541,398bb4d9a15db2d8bf52b9ca9c8538ee (0601)

kooma77이라고 등록한 이 사용자는 자신의 이름을 "원빈"이라고 해놓고 엉터리 이메일 주소에 생년월일도 2000년10월입니다. (2004년에 사용자 등록을 했는데 생년월일이 2000년..)

이 즈음에서 우리민족끼리의 사용자 관리 수준이 여실히 드러납니다.

이메일이 제대로 된 이메일인지도 확인하지 않고 있는 것입니다. 또한 사용자 등록을 한 사용자가 진짜 본인인지, 아니면 이름과 이메일 주소를 도용한 사람인지를 전혀 분간하지 못하고 있다는 사실도 아주 쉽게 알 수 있습니다.

이정도 수준의 사용자 관리를 하고있는 사이트를 털어, 그 명단을 공개해서 대체 뭘 얻을 수 있을지 의심이 드는 부분입니다.

중복 사용자

회원 관리가 이정도 수준이니 중복사용자도 금방 보입니다. 다음과 같은 경우는 중복해서 5번이나 가입했습니다. 그것도 엉터리 이메일주소로

pakyu,F,pakunjong,pakuj@.615,19921014,<blank>,1155300029,b45570328dc3d4885b13607b7e6952ff
pakur,F,pakunjong,pakuj@.615,19921014,<blank>,1155300171,b45570328dc3d4885b13607b7e6952ff
kimyu,F,pakunjong,pakuj@.615,19921014,<blank>,1155359081,b45570328dc3d4885b13607b7e6952ff
paksu,F,pakunjong,pakuj@.615,19921014,<blank>,1155367013,b45570328dc3d4885b13607b7e6952ff
gftruygjhg,F,pakunjong,pakuj@.615,19921014,<blank>,1155382803,b45570328dc3d4885b13607b7e6952ff

이정도 수준의 회원 명단을 가지고 떠들썩한게 한심하기도 합니다.

마치며

2차로 공개한 맨 마지막 회원 명단이 인상적입니다

jjh30008,M,Kimpig,Fuckyou@asshole.com,1044444444,201211,2013-03-30 00:00:00,<blank>,1364569200,89e3f0a39209cd42f0db5b8c2a39d3bf