Webrick을 프로덕션 서버로 사용해서는 안된다는 것이 당연한 것처럼 보이지만 그 이유를 언급하는 곳은 어디에도 없습니다. 합의는 다음과 같습니다. “Webrick은 개발에 적합하지만 Thin 또는 Unicorn은 생산, 기간에 대한 선택입니다.”
Thin 서버의 홈페이지를 검색했는데 초당 요청에 대해 이야기했지만 주석이 없기 때문에 그래프를 실제로 이해하지 못합니다.
Webrick과 비교하여 Thin 또는 Unicorn을 사용해야하는 이유를 알려 주실 수 있습니까? Webrick을 개발에 사용하면 어떤 이점이 있습니까? 저는 Webrick이 레일과 함께 제공되기 때문에 사용해 왔으며 이것이 기본값 인 이유가 있어야한다고 생각합니다.
그런데 Heroku를 사용하고 있습니다.
답변
몇 가지 중요한 이유
- Ruby로 작성되었습니다. http://github.com/ruby/ruby/tree/trunk/lib/webrick 참조 )
- 수정 됨 은 (특히, 수명주기 관리, 비동기 처리 등 포크 (fork)를 사전), 리디렉션, 재 작성 등 생산 웹 사이트는 일반적으로 다수의 노동자처럼, 필요로하는 많은 기능을 가지고 있지 않습니다
리디렉션 / 재 작성에 대해 언급 할 때 Webrick을 사용하면 다른 레이어 (Rack, Sinatra, Rails, 사용자 지정 Webrick 코드 등)에서 재 작성을 처리해야한다는 사실을 언급하고 있습니다. 재 작성 코드를 수행하려면 추가 루비 “핸들러”를 가동해야합니다. 트래픽이 적은 사이트의 경우 사전 예열 된 프로세스가 이미 아무 작업도 수행하지 않을 수 있으므로 괜찮을 수 있습니다. 그러나 트래픽이 더 많은 사이트의 경우 이는 프런트 엔드 서버 (Apache, Nginx 등)가 Ruby *를 가동하지 않고도 처리 할 수있는 서버에 대한 추가 부하이며 아마도 훨씬 더 빠를 것입니다.
* 예를 들어로드 밸런서 뒤에서 실행중인 경우 모든 재 작성 트래픽을 Ruby가 설치되지 않은 서버로 라우팅하고 주 서버가 기본 트래픽 만 관리하도록 할 수 있습니다. 이 재 작성 트래픽은 SEO 또는 이와 유사한 사이트 변경으로 인한 것일 수 있습니다. 또 다른 경우는 여러 구성 요소가있는 사이트 일 수 있습니다. 한 섹션은 Rails이고 다른 섹션은 PHP이며 둘 다에 대해 다시 작성해야합니다 (예 : 이전 PHP 경로를 Rails에 다시 작성).
답변
WEBrick은 또한 더 긴 URI를 처리 할 수 없습니다. 2083자를 초과하면 충돌이 발생합니다. Thin에는 이러한 문제가 없으므로 이미 개발 중입니다.
답변
저는 단순한 일과 조기 최적화를 복잡하게 만드는 것을 좋아하지 않습니다. WEBrick은 트래픽이 적은 웹 사이트 라면 프로덕션 에 사용할 수 있습니다 . 대부분의 응용 프로그램이 있습니다.
사이트에서 이메일을 보내거나 PDF 파일을 생성하는 등 시간이 걸리는 작업을 수행 하는 경우 WEBrick을 다중 스레드로 만들어야 합니다. 한 번에 여러 요청을 처리하려고합니다.
답변
과거에는 보안 문제가 있었지만 큰 이유는 프로덕션 용 서버에 비해 정말 느리기 때문입니다.
답변
프로덕션 모드에서 실행할 때 webrick의 가장 큰 약점은 단일 스레드, 단일 프로세스 웹 서버라는 것입니다. 즉, 한 번에 하나의 단일 http 요청 만 처리 할 수 있습니다.
답변
