오랜만에 확인해본 FeedBurner 통계

feedburner-collapsed

Google 사용량 통계 메일 (매달 오는듯?) 보다가 FeedBurner가 아직 살아있는 것 보고 반가운 마음에 (???) 들여다본 결과.

Google Reader가 2013년 7월 1일 부로 서비스 종료한 이후로 구독자 수 / 도달률 모두 거의 붕괴한 상황이다. 내가 블로그를 덜 읽고, 글도 덜 쓰게 된 것도 대충 저것과 유사한 흐름인 것 같기도 하구나 -_-a

Python 기반의 static page 생성기로 블로그를 옮기려는 중

원래 내 의도는 최근에 읽은 책 (=”해커를 위한 디자인 레슨”) 과 게임 (=”어쌔신 크리드 2 및 그 확장팩, 3″)에 대한 리뷰를 쓰려는 거였다.
하지만 블로그 관리자 페이지 로딩이 너무 느려서 — WordPress 버전이 올라갈 수록 더 심한듯? — 좀 괴롭다.

(일반 유저가 볼) 페이지 로딩 자체는 큰 차이가 없어서 그냥 쓸 생각이 많았는데 오늘 좀 추가 많이 기운 듯 하다.

그래서 Pelican 이란 도구를 다음과 같은 이유로 시도해봤다: (이 순서대로 고려한 것은 아님)

  • OpenSource
  • History가 길다 (+5yr)
  • 현재도 개발이 진행되고 있다
  • Python 기반
  • Markdown 지원 (rst가 주 언어지만)
  • WordPress import 지원

이걸 가지고 내 블로그를 import 해보니 몇 가지 문제가 있다: (WordPress 가 정의한 xml을 rst로 변환하는 도구가 포함되어 있다)

  • 멀티바이트 인코딩된 블로그 제목이면 rst 의 #### 이 부분을 짧게 계산해서 망한다. (글자 수를 세서 그런가)
  • 일부 글에서 글자를 해석 못해서 망하고 있음
  • 글 제목(정확히는 WordPress의 slug 값)을 이용해서 .rst 를 만드는데 urlencode 당한 문자열을 쓴다 -_-

딱히 다른 대안이 없으면 importer를 고치고 어떻게 해봐야겠다;

블로그 로딩 시간 줄이기

주말 저녁에 블로그 패이지 뜨는 속도가 이상하리만치 느려서 최적화하기로 결정했다 — 심지어 구글은 페이지 랭크에 로딩 속도를 반영한다.

사용한 도구는 Chrome용 Pagespeed 확장기능. 여기서 네트워크 탭을 이용해서 오래걸리는 기능을 하나씩 제거했다.
최적화 하기 이전 측정치는  다음과 같다.


WordPress JetPack 관련
이 플러그인엔 적어도 두 가지 문제가 있다. 우선 통계 플러그인이 제 3자인 quantcast 쪽에 js파일을 큰 쿠키를 던져 요청하고, 이걸 실행한다. 위에서 quant.js, pixel;… 에 해당하는 내용. 이게 적어도 500ms는 걸리더라. 이게 이전부터 꽤 이슈였던듯. Respecting User Privacy in WordPress에 따르면 2011년 초 이전부터 있던 일이란다. 이슈화돼서 그런지 이에 대한 방책도 있다. WP DoNotTrack이란 플러그인이 이에 해당하는 DOM 삽입을 차단해준다. 이걸 쓰면 이 500ms를 줄일 수 있더라.그리고 쓰지도 않는 gravatar hovercard관련으로 로드하는 js 파일도 지연시간이 꽤 큰 편. 게다가 css까지 로드 하는 시간을 생각하면 아주 악몽이다. 저 위에선 6초 넘게 날려먹었음. (분산도 커서 더욱 거지 같기도하고). 첫 js 로드도  길고, 얘가 로드하는 파일도 다운로드가 오래 걸리고…
하지만 이게 어이 없었던건 — 난 켜지도 않은 기능이니 — 데이터베이스에 원래 있어야 할 옵션이 없어서 그렇다. 다음 항목을 wp_options 테이블에 추가하면 됨. (wp 부분은 설치 설정에 따라 다름)

mysql> insert into wp_options (option_id, option_name, option_value) values (NULL, ‘gravatar_disable_hovercards’, ‘disabled’);

이걸로 적어도 500ms ~ 3000ms 정도를 벌 수 있다.

 

블로그 테마 관련

위의 두 가지를 제외하면 다음 내용들이 적당히 튀어나온다.

1. 블로그 내용 시작 부분에 Google Transliteration관련 스크립트를 로드하더라. 이건 내 블로그엔 필요 없는 듯 하니 제거. jquery도 구글 서버에서 가져오게 수정.

2. 서버의 vhost 중 내 블로그만 mod_pagespeed 를 적용해 봤다.[1] wp supercache가 문제를 일으키길레 일단 이 플러그인은 삭제. 그리고 .htaccess에서 켰던 mod_deflate 강제하는 것도 껐다. 어차피 mod_pagespeed가 따로 로드하고 적용함. 이거 적용한 후엔 html 타입으로 가는 컨텐츠에 각 파일 별 만료 태그, css sprite, caching등이 자동 적용된다. 약간은 빨라지는듯.

3. 최근 댓글 보여주는 것도 잠시 생각하고 껐다. 이건 이글루스 블로그들을 따라 해본던데 좀 별로인듯.

4. 더불어 CC라이센스 플레이트에 붙어있는 아이콘 이미지 로딩이 느리길레 역시 제거함.

 

최종 결과:

이 결과 대략 800ms ~ 900ms 정도에 페이지 로딩이 되고, 최종 렌더링도 1.3초 수준에 해결.

 

  1. 사실 캡쳐한건 이 모듈 적용 후임 []

Blog 재설치

WordPress의 비쥬얼 에디터가 제대로 동작하지 않아서 WordPress 자체를 재 설치. 이 글은 비쥬얼 에디터에서 쓰고 있다.

MS Windows에서 글 쓰는 거라면 Windows Live Writer가 워낙 훌륭해서 되거나 말거나 크게 신경 안 썼는데, 요즘 Windows 부팅하는 시간이 너무 적어서 결국 불편함을 못 견디고 재설치했다.

설치는 다음과 같은 순서로 진행했다.

  1. 기존 디렉터리 백업 (blog 디렉터리를 백업 디렉터리로 변경)
  2. 새로 설치 (svn checkout 으로 통채로 blog 디렉터리에 가져다 설치)
  3. 기존 설정 파일 복사 (wp-config.php, wlwmanifest.xml, .htaccess)
  4. 기존 테마 파일 복사 (wp-content/theme 디렉터리를 백업에서 blog로 복사)
  5. 기존 플러그인 복사 (wp-content/plugins 디렉터리를 백업에서 blog로 복사)
  6. 기존 이미지 파일 복사 (wp-content/uploads 디렉터리를 백업에서 blog로 복사)

만에 하나 있을지 모를 문제 때문에 캐싱 플러그인 (wp-super-cache는 비활성화 했음)

 

혹시 깨진 링크, 깨진 이미지, 비정상 동작하는 부분이 발견되면 댓글로 알려주시면 감사하겠습니다(…).

 

 

JetPack: WordPress.com의 기능을 설치 형 블로그에서도

WordPress는 GPL v3 에 따라 배포되는 Free/Open Source SW다. 이걸 개발하고 있는 Automattic은 설치 형 블로그로 WordPress를 제공하고, 이와 별개로 WordPress.com 을 통해 무료 및 유료 서비스도 한다. 얘네 핵심 사업 모델이 이 WordPress.com 인데, 설치 형 WordPress에서도 이 사이트에서만 제공되는 기능 중 일부를 쓸 수 있다. 예를 들어 WordPress.com 의 통계 기능[1] 을 설치 형 블로그에서도 그냥 쓸 수 있게 해준다 – 다만 무료라도 WordPress.com 계정이 있긴 해야 함. 스팸 댓글 혹은 트랙백을 막는 Akismet 의 서비스도 일정 규모 이하의 사이트에서는 공짜다. 더불어, wp.me 로 짧은 URL을 만들어주는 기능도 제공한다.

최근에 WordPress.com 에서만 제공되던 기능들 중 일부가 JetPack이란 이름의 플러그 인[2] 으로 새로이 제공되는 걸로 바뀌었다. 몇 가지는 기존에 서로 다른 플러그 인으로 존재하거나, WP.com 밖에서도 쓸 수 있게 해주던 것이고, 몇 가지는 내가 생각하기에는 구현 방식의 한계로 다른 프로그램 없이는 잘 안될 거 같은 기능이다. 예를 들어[3] 서버에 LaTeX이 있어야 적당히 돌 거 같은 \LaTeX 지원이라거나…

관리자 메뉴에서 실제 페이지는 이런 식이고, 통계나 공유 기능처럼 약간의 설정이 필요한 녀석들은 추가 메뉴가 들어있음.

jetpack-page

현재 지원되는 기능은 전부 무료고, “Coming soon…” 으로 표시된 자리가 있으니 앞으로 몇 가지 기능이 더 추가될 것으로 보인다. WordPress.com에서 현재 제공 중인 서비스 방식을 생각할 때, 추후에 추가되는 플러그 인, 혹은 JetPack 자체가 기간 당 사용료를 받는 모델로 전환될 가능성도 있는 것 같다. Akismet 처럼 소규모 사용자에겐 계속 무료일 수도 있고 말이다. 뭐 이건 어디까지나 내 추측; 이 기능들 중 상당 수는 WordPress 설치 자체에서 제공할 수 있는 기능도 아니고, 설치 형 사용자들도 원할만한 기능들이 꽤 많이 있으니, 앞으로 이것도 얘네 사업 모델의 일부가 될 것 같다. WordPress.com 을 몇 가지 이유로 안 쓰는 사람들도 꽤 있고, 그 중 일부는 그래도 WordPress.com의 일부 기능(통계, LaTeX, …)을 쓰고 싶어하니까 말이다.

그리고 이런 기능이 WordPress.com이 다른 WordPress hosting 서비스에 대한 edge가 될 듯…

  1. 흔히 볼 수 있는 페이지 별 방문 수, 일별 통계, 참조 페이지 목록, 검색어 등등 []
  2. Mozilla에서 제공하는 PlugIn SDK의 이름이랑 겹친다; 이미 Mozilla 소프트웨어 재단이랑 얘기가 되어서, 이름을 쓰는데 큰 문제(?)는 없다고 한다… []
  3. 원격 서버를 통해 가능은 하지만 []

rein’s world 2010 통계

2010녀 한 해는 블로깅이 좀 많이 소홀했다. (작년에 이어…)
올해에도 내가 만든 WordPress 연간 통계 플러그 인 우려먹기.

여하튼 그래도 정리하는 의미에서 통계 내기.

글은 총 79개 썼다. 전반적으로 글 수가 Orz

Annual Post Statistics

댓 글도 적었고(…),

Annual Comment Statistics

 

작년과 비교해도 전반적으로 좀 활동이 뜸했다.

Comparison

Comparison

 

글은 예전처럼(…) 프로그래밍과 잡담 위주. 올해는 GCC 새 릴리즈와 VisualStudio 2010에서 C++0x를 지원하기 시작해서 이쪽 포스팅을 좀 한 듯도..

Blog 이사 아닌 이사

도메인 주소 구입 + 블로그 디렉토리 이전으로 몇 가지 삽질을 했다. 아래는 이틀 간의 삽질 기록.

1. 2009년 12월 27일을 끝으로 만료된 rein.kr 도메인을 구입했다 – 물론 만료 후 한 달이 지나야 다른 사람이 등록할 수 있기에 어제 구입. 구매할 때 상당히 많은 개인정보를 요구하는건 유감이지만 — .kr 도메인이 아니고서야 한국 내에서 살 이유가 없으니 – 어쨌든 도메인 주소가 대폭 짧아졌다.

여기까지 해서 http://rein.upnl.org/wordpresshttps://rein.kr/wordpress/ 로 이전.

2. 도메인 주소가 짧아지고나니, wordpress 라는 블로그 디렉토리 이름이 묘하게 길어보이기 시작(…).

집에 돌아와서 mod_rewrite 를 열어 수정을 했다. 뭐가 문제였는지는 모르겠지만, top-level 주소는 제대로 redirection[1] 되던데, 나머지 주소들 – 그러니까 WordPress 에서 사용하는 archives/post-name tags/tagname 같은 대부분의 주소들 – 은 제대로 redirection 이 안되서 어젯밤은 GG 치고 자러 갔다.

3. 오전에 병원가려고 준비하다가 mod_rewrite 대신에 mod_alias 를 쓰면 되겠다 싶어서 간단히 proof-of-concpets 코드만 짜고 병원 행.

오후에 잠시 난 짬을 써서 주소를 옮겼다.

설정은 다음 코드를 이용.

<IfModule mod_alias.c>
Redirect 301 /wordpress /blog
</IfModule>

이걸로  https://rein.kr/wordpresshttps://rein.kr/blog 로 전환. 하지만 rein.upnl.org/blog 로 직접 접근해오는 경우는 웹 브라우져 주소창에는 여전히 이전 주소로 찍힌다.

4. 301 redirect 될 주소에 도메인 주소까지 명시적으로 줘봤다. 잘 된다!

이제 rein.upnl.org/wordpress 로 접속해와도 rein.kr/blog 로 간다

<IfModule mod_alias.c>
Redirect 301 /wordpress https://rein.kr/blog
</IfModule>

이제 블로그 내부 데이터에 박혀있는 – 그러니까 각 글들의 링크, 사진 주소 등등 – 데이터를 rein.kr 기반으로 옮기면 끝.

여기까지가 현재 상태.

남은 문제:

  • Google 검색 정보 옮기기: WebMaster 툴에서 내가 upnl.org 는 소유하고 있는게 아니라고 거부한다
  • upnl.org 를 내껄로 위장(?)하기?
  • 구글 커스텀 검색이 rein.upnl.org 기반 페이지로 가려고 시도함. 어디서 바꾸지?[2]

과연 언제다 해결?

2010-01-31 13:42 – 블로그 각 글에서 rein.upnl.org 사용되는 것 rein.kr 로 이동. 이제 메타데이터 테이블 고쳐야?

  1. HTTP 301 응답; permanently moved 이용 []
  2. 물론 저기로 가봐야 다시 돌아오게 아파치 설정을 고쳐서 별 문제는 안생김 []

Blog 도메인 이전 및 기타 등등

rein.upnl.org –> rein.kr 이전 + /wordpress/ –> /blog/ 이전이 진행 중.

일부 디렉토리가 접근이 안된다거나, 특정 그림/사진이 안보인다거나, 링크가 잠시(?) 접근이 안된다거나 할 수 있는 상황.

주말까지 간헐적으로 문제가(혹은 폭발적으로?) 생길 예정..

<IfModule mod_alias.c>
    Redirect 301 /wordpress /blog
</IfModule>

로 일단 수정. 과연 이걸로 끝?

모바일 디바이스용 테마 설정

…한지 거의 3주는 된거 같지만(쿨럭). 볼 방법이 없는지라 – 아이폰을 선물로 뿌린다는 소문만 회사에 돌고있지만… – UserAgent 를 수정해서 쏴보내고 모바일 버젼[1] 의 블로그를 읽었다.

WP Touch 란 WordPress 모바일 페이지 플러그인을 설치한 결과가 다음 화면. 설정도 WP 답게 쉬운 편. 그냥 플러그인 디렉토리에 업로드하고 활성화(activation)하면 끝.

reinsworld_on_iphone

내 취향대로의 미니멀리즘이 되어버린듯? 블로그 자체를 아예 이 테마로 운영해버릴까하는 생각도 든다.

  1. 확인해본 실제 지원 목록은 google android, aspen, 블랙베리 9500/9530, iPhone/iPod Touch, opera mini 등등을 지원한다고 한다 – wptouch  설정 페이지조. opera mini 까지 포함되니 왠만한 모바일 플랫폼에선 대부분 적용될듯? []

웹서버 로그로 본 내 블로그

물론 아파치 로그를 직접 까보는 일은 회사 들어온 이래로 졸업했고 (…) 요즘은 심심풀이로 awstats / wordpress.com / google analytics 분석결과만 본다. 딱히 돈을 벌어주거나하는 블로그는 아니지만 — 이 블로그는 OB와 동아리 돈으로 IDC에 집어넣은 서버 위에서 동작한다. 즉 운영할 수록 내 돈이 깨진다(…) — 그래도 나름대로 생각을 정리하고, 다른 사람의 의견을 묻는 의미로 사용하고 있어서, 어느 정도의 트래픽 유입이 필요하다(…). 여튼, 오늘 아침 출근하고 까본 결과를 얘기해보겠다.

Apache gzip-compression 을 걸고나니

8월 부터 블로그 페이지들에 gzip 압축(deflate)을 걸기 시작했는데, 덕분에 awstats에 표시되는 웹 서버 네트웍 사용량이 절반 이하로 줄었다. (그 동안 UV/PV는 증가했다) 다만, 이 로그가 완전히 신뢰가 안가는건 가끔 아예 트래픽이 집계 안되는 날이 있어서 Orz. 하지만 대부분의 경우엔 실제로도 느껴질 수준으로 네트웍 사용량이 줄어들었으니, 아마도 대부분의 내용이 텍스트이고, gif 나 png는 캐슁도 잘 되고 있을테고해서 그러한듯하다.[1] 그리고 서버 로드도 거의 증가하지 않았다.[2]

웹에 보이는건 구글과 네이버 그리고 약간

WordPress.com 에서 제공하는 로그 분석 기능과 Google의 Analytics를 써서 나온 결과는 여러모로 재미있었다. 둘다 한국 내 웹검색엔진 들을 검색엔진으로 분석안해서, naver나 daum을 단순한 “referer”로 인식하는 덕에 굉장히 특이한 결과가 나온다. 검색 엔진은 죄다 구글로 잡히고, 리퍼러는 거의 네이버로 잡힌다. (다음은 사실 보이지도 않는다) 구글 analytics 데이터는 지난 한 달간 다음과 같다. (UV 6066; PV 10426)

refer

구글 검색이 전체 방문자의 1/3 도 넘는 수를 끌어들이고, 내이버가 약 1/4[3] , 그 이외에는 거의 google reader / hanrss / egloos-valley 같은 리더 류의 사이트다. 빙/야후/다음은 잘 보이지 않는듯 ;;;  고어핀드한테 이 얘기를 했더니 “자기 블로그도 그렇다”라는 답변이 오더라;

사실상 사람들이 쓰는 엔진이 뻔한 다음에야(…), 그리고 네이버 쪽 P/V가 낮은 이상에야 그냥 지금 하는데로, 구글에 사이트맵 잘 보내주고, RSS는 전문공개로 운영하면 어느 정도 찾아오는 사람이 유지될 걸로 보인다.

ps. 근데 궁굼한게 있다. 이건 내가 답이 짐작이 가지 않는게 있다. RSS 리더를 통해서 유입되는 트래픽이 약간 있는데[4] — 이 블로그의 RSS는 모든 내용이 포함되서 공개되었기 때문에, 리더에서만 읽으면 되지 굳이 사이트로 찾아오지 않아도 된다 — 이 사람들은 한 페이지만 보고 나가는게 아니라, 여러 페이지를 보고나간다는 통계인데, 이 의미가 꽤나 궁굼하다.

  1. 텍스트만 있는 페이지는 대략 1/3 수준으로 줄어든다 []
  2. 물론 이건 블로그 자체에 WP-SuperCache를 걸어서 스태틱 페이지를 내보내고 있어서이긴 하다 []
  3. 네이버 검색/카페-블로그 검색/지식인이 다 분리되어 나오더라 []
  4. 위 테이블에선 google.com/co.kr 의 refereal, hanrss 정도에 해당한다 []