Rails는 기본적으로 Webrick이란 실행기를 가지고 있습니다.
개발환경으론 별다른 설정도 필요없고, Command 명령어인 Rails server (Rails3기준)만으로 실행되기때문에 편합니다.
하지만 성능에 큰 문제가 있습니다.  특히 서버가 Windows일때는 local접속 말고는 쓸수가 없는 수준입니다. 현재는 Mongrel를 사용하고 있지만, 새로 세팅한 곳은 이미 Apache2가 돌고 있어서 이번에는 Pasenger를 사용해서 Apache2와 연동해보았습니다.

결론부터 말하면, 너무너무너무 쉽군요. 10분만에 끝냈습니다. 환경은 다음과 같습니다. 하이시커 Blog를 참고했습니다.

Ubuntu 10.4
Apaceh2
Rails 3.0
passenger 3.0.2

1. passenger 설치합니다.

2. apache 모듈 설치합니다. 다음 명령어로 실행하는데 친절하게 안내를 해주고, 필요한 모듈이 설치 되어있지 않을땐 적절한 안내를 해줍니다.  세팅한 서버 같은 경우는 APR(Apache Partable Runtime) 를 설치했습니다. 이하 내용은 모두 이 명령어의 진행과정입니다.

3. 설치 [/code]및 설정이 끝나면  Apache Configuration을 수정할 정보를 보여줍니다.
이는 설치하는 시스템에 따라 Path 가 다를 수 있습니다. 

/etc/apache2/mods-available/ 에 rails.load 정도의 이름으로 위의 내용을 추가하고,

이것을 /etc/apache2/mods-enable/에 링크를 걸어 활성화시킵니다.

4. 마지막으로 VirtualHost 설정을 하고 Apache2 restart. Rails 로 생성한 Project 폴더의 ./public 폴더 패스를 DocumentRoot 로 설정하면 됩니다.

추가적인 정보는 다음 Path 에 있다고 안내합니다.

5. apache2 restart하면 끝.

참고로 다음은 레일즈 실행환경별 속도 비교입니다.
webrick를 기준으로 Mongrel가 17배 Aapache가 33배, lighttpd는 100배 빠르군요. 이건뭐...;;;

http://viewsourcecode.org/why/redhanded/inspect/mongrelSGoingToKillWebrickGiveItAMonth.html

당분간은 Apache에 정착해야겠습니다.




.

한 1년전만해도 '너 touch안했지?', 'touch좀 해줘', '올리고 touch해.' 를 입에 달고 다녔다.

UI 구성등을 위해 jsp의 include를 쓸때, 성능 편의등의 이유로 include action 보다는 include directive를 선호한다.
하지만. include directive 는 한 서블릿으로 컴파일 되기때문에 head, menu, footer등 include 되는 파일이 수정이 되었을때 서블릿 컨테이너가 알아 차리질 못한다. 주체가 되는 jsp가 변경된것이 없기때문이다.

이럴때 필요한게 뭐? touch이다.
touch는 파일의 날짜를 변경하는 shell명령어이다.
touch를 사용하면 실제로 jsp파일이 변경된게 없어도, 날짜만 바꿈으로 서블릿컨테이너가 jsp파일이 변경된것으로 속일 수 있다. 그러면 커블릿 컨테이너는 해당 jsp를 다시 컴파일 한다.

하지만 프로젝트가 크면 resource를 포함하여 파일이 상상을 초월하게 많을때도 있다. touch하면 되는건 jsp파일뿐인데.
그래서 정해진 path아래에 jsp파일만 touch하게 명령어를 날리는데...
항상 시키기만 하다보니 명령어를 모르더군요. 그래서 정리차원에서 적어본다.

현재 폴더 아래에서 jsp만 찾아서 touch 함.

좀 어이없는 내용이긴 한데, 정리차원에서. ㅎ

ImageMagick 는 비트맵 이미지를 컨트롤 하는 라이브러리입니다. 이미지 업로드를 할때 썸네일생성등으로 많이 쓰이죠.

Rails3.0에서 Paperclip을 사용중인데 ImageMagick를 사용할때 다음 에러가 났습니다. 사연이 있어서 windows에서 Rails를 돌리고 있는데, 서버를 이관하게 되어서 소스를 옮겼더니 잘되던게, 이미지파일 첨부를 할때 다음과 같은 에러가 나는 군요.



요지는 identify 가 이미지를 인지하지 못한다는 건데, 체크사항은 두가지입니다.

 1. identify의 path설정.

 2. 이미지의 Path의 호출가능여부.

하나씩 확인합니다.




1. identify의 path설정.

구글링을 해보면 다음 두가지 방법이 나옵니다. 둘중 하나를 적용하고 Rails 재기동.

1.1. /config/enviroments/development.rb  에 다음 내용을 추가.



1.1. /config/initializers/ 에 paperclip.rb 를 생성



결국은 같은 이야기입니다.  identify의 경로 지정을 해주는 것. 
주의할점은 윈도우에서도 폴더구분을 \이 아닌 /로 해야하며, Program files 폴더는 progra~1로 표기해야 한다는 겁니다.  C:/Progra~1/ImageMagick-6.6.6-Q8 이런식. 이것떄문에 Rails restart를 수십번했내요.


2. 이미지의 Path의 호출가능여부.

이게 좀 짜증났는데, 결론은 identify는 인자로 받는 path에서 한글을 인식못합니다.
windows가 아니면 거의 발생할일이 없으며, windows라 해도 Rails서버의 로그인계정이 한글이 아니면 발생하지 않습니다. 제가 돌린 서버는 계정이 '행정용'이였습니다. ㅡㅡ;
/log/ 를 확인해서 identify 가 이미지를 호출할때 사용하는 temp path가 풀영문이 되도록 설정하면 된됩니다.


그럼 다시 정상작동.

오늘의 교훈은 왠만하면 Windows에서 뭐 돌리지 말자.

얼마나 쓰는지는 모르겠지만 일단 직장에 있내요.
Flash Media Server Start / Stop / Restart 방법입니다.

Redhat Ent + FMS 3.5 입니다.

1. root 로 로그인.

2. 인스톨된 폴더를 찾아 갑니다. 전 /opt/adobe/fms이군요.



3. 모르면 다음 명령으로 찾습니다.



3. 기동상태를 확인합니다.



4. 다음 명령어를 줍니다.

Rails 가 3.0  으로 올라가면서  Rails 를 기동하는  Command Script 들이  Rails 란 명령어로 통일 되었다.
그래서 기존에 서버를 구동하던  


 명령어는 다음으로 변경됬다. (script  폴더에  server script 가 없다.)


기동관련 옵션은 다음과 같다.




그러므로  Port 80 , 실행환경 production, 데몬  모드로 실행하려면 다음과 같다.



자의반 타의반으로  Rails 를 열심히 파는 중.
짧은 내용이라 간단히 포스팅 한다.

IIS로 서비스를 하거나 준비하다보면...
특정 사이트에서 메모리 누수가 생겨서 계속 메모리가 증가한다던가, CPU 를 100% 먹는다든가 하는것 말이다.
이럴경우 해당 사이트를 중지/재실행하던가 IIS서버 자체를 ReStart하는 형태로 해결을 한다.

문제는 한서버에 여러사이트가 운영되고 있는 상황이다.
대체 [작업관리자]에 저 메모리를 집어먹고 있는놈은 지금 돌아가고 있는 사이트중에 어떤놈이란 말인가? ㅡ ㅡ
그렇다고 멀쩡히 돌아가는 다른 사이트까지 다 죽이기도 그렇고...

이 포스트는 그놈(?)을 색출하는 방법이다.


IIS 6.0의 경우 5.0과는 달리 [작업관리자]에서 IIS실행 프로세스로 확인할 수 있는것이 Dllhost.exe가 아니라 w3wp.exe 이다.
이는 IIS메뉴에 있는 [응용프로그램 풀]에 해당한다. (정확하게 같은것은 아니지만..그냥 같다고 생각하자.)
그러므로 사실상 w3wp.exe하나가 한 사이트. 혹은 한 웹서비스로 보아도 무방하다. (이도 사실아니지만 이글에선 그냥 같다고 하자.)

그럼 [작업관리자]에서 w3wp.exe 가 떠있는것 만큼 웹사이트가 돌고 있는것인데,
각각의 w3wp.exe를 구분할 수 있는 유일한 구분자는 PID. 즉 ProcessID뿐이다. [작업관리자] PID만으로 어느사이트인지 알 수는 없을까?
이 PID를 가지고 해당 서비스 사이트를 찾아보자.
아. 먼저 이 방법은 당연히 IIS가 설치되어있는 서버에서만 가능하다.




그림처럼 [작업관리자]에서 w3wp.exe의 PID들을 확인한다.
컴맨드 창을 띄워서 iisapp라고 입력하자.
그러면. wscript   로 실행할 수 없는 스크립트라는 경고가 뜨고, cscript 로 실행하겠냐고 묻는다.
그러고 나서 다시 iisapp를 하면 다음과 같은 결과를 볼수 있다.




현재 메모리에 떠있는 w3wp.exe의 PID별로 IIS의 Application Pool 의 이름을 보여주고 있다.
IIS를 띄워보자.



[응용프로그램 풀]을 들어가면 같은 이름의 Application Pool 들이 있는것을 확인할 수 있다.

서두에 잠시 언급했듯이 w3wp.exe가 Application Pool 를 그대로 의미하는 것은 아니다.
그러므로 각각의 다른 PID가 같은 Application Pool 를 가리킬 수도 있다. (이건 다음기회에...)

어쨌든 이렇게 확인을 하면 문제를 일으킨 놈(?)을 확인하여 그놈만 확인사살을 하거나 디버깅을 할 수 있다.

참고로 혹시 컴맨트 창에서 iisapp가 경로를 찾지 못하면 다음과 같이 하면 된다.

이파일의 실경로는 c:\windows\system32\iisapp.vbs 이며 cscript로 실행한다.



주의할점은 PID는 현재 기동되어있는 프로세스를 구별하기 위해, 윈도우에 프로세스가 기동될때마자 임의로 주어진다  메모리에서 내려갔다 올라오면 숫자가 변한다는 의미다. 그러므로 '우리 관리단 PID는 3456 야 ' 따위는 아무 의미없다.

더 자세한건 다음 링크를 참고.
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/ko/library/ServerHelp/9b059eb9-1ebd-4fa9-a80e-1fa31adcdacf.mspx?mfr=true

신규 프로젝트를 맞았는데, 서버 환경이 Solaris에 Oracle9i ... 거기다 서블릿컨테이너가 Jrun4 였다.
아. 익숙한게 단한개도 없는 이상황을 어찌할꼬... 하다가 뭐, 어찌어찌 두달째 진행중이긴 한데...


이Jrun4 에대해 몇마디 적고자 한다...


Jrun4는 Macromedia가 만든 자바 웹 어플리케이션 서버 솔루션이다.
나름대로는 강력한 기능을 제공한다. (..고한다.. ㅡ ㅡ)
리눅스에서도 윈도우 못지 않은 쉬운 인스톨 환경도 제공한다.

하지만, 국내 개발 유저층이 무척이나 얇아서 국문으로 된 정보를 거의 찾을 수 없다.
삽질로 알아낸 몇가지 정보를 나누고자 한다.


1.
Macromedia 에서 제공하는 Developor 버전은 기능 제한은 없으나
로컬에서만 접속이 자유롭고 원격접속은 2명이상 동시접속이 안된다는 몸으로 익히는데 1주걸렸다.
http://localhost:8010/ 은 되지만 http://210.111.111.1111:8010/ 은 안된단 말이다.

다운로드 사이트에는 다음과 같은 알듯 모를듯 한 문구만 있다.

JRun 4 Developer Edition is a perpetual license with complete functional capabilities but is limited for low volume non-production deployments.....

http://www.macromedia.com/cfusion/tdrc/index.cfm?product=jrun (여기서 볼수 있다.)




2.
Jrun4는 J2EE 1.3를 완벽하게 지원한다고 엄청나게 자랑한다.
(http://www.macromedia.com/software/jrun/resources/developer/j2ee/)
실제로 대단하기는 한데 몇가지 주의점이 있다.

위의 링크를 보면 알겠지만, J2EE 1.3 API의 내용을 보면  JSP 1.2 와 Servlet 2.3 이 있다.
현재 J2EE API의 최고 버전은 JSP 2.0과 Servlet 2.4 인것으로 알고 있으며, 이를 기반으로 만들어진 사이트는 JRun4에서 문제가 될 수 있다는것을 의미한다. 뭐.. 어짜피 컨테이너 가 바뀌면 문제가 있지만..
참고로, 현재 Tomcat 5.x가 JSP 2.0/Servlet 2.4 기반이다.  (http://tomcat.apache.org/)




3.
개발을 하다보면 서블릿 컨테이너를 restart할일이 곧잘 있다.
윈도우용 Jrun이 reStart가 잘 되지 않을때는 다음과 같은 문제일 수 있다.

윈도우용 JRun을 설치하면, 설치중 Window Service로 등록하겠냐는 선택이 나온다.
이를 선택하면,  Window Service에 떠있는 사이트 수만큼 Macromedit Jrun Service가 실행되어있다.
문제는 이 Service가 SYSTEM계정으로 실행이 된다는 것이다. (Administrator가 아니라.)
그래서 Jrun에서 제공하는 Command 명령어인
jrun -start default
jrun -stop default
jrun -restart default 등이 작동되지 않는다.
왜?
Windows Command 에서의 실행은 로그인 한 계정( 일반적으론 Administrator) 으로 실행이 되기때문에,
Command명령어를 준다고 Service에 등록되어있는 Jrun Service가 영향을 받지 않기때문이다.
이는 [작업관리자]의 [프로세스]를 띄워놓으면 단번에 알 수 있다.
jrun.exe가 SYSTEM계정으로 실행되어있는 상태에서 Command에 jrun -stop 를 실행하면,
Administrator 계정으로 Jrun.exe가 잠시 실행되었다가 사라진다.
그러므로 윈도우 서버에서는 반드시 Window Service에서 Jrun를 reStart해야 한다.