sh’s words

(요즘 일도 많고, 사내 블로그를 쓰게 되서 한 동안 포스팅을 못했다.)

일전에 사내 프로젝트를 진행하며 PHP5.x + Propel을 도입했었다. Propel은 java의 hibernate의 php port인데 이 녀석의 구현이 php의 class/object 부분을 좀 하드코어하게 활용했다. (수 많은 클래스와 상속들…) 그래서인지 갖다붙이는 opcode cacher마다 프로그램을 뻗어버리게 만들어버렸다. APC, eaccelerator(구 turckMM cache) 모두 특정한 부분에서 오류를 내고 죽어버렸다. cacher없이 돌아가는 php스크립트가 얼마나 느린가를 수 개월간 체험할 수 있는 기회였다고나 할까. 메인 페이지가 대략 0.6초 정도의 execute time이 걸렸다. 클릭했을 때 답답함을 느낄 정도의 속도다.

그런데 어제, lighttpd의 설정에 대해서 좀 찾아보다 같은 사람이 작성한 듯한 XCache에 대해 알게됐는데 이 사람, 왠지 자신에 찬 어조로 XCache에 대해서 설명하고 있었다. 지푸라기 한 번 더 잡는 심정으로 php5.2.0에 이걸 붙여봤다. (php5.2.0에는 최근 버전인 1.2.0을 설치해야 한다. 지금 시점에서 1.2.0은 RC딱지를 떼기는 했지만 unstable로 분류되어 있다.)

오 예.

APC나 eaccelerator에서 오류가 생기던 부분이 잘 작동한다. 속도는 두 배 정도 빨라졌군. 같은 서버에 있던 태터툴즈 1.1.1도 이제 클릭질에 시원시원한 반응을 보여준다. XCache 만쉐. 문서화도 잘 되어 있다.

XCache homepage : http://trac.lighttpd.net/xcache/
XCache introduce : http://blog.lighttpd.net/articles/2006/04/04/one-more-opcache-for-php-preview

요즘 회사에서 개발표준화의 일환으로 웹 프레임워크를 제작하고 있다. MVC의 형태를 가지게 될 예정인데 그 중 내가 Model 부분을 진행하는 중이다. DAO부분을 작성하려다 mysql을 위한 api로 뭘 써야하나 고민이 되서 검색을 하다 PDO에 대한 의외의 자료를 발견했다.

http://dealnews.com/developers/php-mysql.html 를 읽어보면 PDO의 성능이 경우에 따라 mysql/mysqli의 절반밖에 되지 않는다는 내용이 있다. PDO는 빠른 속도의 DB추상계층이라 알고 있는데 select성능이 형편없다면 아주 곤란하지 않을까? 대부분의 웹사이트가 select위주의 쿼리를 사용한다면 더욱 더 그럴테다.

그런데 http://netevil.org/node.php?nid=902 에서는 윗글을 정면으로 반박하면서 PDO의 “magic turbo switch”에 대해 얘기한다.

그리고 http://doughboy.wordpress.com/2006/08/25/pdo-turbo-button/ 에서는 wez의 “magic uurbo button”을 켜고 다시 실험을 했다.

난 아직 결론을 내지는 못했지만, 정리하는 차원에서 글로 남긴다.

p.s : http://kr2.php.net/sdo 라는게 있더라.

php 5.x 이상에서는 xml을 쉽게 다루기 위한 인터페이스로 simpleXML 이라는 것을 제공한다. 매우 편해보이는데 php4.x에서는 사용할 수 없을까?

하여 구글신에게 물어보았다.

“backport of simplexml”

역시… 고려해볼만한 세 가지 대안을 찾을 수 있었다.

우선 miniXML. miniXML은 simpleXML과 컨셉이 비슷한 녀석인데, php와 perl 모듈을 제공하고 있다. simpleXML과 API가 달라서 탈락. (하지만 꽤 괜찮아 보인다)
link : http://minixml.psychogenic.com/

그리고 ister.org에서 simpleXML의 backport를 제공하고 있더라. 다운로드해서 살펴봤는데 여러개의 파일로 나눠져 있는데다 클래스명에 Ister라는 prefix를 사용하고 있어서 탈락.
link : http://www.ister.org/code/simplexml44/index.xhtml

joomla(mambo라는 CMS가 fork한 것)에서도 simpleXML의 backport를 제공하길래 살펴봤더니 svn을 통해 체크아웃 할 수가 있길래 얼른 받아봤다. (요즘은 tar를 받아서 압축 푸는것보다 svn이 더 편해~)
단 두 개의 파일만 필요한데다 그나마 한 개의 파일은 JObject라는 간단한 base class라서 이걸로 낙점. API도 거의 같다. joomla가 꽤 활발하게 유지되고 있다는 점도 크게 작용했다.
link : http://dev.joomla.org/index.php?option=com_jd-wiki&Itemid=31&id=guidelines:jsimplexml

anyway- php4에서의 xml_parser() 를 써야 했으면 몇 일 빈둥거렸을지도 몰라!

미니홈피 메뉴관리에 들어갔더니 “파일방”이란게 생겼더라. 뭔가 해서 메뉴를 활성화하고 들어가보니 오류메세지가 떴다.

Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-00001: unique constraint (UBUSMAIN.MINIHP_SESSION_IDX_ID) violated in /web/core/common/dbconn_class.php on line 237

oracle에 php라… >_<)b 다시 메뉴를 클릭하니 더 이상 에러메세지는 보이지 않더라.

잠깐 써 본 느낌- 어딘가 말끔하지가 않다. 기본 폴더명이 깨져서 보이는 것도 그렇고 파일설명글이 등록된 다음에 Active-X로 제작된 파일 업로드창이 다시 뜨는것도 의아한 부분이다. 아래와 같은 상태에서 창을 닫아버릴 수 있는데, 그러면 이미 올려진 글은 파일 한 개도 없는 미아가 되버린다. 물론, 추가로 업로드를 하는 기능은 없다.

그나마 업로드창이 modal창도 아니더라. 환경설정 탭을 누르면 옵션들이 blind-down되며 나타나던데, 그런것보다는 전체적인 인터페이스를 좀 더 단순하게 하는 노력이 필요하지 않았을까? 미니홈피의 사용자층이 p2p 프로그램이나 ftp클라이언트를 쓰는 사람들보다는 “컴맹”에 가까운 사람이 더 두터울텐데 말이다.

미니홈피에 뭔가를 업로드할 수 있다는 점이 환영할만하긴 하지만, 끊임없이 도토리를 써야한다니, 이거 과연 성공할 수 있을까? 100메가바이트를 30일 저장할 수 있는데 1,000원이라면 결코 싼 가격이 아니다. 월 500원에 300메가바이트를 제공하는 웹호스팅들이 꽤 많으니까 말이다.

그동안 미루고 미루다가 이슈트래커에 1번으로 등록했던 버그를 고치기로 맘먹었다. 두 달 정도 미뤄둔 것 같은데, 그 동안 몇 번 소스를 열어봤기 때문에 대강 어느 메쏘드가 문제겠구나 하고 감은 잡고 있었다. 그런데 막상 소스코드를 자세히 살펴보니, 예상했던 지점의 문제가 맞긴 했는데 그 내용이 하도 어이없어서 여기에 기록하고 반성하려고 한다.

첫 번째 문제

$goods->setFrom($data);
unset($data[’supertax’], $data[’state’], $data[’fee_shop’], $data[’fee_benefit’]);
$goods->update();

이 메쏘드를 통해서는 supertax, state, fee_shop, fee_benefit가 수정되지 않도록 하려는 의도였는데, 이미 setFrom()으로 값을 줘버린 상태에서 unset() 을 한거다 -_-;; vim에서는 [ddp] 이렇게 세 개의 키로 수정이 됐다 -_-;;

두 번째 문제
if (strpos($var, ’somestring’) != false)) …..

이거, 너무 뻔한거라 민망하다. strpos의 인수 순서는 왜 매번 헷갈리는 것일까? 반환값이 0 이 나올수도 있다는 걸 왜 자꾸 간과하는걸까?

strpos($var, ’somestring’) !== false로 코딩해야 정확하다.
어쨌거나 버그를 고치긴 했는데, 좀 더 조심성을 가져야겠다. 그리고 굉장히 중요한 부분인데도 테스트를 작성하지 않은것도 반성할 점이다.