랙에서 동시 요청 처리 옵션을 완전히 이해하려고합니다. 나는 long-polling 앱을 만들기 위해 async_sinatra를 사용했으며, 이제 throw :async 및/또는 Thin-threaded 플래그를 사용하여 베어 메탈 랙을 실험하고 있습니다. 나는 그 주제에 만족하지만, 나는 단지 이해할 수없는 것들이있다. (아니요, 병렬성에 대한 동시성을 오해하지 않고 있습니다. 예, GIL이 부과 한 한계를 이해하고 있습니다.)랙 동시성 - rack.multithread, async.callback 또는 둘 다?
Q1. 테스트 결과 thin --threaded (즉 rack.multithread=true)은 별도의 스레드 (EM 사용을 전제로 함)로 동시에 요청을 실행합니다. 즉, 장기 실행 요청 A는 요청 B (IO 제외)를 차단하지 않습니다. 즉, 응용 프로그램에 동시성을 얻기 위해 특별한 코딩 (예 : 콜백)이 필요하지 않습니다 (다시 DB 호출, IO 등을 차단하지 않음). 이것이 내가 관찰 한 것으로 믿는다. 맞습니까?
질문 2. 동시성을 달성하는 또 다른 방법으로는 EventMachine.defer과 throw :async이 있습니다. 엄밀히 말하면, 요청은 이 아니고은 스레드를 사용하여 처리됩니다. 그들은 순차적으로 다루어 지지만, heavyly lifting과 콜백을 EventMachine으로 전달합니다. EventMachine은 async.callback을 사용하여 나중에 응답을 보냅니다. 요청 A가 작업을 EM.defer로 오프로드 한 후에 요청 B가 시작됩니다. 이것이 맞습니까?
3. 위의 내용이 정확하다고 가정하면 은 다른 방법보다 한 가지 방법에 특별한 이점이 있습니까? 분명히 --threaded은 마법의 총알처럼 보입니다. 단점이 있습니까? 그렇지 않다면 모두가 왜 async_sinatra/throw :async/async.callback에 대해 이야기하고 있습니까? 아마 이전 버전은 "나는 Rails 앱을 무거운 짐을 싣고 약간 더 부드럽게하고 싶다"는 것이고, 후자는 장기 실행 요청이 많은 앱에 더 적합할까요? 아니면 규모가 중요한 요소일까요? 그냥 여기서 추측 해.
MRI 루비 1.9.2에서 씬 1.2.11을 실행 중입니다. (epoll에 루비 1.9.2의 EventMachine의 사용과 a long-standing, supposedly-resolved-but-not-really problem을 거기로 참고로, 나는 --no-epoll 플래그를 사용해야 즉, 지점 옆에, 그러나 어떤 통찰력을 환영합니다..)
epoll 문제는 해당 티켓에서 말한대로 [커밋] (https://github.com/eventmachine/eventmachine/commit/d684cc3b77a6c401295a3086b5671fe4ec335a64)으로 수정해야합니다. 나는 --no-는 epoll 플래그를 제거하면 – Bitterzoet
내 스레드 요청 분에 밀리 초에서 이동합니다. EM 0.12.10, Ruby 1.9.2-p180. 나는 p290을 컴파일하려고 시도 할 수 있다고 생각합니다 ... – bioneuralnet
좋은 질문입니다. 나는 비슷한 질문을 여기에 : http://stackoverflow.com/questions/8146851/how-to-deploy-a-threadsafe-asynchronous-rails-app 및 https : // github 여기 몇 가지 실험을 수행했습니다. com/jjb/threaded-rails-example (스레드 thin이 비동기식으로 성공적이지만 벤치 마크 속도가 느리다는 점에 유의하십시오) –