2012-11-19 1 views
0

그래서 장기 실행 Ruby 프로세스가 있는데, 수행 할 작업 (이진 메시지가있는 EventMachine TCP 서버)에 따라 다양한 작업을 수행합니다. 이제는 특정 사람들에게 웹 인터페이스를 통해 주어진 프로세스를 모니터, 변경, 종료 할 수있는 기능을 제공하고자합니다. 나는 그것에 대해 Sinatra.rb을 사용하려고 계획하고 있지만 더 나은 대안을 공개하고 있습니다."외부에서"Ruby 응용 프로그램을 제어하는 ​​연습

내 원래 아이디어는 Thread 안에 Sinatra 웹 인터페이스 (Sinatra에 익숙하지 않은 사용자는 Rack을 기반으로 함)를 실행하여 백그라운드에서 실행하도록하는 것이 었습니다.

그러나, 나는 그런 식으로 할 경우 성능에 영향을 줄 수 있습니다 생각했다, 그래서 나는 루비 (resque, 메모리 공유, named pipes 등)에 대한 IPC 능력과 다른 구현을 조사하기로 결정했다.

나는 resque (그리고 그 이름은 정말로 재치가있다.)의 아이디어를 정말 좋아했지만, 그것이 내가 필요로하는 것이지, 그것이 과잉 일지 모른다는 것을 완전히 확신하지는 못했다. 실제로 Sinatra EventMachine을 사용하여 구현하는 것이 가장 좋은 방법인지는 모르겠지만 (resque에 대한 전체 설명서를 읽지는 않았지만 예제를 신속하게 스캔하고 예제와 사용 사례를 읽었습니다.)

마음에 떠오른 또 다른 아이디어는 EventMachine::defer 안에 Sinatra를 사용하는 것이지만, 새로운 Thread을 만드는 것과 본질적으로 같은가요?

내가 Fiber의를 사용하여 심각한 일을 해본 적이없는, 그래서 자신의 전체 잠재력을 모르겠지만, 그들이 내 마음을 교차했다.

그래서 Ruby PCI에 가장 적합한 방법은 무엇입니까 (또는 더 좋습니다).

감사합니다.

+0

이렇게 많은 질문이 있습니다. 더 구체적으로 프로토 타이핑을 해보십시오. 언급 된 대부분의 기술은 설치하기가 어렵지 않습니다. –

+0

@BenjaminUdinktenCate 알아요.하지만 더 숙련 된 (또는 비슷한 문제가있는) 사람에게 가장 좋은 기술을 제안 해 줄 것을 요청할 것이라고 생각했습니다. – omninonsense

답변

2

신호를 사용하여 실행중인 프로세스와 통신하는 것이 좋습니다.

내 접근 방식은
이지만 가장 좋은 추천은 Espresso Framework입니다.

여기 거래가 있습니다. kill 인터페이스를 통해 프로세스에 보낼 수있는 많은 신호가 있습니다.

다른 Ruby 프로세스의 명령 행에서 신호를 보낼 수 있습니다.

당신이 필요로하는 모든 것은 앱 내부에서 보내진 신호를 잡거나 잡는 것입니다.

예 : 내부 통제 과정 :

# build your app 

Signal.trap("USR1") do 
    # do some stuff here 
end 

Signal.trap("USR2") do 
    # do another stuff here 
end 

# run your app 

당신은 당신의 애플 리케이션이 PID를 얻을 수 있는지 확인 시작할 때. (가) PID 당신이 kill
(이에 대한 명시적인 신호를 전송하지 않는 한, 그것은 늘 당신의 응용 프로그램을 죽일)를 통해 앱에 신호를 보낼 수있는 데

.명령 줄에서 직접

Process.kill "USR1", PID 

을 또는 :

그러면 또 다른 루비 과정에서 당신이 할 수있는

kill USR2 PID 

그리고 앱/잡기 트랩 신호를 전송하고 해당 물건을 할 것입니다.

PID을 제어 된 앱의 실제 프로세스 ID로 바꾸십시오.

이 방법은 Unicorn 웹 서버에서 성공적으로 사용됩니다. 루비에서 신호 작업에

http://en.wikipedia.org/wiki/Unix_signal

일부 통찰력 :

https://jellyjelly.net/blog/2010/04/27/unix-signal-programming-in-ruby/

0

당신은 RabbitMQ 같은 로컬 메시지 큐를 사용할 수있다 (AN 여기

는 신호의 목록입니다 AMQP 구현) 그러나 언급 한 것처럼 Redis를 사용하는 것과 사실상 동일합니다.

이러한 종류의 접근 방식은 OS 고유의 프로세스 간 통신 메커니즘에 의존하지 않습니다. 그렇습니다. 다른 서비스를 운영 할 것이지만 낮은 수준의 서비스에는 연결되지 않을 것입니다. 규모를 확장 할 때가되면 아주 좋은 방법입니다.