리프트 웹 프레임 워크가 확장 가능한 이유는 무엇입니까?

리프트 웹 프레임 워크가 확장 가능한 이유는 무엇입니까?

---

리프트 웹 프레임 워크가 높은 성능과 확장 성을 갖는 기술적 이유를 알고 싶습니다. 액터 라이브러리가있는 스칼라를 사용한다는 것을 알고 있지만 설치 지침에 따르면 기본 구성은 부두입니다. 그렇다면 액터 라이브러리를 사용하여 확장합니까?

이제 바로 사용할 수있는 확장 성입니다. 서버와 노드를 추가하기 만하면 자동으로 확장됩니다. 작동 방식입니까? 지원 서버와 500000 개 이상의 동시 연결을 처리 할 수 ​​있습니다.

저는 엔터프라이즈 수준을위한 웹 서비스 프레임 워크를 만들려고합니다.이 프레임 워크는 외부에있는 것을 능가 할 수 있고 확장, 구성 및 유지 관리가 쉽습니다. 확장에 대한 나의 정의는 단지 더 많은 서버를 추가하는 것이며 추가로드를 수용 할 수 있어야합니다.

감사

---

확장성에 대한 Lift의 접근 방식은 단일 시스템 내에 있습니다. 머신 간 확장은 더 크고 어려운 주제입니다. 짧은 대답은 다음과 같습니다. Scala와 Lift는 수평 적 확장을 돕거나 방해하지 않습니다.

단일 머신 내의 행위자에 관한 한, Lift는 단일 인스턴스가 대부분의 다른 서버보다 더 많은 동시 요청을 처리 할 수 ​​있기 때문에 더 나은 확장 성을 달성합니다. 설명하기 위해 먼저 고전적인 요청 당 스레드 처리 모델의 결함을 지적해야합니다. 저를 참아주세요, 이것은 약간의 설명이 필요할 것입니다.

일반적인 프레임 워크는 스레드를 사용하여 페이지 요청을 서비스합니다. 클라이언트가 연결되면 프레임 워크는 풀에서 스레드를 할당합니다. 그 스레드는 다음 세 가지 작업을 수행합니다. 소켓에서 요청을 읽습니다. 일부 계산을 수행합니다 (잠재적으로 데이터베이스에 대한 I / O 관련). 소켓에서 응답을 보냅니다. 거의 모든 단계에서 스레드는 얼마 동안 차단됩니다. 요청을 읽을 때 네트워크를 기다리는 동안 차단할 수 있습니다. 계산을 수행 할 때 디스크 또는 네트워크 I / O에서 차단 될 수 있습니다. 데이터베이스를 기다리는 동안 차단할 수도 있습니다. 마지막으로 응답을 보내는 동안 클라이언트가 데이터를 느리게 수신하고 TCP 창이 가득 차면 차단할 수 있습니다. 전반적으로 스레드는 차단 된 시간의 30 ~ 90 %를 소비 할 수 있습니다. 그러나 하나의 요청에 100 %의 시간을 소비합니다.

JVM은 실제로 속도가 느려지기 전에 너무 많은 스레드 만 지원할 수 있습니다. 스레드 스케줄링, 공유 메모리 엔티티 (예 : 연결 풀 및 모니터)에 대한 경합 및 기본 OS 제한은 모두 JVM이 작성할 수있는 스레드 수에 제한을 부과합니다.

JVM이 최대 스레드 수로 제한되고 스레드 수가 서버가 처리 할 수있는 동시 요청 수를 결정하는 경우 동시 요청 수는 스레드 수에 따라 결정됩니다.

(하한을 부과 할 수있는 다른 문제가 있습니다. 예를 들어 GC 스 래싱이 있습니다. 스레드는 근본적인 제한 요소이지만 유일한 요소는 아닙니다!)

리프트는 요청에서 스레드를 분리합니다. Lift에서는 요청이 스레드를 묶지 않습니다 . 오히려 스레드는 작업 (예 : 요청 읽기)을 수행 한 다음 액터에게 메시지를 보냅니다. 배우는 "경량"스레드를 통해 예약되기 때문에 스토리의 중요한 부분입니다. 스레드 풀은 액터 내에서 메시지를 처리하는 데 사용됩니다. 액터 내부에서 작업을 차단하지 않도록하는 것이 중요하므로 이러한 스레드가 빠르게 풀로 반환됩니다. (이 풀은 애플리케이션에 표시되지 않으며 액터에 대한 Scala의 지원의 일부입니다.) 예를 들어 데이터베이스 또는 디스크 I / O에서 현재 차단 된 요청은 요청 처리 스레드를 점유하지 않습니다. 요청 처리 스레드는 거의 즉시 사용 가능하여 더 많은 연결을 수신 할 수 있습니다.

스레드에서 요청을 분리하는이 방법을 사용하면 Lift 서버가 요청 당 스레드 서버보다 더 많은 동시 요청을 가질 수 있습니다. (또한 Grizzly 라이브러리가 행위자없이 유사한 접근 방식을 지원한다는 점을 지적하고 싶습니다.) 동시 요청이 많을수록 단일 Lift 서버가 일반 Java EE 서버보다 더 많은 사용자를 지원할 수 있음을 의미합니다.

---

mtnyguard에서

"Scala와 Lift는 수평 적 확장을 돕거나 방해하지 않습니다."

옳지 않습니다. 리프트는 고도로 statefull 프레임 워크입니다. 예를 들어 사용자가 양식을 요청하면 양식 처리 작업이 서버 상태에 저장되기 때문에 양식이 생성 된 동일한 시스템에만 요청을 게시 할 수 있습니다.

그리고 이것은 실제로 확장 성을 방해하는 것입니다. 왜냐하면이 동작은 비공유 아키텍처와 일치하지 않기 때문입니다.

리프트의 성능은 높지만 성능과 확장 성은 두 가지가 다릅니다. 따라서 리프트를 사용하여 수평으로 확장하려면로드 밸런서에서 고정 세션을 정의해야합니다.이 세션은 세션 중에 사용자를 동일한 머신으로 리디렉션합니다.

---

Jetty는 진입 지점 일 수 있지만 배우는 결국 요청을 처리합니다. 매우 확장 가능한 서비스를 생성 할 수있는 방법을 알아 보려면 Twitter와 같은 예인 'skitter'를 살펴 보는 것이 좋습니다. IIRC, 이것은 트위터 사람들이 주목하게 만든 것 중 하나입니다.

---

저는 @dre의 대답이 수평 적 확장 성의 잠재적 인 문제가되는 리프트의 statefulness를 올바르게 언급했기 때문에 정말 마음에 듭니다.

문제-전체 내용을 다시 설명하는 대신이 게시물의 토론 (내용이 아님)을 확인하세요. http://javasmith.blogspot.com/2010/02/automagically-cluster-web-sessions-in.html

해결책은 @dre가 전면의로드 밸런서에 고정 세션 구성을 말하고 더 많은 인스턴스를 추가하는 것입니다. 그러나 리프트의 요청 처리는 스레드 + 액터 조합으로 수행되므로 하나의 인스턴스가 일반 프레임 워크보다 더 많은 요청을 처리 할 수 ​​있습니다. 이것은 다른 프레임 워크에서 고정 세션을 갖는 것보다 우위를 제공합니다. 즉, 더 많은 것을 처리 할 수있는 개별 인스턴스의 용량은 확장에 도움이 될 수 있습니다.

• 이것의 또 다른 장점이 될 Akka 리프트 통합이 있습니다.

참조 URL : https://stackoverflow.com/questions/648964/why-is-the-lift-web-framework-scalable