LAMP 애플리케이션을 조정하는 다섯 가지의 간단한 방법
요약： Linux, Apache, MySQL 및 PHP(LAMP) 아키텍처는 오늘날 가장 대중적인 웹 서버 아키텍처 중 하나입니다. 저자인 John Mertic은 모든 LAMP 애플리케이션이 최적의 성능을 위해 활용해야 하는 다섯 가지 사항을 검토합니다.
원문 게재일： 2011 년 6 월 07 일
난이도： 중급
원문： 보기
PDF： A4 and LetterGet Adobe® Reader®
페이지뷰： 5001 회
의견： 0 (의견 추가)
난이도： 중급
원문： 보기
PDF： A4 and LetterGet Adobe® Reader®
페이지뷰： 5001 회
의견： 0 (의견 추가)
평균 평가 등급 (총 3표)Wikipedia, Facebook 및 Yahoo!와 같은 주요 웹 자산들은 LAMP 아키텍처를 사용하여 매일 수 백 만 건의 요청을 처리하는 반면, Wordpress, Joomla, Drupal 및 SugarCRM과 같은 웹 애플리케이션 소프트웨어는 이 아키텍처를 사용하여 조직들이 웹 기반 애플리케이션을 간편하게 배치하도록 한다.
그 아키텍처의 강점은 단순성에 있다. .NET과 Java™ 기술과 같은 스택들이 방대한 하드웨어와 값비싼 소프트웨어 스택 및 복잡한 성능 조정을 사용하는 반면에, LAMP 스택은 오픈 소스 소프트웨어 스택을 사용하여 상용 하드웨어에서 실행할 수 있다. 소프트웨어 스택이 모놀리식(monolithic) 스택이 아니라 느슨한 컴포넌트의 세트이기 때문에, 성능을 위해 조정하는 것은 각 컴포넌트를 분석하고 조정해야 하기 때문에 어려운 과제가 될 수 있다.
하지만, 어느 크기의 웹 사이트에서나 성능에 엄청난 영향을 줄 수 있는 몇 가지의 간단한 성능 태스크가 있다. 이 기사에서는 LAMP 애플리케이션의 성능을 최적화하도록 설계된 이러한 다섯 가지의 태스크에 대해 살펴볼 것이다. 이러한 항목들은 어느 아키텍처나 애플리케이션에 변경하는 경우에 요구사항이 매우 적기 때문에, 웹 애플리케이션에 대한 하드웨어 요구사항과 응답성을 최대화하는 안전하고 간편한 옵션이 된다.
opcode 캐시 사용
어느 PHP(물론, LAMP에서의 "P"임) 애플리케이션에서나 성능을 가장 간편하게 신장시키는 것은 opcode 캐시를 활용하는 것이다. 필자는 작업하는 어느 웹 사이트에서나 존재하는지 한 가지만 확인한다. 왜냐하면 성능 영향이 엄청나기 때문이다(opcode 캐시가 없는 많은 경우에 응답 시간이 반으로 줄어듬). 하지만, PHP에 새롭게 입문하는 대부분의 사람들의 질문은 왜 개선이 급격한가이다. 응답은 PHP가 어떻게 웹 요청을 처리하는가에 달려있다. 그림 1은 PHP 요청의 플로우를 개괄적으로 보여준다.
그림 1. PHP 요청
PHP가 C 또는 Java 언어와 같이 컴파일된 언어가 아니라 해석된 언어이므로 전체 구문 분석-컴파일-실행 단계는 매 요청에 대해 수행된다. 이 과정이, 특히 요청들 사이에서 스크립트가 거의 바뀌지 않을 때에 얼마나 시간 및 자원 소모적인지 확인할 수 있다. 스크립트가 구문 분석되고 컴파일된 후에, 스크립트는 일련의 opcode로 시스템이 구문 분석 가능한 상태가 된다. 여기에서 opcode 캐시의 효과가 나타난다. 이는 이러한 컴파일된 스크립트를 일련의 opcode로 캐시하여 매 요청에 대한 구문 분석 및 컴파일 단계를 방지한다. 그림 2에서 이러한 워크플로우가 어떻게 동작하는지 확인할 수 있다.
그림 2. opcode 캐시를 활용하는 PHP 요청
따라서 PHP 스크립트의 캐시된 opcode가 존재하면, PHP 요청 프로세스의 구문 분석 및 컴파일 단계로 건너뛰고 캐시 opcode를 직접 실행하며 결과를 출력할 수 있다. 검사 알고리즘은 스크립트 파일에 변경할 수 있는 상황을 처리하므로, 변경된 스크립트의 첫 번째 요청에서 opcode는 자동으로 다시 컴파일되고 다음 요청을 위해 캐시되어, 캐시된 스크립트를 대체할 것이다.
Opcode 캐시는 PHP V4의 전성기 시절에서부터 내려오는 최초의 일부 캐시로 PHP용으로 오랜 기간 인기가 있었다. 오늘날에는 활발한 개발과 사용 측면에서 다음과 같이 몇 가지의 대중적인 선택이 있다.
- APC(Alternative PHP Cache)는 아마 PHP에 가장 대중적인 opcode 캐시일 것이다(참고자료 참조). 이는 몇 명의 핵심 PHP 개발자들이 개발하고 주로 참여하여, Facebook과 Yahoo! 엔지니어로부터 속도와 안정성을 확보하였다. 이는 또한 이 기사에서 나중에 살펴 볼 사용자 캐시 컴포넌트를 포함하여 PHP 요청을 처리하기 위해 몇 가지 다른 속도 개선도 뽐낸다.
- Wincache는 IIS(Internet Information Services) 웹 서버를 사용하여 Windows®에서만 사용하도록 Microsoft®의 IIS 팀이 가장 활발하게 개발하는 opcode 캐시이다(참고자료 참조). APC가 Windows-IIS-PHP 스택에서 원활히 작동하지 않는 것으로 알려졌으므로 PHP를 Windows-IIS-PHP 스택에서 최상급 개발 플랫폼으로 만드는 노력의 일환으로 대세를 이루며 개발되었다. 기능 면에서 APC와 매우 유사하고, 사용자 캐시 컴포넌트 뿐만 아니라 내장 세션 핸들러를 자랑하여 Wincache를 세션 핸들러로 직접 활용한다.
- eAccelerator는 원본 PHP 캐시 중 하나인 Turck MMCache opcode 캐시 중 하나의 갈래이다(참고자료 참조). APC 및 Wincache와는 달리, 이는 유일한 opcode 캐시 및 최적화 프로그램이므로 사용자 캐시 컴포넌트를 포함하지 않는다. 이는 UNIX® 및 Windows 스택에 걸쳐 완전히 호환 가능하며, APC 또는 Wincache가 제공하는 추가 기능을 활용하도록 의도하지 않은 사이트에 매우 인기가 많다. 이 경우는 memcache와 같이 솔루션을 사용하여 여러 웹 서버 환경에 대해 개별 사용자 캐시 서버를 가질 경우에 종종 발생한다.
PHP 설정 최적화
opcode 캐시를 구현하는 것은 성능 개선을 위한 대개혁인 반면, php.ini 파일에서 설정을 기반으로 PHP 설정을 최적화하기 위해 다른 수정 사항들을 많이 수행할 수 있다. 이러한 설정들은 프로덕션 인스턴스에 대해 더 적절하다. 개발 또는 인스턴스 테스트를 하자마자, 애플리케이션 문제를 디버그하는 것이 더 어려워질 수 있으므로 이러한 변경을 적용하지 않으려 할 수 있다.
성능을 돕기 위해 중요한 몇 가지 항목에 대해 살펴보자.
사용 안함 상태가 되어야 하는 사항
하위 호환성(backward-compatibility)에 자주 사용되기 때문에, 사용 안함 상태가 되어야 하는 다음 몇 가지의 php.ini 설정이 있다.
register_globals— 이 기능은 수신되는 요청 변수가 자동으로 정상 PHP 변수에 지정되는 PHP V4.2 이전에 기본값으로 사용되었다. 이렇게 할 때에(정상 PHP 변수 컨텐츠와 혼합된 수신 요청 데이터를 필터링하지 않는 것), 주요 보안 문제 외에도 매 요청 시 이를 수행하게 하는 오버헤드도 나타난다. 따라서, 이를 끄면 애플리케이션을 더 안전하게 유지하고 성능을 개선하게 될 것이다.magic_quotes_*— 이는 수신되는 데이터가 위험한 양식 데이터를 자동으로 벗어나는 PHP V4의 또 다른 잔재이다. 이는 수신되는 데이터가 데이터베이스로 전송되기 전에 무해하도록 도움을 주는 보안 기능이 되도록 설계되었지만, 그 곳에서 SQL 주입 공격의 더 일반적인 유형에 대해 사용자를 보호하지 않기 때문에 별로 효율적이지는 않다. 대부분의 데이터베이스 계층들이 이러한 위험을 훨씬 더 우수하게 처리하는 준비된 명령문을 지원하기 때문에, 이를 끄면 골치아픈 성능 문제를 다시 제거하게 될 것이다.always_populate_raw_post_data— 이는 어떤 이유에서 수신되는 필터링되지 않은POST데이터의 전체 페이로드를 살펴 보아야 하는 경우에만 정말 필요하다. 그렇지 않으면, 이는 POST 데이터의 복제 사본을 메모리에 저장하는 것이며, 이는 불필요하다.
사용 상태가 되거나 설정이 수정되어야 하는 사항
스크립트의 속도를 약간 신장시키도록 php.ini 파일에서 사용할 수 있는 다음과 같이 일부 훌륭한 성능 옵션이 있다.
output_buffering— 반드시 이를 켜야 한다. 왜냐하면 요청 응답 시간이 매우 느려질 수 있는 매echo또는print명령문에서가 아니라, 큰 덩어리로 브라우저에 다시 쏟아 버릴 것이기 때문이다.variables_order— 이 지시문은 수신되는 요청에 대해 EGPCS(Environment,Get,Post,Cookie및Server) 변수 구문 분석의 순서를 제어한다. 특정 슈퍼전역변수(superglobals)(예: 환경 변수)를 사용하지 않는 경우, 안전하게 이를 제거하여 매 요청 시 이를 구문 분석하도록 하지 않고 속도만 약간 높일 수 있다.date.timezone— 이는 소개된DateTime기능으로 사용하기 위해 기본 시간대를 설정하도록 PHP V5.1에 추가된 지시문이다. php.ini 파일에서 이를 설정하지 않는 경우, PHP는 이것이 무엇인지 확인하기 위해 시스템 요청을 많이 수행할 것이며, PHP V5.3에서 매 요청 시에 경고가 발생할 것이다.
require() 및 include()(뿐만 아니라 동기인 require_once() 및 include_once())의 사용이다. 이는 PHP 구성 및 코드를 최적화하여 매 요청 시 불필요한 파일 상태 검사를 방지하며, 이로 인해 응답 시간이 느려질 수 있다. require() 및 include() 관리파일 상태 호출(파일의 존재를 검사하는 내재된 파일 시스템에 작성된 호출을 의미함)은 성능의 측면에서 꽤 비용이 많이 들 수 있다. 파일 상태의 주범 중 하나는
require() 및 include() 명령문의 형태이며, 이는 코드를 스크립트로 가져오는 데 사용할 수 있다. require_once() 및 include_once()의 동기 호출은 더 문제가 될 수 있다. 왜냐하면 파일의 존재 뿐만 아니라 이전에 포함되어 있지 않았는지 여부를 확인해야 하기 때문이다.그렇다면 이를 처리하는 최선의 방법은 무엇일까? 이를 가속화하기 위해 몇 가지 사항을 수행할 수 있다.
- 모든
require()및include()호출에 대해 절대 경로를 사용한다. 이렇게 하면 PHP에 포함할 정확한 파일이 더 분명해져서, 파일에 대해 전체include_path를 검사할 필요가 없게 된다. include_path의 항목의 수를 낮게 유지한다. 이렇게 하면 포함하고 있는 파일이 없을 위치를 검사하지 않아 모든require()및include()호출(종종 대형의 레거시 애플리케이션에서의 경우)에 대해 절대 경로를 제공하는 것이 어려운 상황에 도움이 될 것이다.
데이터베이스 최적화
데이터베이스 최적화가 신속하게 매우 진보한 주제가 될 수 있고, 필자는 여기에서 이 주제를 흡족하게 소화할 만한 공간이 거의 없다. 하지만, 데이터베이스의 속도 최적화에 대해 살펴보는 경우에 첫 번째로 취해야 하는 몇 가지 단계가 있다. 이는 가장 일반적으로 발생하는 문제에 유용할 것이다.
데이터베이스를 자체 시스템에 넣기
데이터베이스 쿼리는 자체적으로 매우 치열하게 될 수 있어서, 종종 합리적인 크기의 데이터세트로 간단한
SELECT 명령문을 수행하기 위해 CPU를 전적으로 고정한다. 웹 서버와 데이터베이스 서버 둘 다 하나의 시스템에서 CPU 시간에 경쟁하는 경우, 이는 반드시 요청의 속도를 느리게 할 것이다. 따라서, 필자는 웹 서버와 데이터베이스 서버를 별도의 시스템에 두고 둘 중에 데이터베이스 서버를 더 무겁게 만드는 것(데이터베이스 서버는 대량 메모리와 복수 CPU를 선호함)이 훌륭한 첫 번째 단계라고 생각한다.올바르게 테이블 설계 및 인덱스
데이터베이스 성능 관련하여 가장 큰 문제점은 거의 비효율적인 데이터베이스 설계와 누락된 인덱스로 인해 발생한다.
SELECT 명령문은 일반적인 웹 애플리케이션에서 실행되는 대개 압도적으로 가장 일반적인 쿼리 유형이다. 이는 또한 데이터베이스 서버에서 실행되는 가장 시간을 많이 소모하는 쿼리이기도 하다. 추가적으로, 이러한 종류의 SQL문은 올바른 인덱싱과 데이터베이스 설계에 가장 민감하므로, 최적의 성능을 위한 팁을 보려면 다음 포인터를 살펴보자. - 각 테이블에 기본 키가 있도록 보장한다. 이는 테이블에 기본 순서 및 다른 테이블에 대해 이 테이블을 결합하는 신속한 방법을 제공한다.
- 테이블의 외부 키(다시 말해서, 또 다른 테이블에서 레코드를 서로 연결하는 키)가 올바르게 인덱싱되도록 보장한다. 많은 데이터베이스들은 이러한 키에 자동으로 제한조건을 강제할 것이므로 그 값은 실제로 또 다른 테이블의 레코드와 일치하여, 이에 도움이 될 수 있다.
- 테이블에서 열의 수를 제한하도록 시도한다. 테이블에 열이 너무 많으면 열이 적은 경우보다 쿼리에 대한 스캔 시간이 훨씬 더 오래 걸릴 수 있다. 게다가 일반적으로 사용하지 않는 열이 많은 테이블이 있어도
NULL값 필드로 디스크 공간을 낭비하고 있는 것이다. 이는 테이블 크기가 필요 이상으로 훨씬 더 커질 수 있는 텍스트나 blob과 같은 변수 크기 필드에도 적용된다. 이 경우에 추가 열을 다른 테이블로 나누고, 레코드의 기본 키에서 함께 결합하는 것을 고려해야 한다.
데이터베이스 성능을 개선하기 위한 최선의 도구는 무슨 쿼리가 데이터베이스 서버에서 실행되고 실행되는 데 얼마나 오래 걸리는지 분석하는 것이다. 거의 모든 데이터베이스에 이를 수행하기 위한 도구가 있다. MySQL을 통해, 느린 쿼리 로그를 활용하여 문제가 있는 쿼리를 찾을 수 있다. 이를 사용하기 위해 MySQL 구성 파일에서
slow_query_log 설정을 1로 설정한 후에, log_output을 FILE로 설정하여 파일 hostname-slow.log로 로그되도록 한다. "느린 쿼리"로 고려하기 위해 초 단위로 얼마나 오래 쿼리가 실행해야 하는지 long_query_time 임계값을 설정할 수 있다. 데이터 세트에 따라 이를 처음에 5초로 설정하고 시간이 지나면서 1초로 낮추는 것을 권장한다. 이 파일을 살펴보면, 목록 1과 유사한 자세한 쿼리를 확인하게 될 것이다. 목록 1. MySQL 느린 쿼리 로그
/usr/local/mysql/bin/mysqld, Version: 5.1.49-log, started with: Tcp port: 3306 Unix socket: /tmp/mysql.sock Time Id Command Argument # Time: 030207 15:03:33 # User@Host: user[user] @ localhost.localdomain [127.0.0.1] # Query_time: 13 Lock_time: 0 Rows_sent: 117 Rows_examined: 234 use sugarcrm; select * from accounts inner join leads on accounts.id = leads.account_id; |
살펴보려는 핵심 사항은 쿼리가 얼마나 오래 걸리는지 보여주는
Query_time이다. 한 가지 더 살펴볼 것은 Rows_sent 및 Rows_examined의 수이다. 왜냐하면 이는 너무 많은 행을 보거나 너무 많은 행을 리턴하는 경우 쿼리가 잘못 쓰일 수 있는 상황을 가리킬 수 있기 때문이다. 목록 2와 같이 결과 세트 대신에 쿼리 계획을 리턴할 쿼리에 EXPLAIN을 앞에 첨가하여 쿼리를 작성하는 방법을 더 심도있게 탐색할 수 있다. 목록 2. MySQL
EXPLAIN 결과mysql> explain select * from accounts inner join leads on accounts.id = leads.account_id; +----+-------------+----------+--------+--------------------------+---------+--- | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+--------+--------------------------+---------+-------- | 1 | SIMPLE | leads | ALL | idx_leads_acct_del | NULL | NULL | NULL | 200 | | | 1 | SIMPLE | accounts | eq_ref | PRIMARY,idx_accnt_id_del | PRIMARY | 108 | sugarcrm.leads.account_id | 1 | | +----+-------------+----------+--------+--------------------------+---------+--------- 2 rows in set (0.00 sec) |
MySQL 매뉴얼은
EXPLAIN 출력의 주제로 훨씬 더 깊이 탐구한다(참고자료 참조). 하지만 주목하여 살펴보는 것은 'type' 열이 'ALL'인 부분이다. 이는 MySQL이 전체 테이블 스캔을 수행하도록 요구하며 검색에 대한 키를 사용하지 않기 때문이다. 이는 인덱스를 추가하면 쿼리 속도를 엄청나게 높이는 데 도움을 줄 것이라는 부분을 가리키는 데 유용하다.효율적인 데이터 캐시
이전 섹션에서 본 것처럼, 데이터베이스는 웹 애플리케이션에서 쉽게 성능의 가장 큰 골치거리가 될 수 있다. 하지만, 쿼리하고 있는 데이터가 그다지 자주 달라지지 않으면 어떻게 되는가? 이 경우에, 매 요청 시 쿼리를 호출하는 것이 아니라 로컬로 이러한 결과를 저장하는 훌륭한 옵션이 될 수 있다.
이전에 살펴본 두 가지의 opcode 캐시인 APC와 Wincache는 이것만 수행하기 위한 기능이 있다. 이는 PHP 데이터를 빠른 검색을 위해 공유 메모리 세그먼트로 저장할 수 있다. 목록 3은 이를 수행하는 방법에 대한 예제를 제시한다.
목록 3. 데이터베이스 결과를 캐시하기 위해 APC 사용의 예제
<?php
function getListOfUsers()
{
$list = apc_fetch('getListOfUsers');
if ( empty($list) ) {
$conn = new PDO('mysql:dbname=testdb;host=127.0.0.1', 'dbuser', 'dbpass');
$sql = 'SELECT id, name FROM users ORDER BY name';
foreach ($conn->query($sql) as $row) {
$list[] = $row;
}
apc_store('getListOfUsers',$list);
}
return $list;
}
|
쿼리를 한 번만 수행해야 할 것이다. 그 이후에, 결과를
getListOfUsers 키 아래 APC 사용자 캐시로 밀어 넣는다. 지금부터 캐시가 만기될 때까지 캐시에서부터 결과 배열을 직접 페치할 수 있어, SQL 쿼리를 건너 뛸 수 있다.APC 및 Wincache는 사용자 캐시를 위한 유일한 선택은 아니다. memcache와 Redis는 웹 서버와 동일한 서버에서 사용자 캐시를 실행하도록 요청하지 않는 또 다른 인기있는 선택이다. 이렇게 하면 특히, 웹 애플리케이션이 몇 개의 웹 서버에 걸쳐서 규모가 조정되는 경우에 추가 성능과 유연성을 제공한다.
결론
이 기사에서는 더 우수한 성능을 위해 LAMP 애플리케이션을 조정하는 간단한 다섯 가지의 방법을 살펴보았다. opcode 캐시를 활용하고 PHP 구성을 최적화하여 PHP 레벨에서의 기술을 살펴보았을 뿐만 아니라, 올바른 인덱싱을 위해 데이터베이스 설계를 최적화하는 것도 살펴보았다. 또한 데이터를 매우 자주 변경하지 않을 때에 반복된 데이터베이스 호출을 어떻게 방지할 수 있는지를 보여주는 사용자 캐시의 활용(예제로 APC 사용)에 대해서도 살펴보았다.
다운로드 하십시오
| 설명 | 이름 | 크기 | 다운로드 방식 |
|---|---|---|---|
| Source code | os-5waystunelamp.zip | HTTP |
참고자료
교육
- "A PHP V5 migration guide": PHP V4에서 V5로 개발된 코드를 마이그레이션하는 방법을 배워보자.
- Planet PHP는 PHP 개발자 커뮤니티 뉴스 소스이다.
- MySQL 매뉴얼은
EXPLAIN출력의 주제에 대해 더 심도있게 탐색한다.
- PHP.net은 PHP 개발자들이 주로 이용하는 웹 사이트이다.
- "Recommended PHP reading list"를 확인하자.
- developerWorks에 있는 PHP 컨텐츠를 모두 찾아보자.
- Twitter의 developerWorks 페이지를 살펴보자.
- IBM developerWorks의 PHP project resources를 활용하여 PHP 기술을 향상시키자.
- developerWorks podcasts에서 소프트웨어 개발자의 흥미로운 인터뷰와 토론을 확인할 수 있다.
- PHP로 데이터베이스를 사용 중인가? IBM DB2 V9을 지원하는 원활하고 탁월하며 설치가 간편한 PHP 개발 및 프로덕션 환경인 Zend Core for IBM을 확인해보자.
- developerWorks의 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
- IBM 오픈 소스 개발자에게 유익한 컨퍼런스, 기술 박람회, 웹 캐스트 및 기타 행사를 확인하고 참여하자.
- developerWorks 오픈 소스 영역에서 오픈 소스 기술을 활용하여 개발 작업을 수행하고 이러한 기술을 IBM 제품과 함께 사용하는 데 도움이 되는 사용법 정보, 도구 및 프로젝트 업데이트와 가장 인기 있는 기사 및 튜토리얼을 확인할 수 있다.
- 무료로 제공되는 developerWorks On demand demos를 통해 IBM 및 오픈 소스 기술에 대해 배우고 제품 기능을 익히자.
- Alternative PHP Cache는 아마 PHP에 가장 대중적인 opcode 캐시일 것이다.
- Wincache는 IIS(Internet Information Services) 웹 서버를 사용하여 Windows에서만 사용하도록 Microsoft의 IIS 팀이 가장 활발하게 개발한 opcode 캐시이다.
- eAccelerator는 원본 PHP 캐시 중 하나인 Turck MMCache opcode 캐시 중 하나의 갈래이다.
- DVD로 제공되거나 다운로드할 수 있는 IBM 시험판 소프트웨어를 사용하여 차기 오픈 소스 개발 프로젝트를 구현해 보자.
- IBM 제품 평가판을 다운로드하거나 IBM SOA Sandbox의 온라인 시험판을 살펴보고 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere®의 애플리케이션 개발 도구 및 미들웨어 제품을 사용해 볼 수 있다.
- developerWorks 커뮤니티에 참여하자. 개발자가 운영하고 있는 블로그, 포럼, 그룹 및 위키를 살펴보면서 다른 developerWorks 사용자와 의견을 나눌 수 있다.
- developerWorks 블로그를 통해 developerWorks 커뮤니티에 참여할 수 있다.
- developerWorks PHP 포럼: Developing PHP applications with IBM Information Management products(DB2, IDS)에 참여하자.
John Mertic은 SugarCRM의 소프트웨어 엔지니어이며, PHP 웹 애플리케이션과 관련하여 수 년간의 경험이 있다. 그는 SugarCRM에서 데이터 통합, 모바일 및 사용자 인터페이스 아키텍처를 전문으로 하여 재직 중이다. 왕성한 저술가로서 php|architect, IBM developerworks 및 Apple Developer Connector에 기고했으며, "The Definitive Guide to SugarCRM: Better Business Applications"이라는 책의 저자이기도 하다. 많은 오픈 소스 프로젝트에 참여했으며, 특히 PHP 프로젝트에 주력하고 있다. 또한 PHP Windows Installer를 개발 및 유지보수한다
댓글 없음:
댓글 쓰기