이 기사는 CloudWeGo 2주년 축하 시리즈의 세 번째 기사입니다.
지난 1년 동안 CloudWeGo Rust 팀이 수행한 작업을 되돌아보면, 두 가지 키워드로 요약하자면 성능 최적화와 생태학적 구축입니다. 이 글은 크게 세 가지로 나누어져 있는데, 첫 번째는 올해 Volo의 발전을 대략적으로 요약하고 검토하는 것입니다. 두 번째는 Volo의 성능 최적화에 초점을 맞추는 것입니다. 상들.
1. 올해 볼로
2022년 8월, 우리는 " Rust 언어를 기반으로 한 중국 최초의 RPC 프레임워크 - Volo가 공식적으로 오픈 소스입니다 볼로(Volo ) - 기능 완성 및 성능 최적화, 필로타(Pilota ) - 안정화, 메타인포 (Metainfo) - 사용 편의성입니다.
특히, 올해 Volo의 주요 노드와 기술 업데이트 중 일부를 검토해 보시기 바랍니다.
-
오픈 소스 직후 커뮤니티 동급생 @anwentec로부터 첫 번째 PR을 받았습니다. 이 PR은 주로 사용자가 Windows에서 개발을 위해 Volo를 사용하도록 지원하며 이는 프레임워크의 다중 플랫폼 지원을 크게 보완합니다.
-
그 직후 우리는 출시 이후 첫 번째 주요 성능 최적화인 인코딩 및 디코딩 재구성을 시작했습니다. 이 최적화는 원래 Pilota의 커뮤니티 동급생 @ii64가 Thrift 프로토콜을 지원하기 위해 제안한 PR에서 영감을 얻었습니다. 우리는 Volo의 기존 기능이 사용자가 사용자 정의 코덱을 입력하는 것을 제대로 지원할 수 없다는 것을 발견하여 현재 Volo 코덱 재구성 및 최적화를 보유하고 있습니다.
-
이 과정에서 우리는 최적화를 지원할 뿐만 아니라 Rust 오픈 소스의 관련 생태계를 풍요롭게 하는 두 개의 크레이트인 linkedbytes 및 faststr도 출시했다는 점을 언급할 가치가 있습니다.
-
마지막으로 인코딩 및 디코딩 측면에서 안전하지 않은 코드를 통해 일부 경계 검사를 우회하여 보조 컴파일러가 보다 효율적인 SIMD 병렬 연산 명령을 생성할 수 있도록 하여 성능을 크게 향상시켰습니다. Volo의 더 자세한 진행 상황을 알고 싶다면 CloudWeGo 공식 웹사이트 에서 릴리스 노트를 확인 하세요.
2. 성능 최적화
RPC 프레임워크에서 성능을 가장 많이 소모하는 측면은 직렬화 와 네트워크 통신 입니다 . 우리의 성능 최적화는 주로 이 두 가지 사항에 중점을 둡니다. 아래 그림은 완전한 RPC 호출 링크를 보여줍니다. 우리의 최적화 작업은 기본적으로 이러한 CPU 집약적 및 IO 집약적 작업에 집중되어 있습니다. 아래에서 자세히 소개할 인코딩 및 디코딩 재구성 최적화는 주로 In에 중점을 두고 있습니다. 직렬화 인코딩 및 디코딩 부분은 심층적인 성능 최적화에 참여하고 싶다면 좋은 참고 자료가 될 것입니다.
2.1 코덱 재구성 최적화
이 영역의 최적화는 주로 메모리의 제로 복사 작업입니다. RPC 호출을 할 때 사용자 요청 구조는 바이너리 바이트 스트림으로 직렬화되어 사용자 모드 메모리에 저장된 다음 전송을 위해 쓰기 시스템 호출을 통해 커널 모드 메모리에 기록되어야 한다는 것을 알고 있습니다. -우리가 최적화한 복사 부분은 첫 번째 단계에서 사용자 모드 메모리에 저장됩니다. 대부분의 구현에서는 쓰기 시스템 호출에 기록된 내용이 연속 메모리여야 하기 때문에 String
이러한 유형의 직렬화 에 대한 복사 오버헤드가 있습니다 . Vec<u8>
그렇다면 질문은 연속적인 메모리 쓰기가 필요하지 않은 경우 여기의 복사본을 생략할 수 있습니까? 대답은 분명합니다. 사용자 요청 구조에서 메모리를 재사용한 다음 쓰기를 위해 연결된 목록 형태로 메모리를 함께 연결하면 복사 오버헤드를 줄일 수 있습니다.
메모리를 재사용하려면 이 메모리가 언제 해제될 수 있는지 결정하기 위해 참조 카운팅을 도입하는 것이 불가피합니다. 결과적으로 원래의 두 가지 유형인 String
및 는 요구 사항 Vec<u8>
을 충족하지 않습니다. 다행스럽게도 오픈 소스 커뮤니티에는 대안으로 사용할 수 있는 바이트열 라이브러리 구조가 이미 있습니다 . 그러나 좋은 대체품은 없으며 이것이 faststr 라이브러리가 탄생한 이유 중 하나입니다.Arc<String>
Arc<Vec<u8>>
Vec<u8>
Bytes
String
faststr 라이브러리는 주로 FastStr
구조체를 제공하는데, 그 구조체에서의 표현은 실제로는 다양한 문자열 타입을 모아놓은 형태이므로, 이를 사용하면 사용자가 문자열 타입을 선택하는 방법에 대한 정신적 부담을 많이 줄일 수 있습니다. 위의 메모리 재사용 요구 사항을 충족하는 것 외에도 스택에 직접 메모리를 할당하는 등 작은 문자열에 대한 특정 최적화 기능도 있습니다. 물론 여기에 있는 일부 사람들은 요구 &str
사항을 충족할 수 있다면 왜 faststr이 여전히 필요한가요? 실제로는 그렇지 않습니다. 일부 시나리오에서는 수명 주기를 표현할 수 없습니다. 이 부분에 대한 자세한 설명은 faststr 문서를 참조하세요.
String
linkedbytes 라이브러리는 주로 연결된 목록의 아이디어를 바탕 으로 writev 시스템 호출을 통해 위에서 재사용한 Vec<u8>
메모리를 씁니다 . LinkedBytes에는 두 가지 주요 부분이 있습니다. 하나는 비합계 String
메모리를 임시로 저장하는 필드이고 Vec<u8>
, bytes
다른 하나는 메모리를 함께 연결하는 필드입니다 list
. 삽입의 논리를 간략히 살펴보면 Bytes
, 먼저 현재 임시로 저장되어 있는 연속 메모리를 분할하여 삽입 list
한 후, 들어오는 것을 삽입하면 Bytes
됩니다.
2.2 안전하지 않은 코덱 최적화
이 영역의 최적화는 주로 컴파일러가 효율적인 어셈블리 코드를 생성하도록 돕는 것입니다. encode를 예로 들면, 일반적인 상황에서 메모리에 쓸 때 Vec<i64>
아래와 같이 코드를 작성하는 것이 쉽습니다. 즉, this 를 직접 탐색한 Vec
다음 put_i64()
메소드를 호출하여 작성하는 것입니다.
하지만 메소드의 구현을 자세히 살펴보면 put_i64()
, 쓸 때마다 먼저 메모리가 충분한지 확인하고, 충분하지 않으면 쓰기 전에 메모리를 확장한다는 것을 알 수 있습니다. 그래서 처음부터 충분한 메모리를 할당했다면 여기서는 경계체크를 완전히 생략할 수 있기 때문에 약간 수정해서 아래와 같이 코드를 작성할 수 있습니다.
코드를 작성한 후 다음 단계는 성능 테스트입니다. 간단히 벤치를 작성하고 실행해 보면 알 수 없습니다. 이전에 생각했던 것과 똑같이 경계체크만 없애면 성능향상은 그리 크지 않을 텐데, 실제로 아래 그림을 보면 7~8배 정도의 이득이 있다는 것을 알 수 있습니다.
그렇다면 왜 그런지 좀 더 자세히 살펴봐야 할까요? 속담처럼, 심층적으로 최적화하려면 어셈블리 코드를 실행할 수 없습니다. 두 가지를 모두 어셈블리 코드로 변환하고 다시 살펴보겠습니다. 다음 두 그림은 작성 과정에서 어셈블리 코드의 일부를 캡처합니다.
이것을 읽고 나면 SIMD 명령어에 익숙한 학생들이 갑자기 깨어났을 것입니다. 경계 검사를 제거한 후 어셈블리 코드에서 SIMD 명령어를 사용하여 메모리 쓰기 속도를 높일 수 있습니다. 성능상의 이점도 합리적인 것 같습니다.
3. 향후 전망
마지막으로, 현재 저희가 시도하고 있는 일부 프로젝트와 앞으로 집중적으로 최적화할 부분에 대한 스포일러를 말씀드리겠습니다.
1. 새로운 프로젝트
첫 번째는 Shmipc-rs 프로젝트입니다. CloudWeGo에 익숙한 학생들은 Shmipc가 이제 오픈 소스 프로젝트라는 것을 알 수 있지만 이는 Spec 및 Go 언어 버전의 구현일 뿐입니다. Rust 언어 버전의 구현입니다. , 성능 향상을 위해 Volo에도 통합될 예정입니다. Shmipc는 공유 메모리를 기반으로 하는 프로세스 간 통신이며 주로 대규모 패킷 및 높은 처리량 시나리오에 적합합니다.
두 번째는 커뮤니티에서 널리 사용되는 Axum 프레임워크와 일관된 개발 경험을 제공하는 Volo-http 프로젝트이며, 미들웨어 부분은 자체 오픈 소스 Motore를 기반으로 구현되어 향후 일부 성능 향상을 가져올 것입니다. 또한 Volo-gRPC 프로젝트와 결합하여 게이트웨이 및 기타 기능을 제공할 것으로 예상됩니다. 현재 사용 가능하며 누구나 함께 경험하고 구축할 수 있습니다.
2. 사용 편의성 최적화
첫 번째는 문서화 부분입니다. 현재 Volo에는 많은 기능이 있지만 대부분 설명할 문서가 부족하여 사용자가 제대로 사용하고 경험할 수 없습니다. 문제에 대한 후속 조치를 취하면 누구나 참여할 수 있습니다.
두 번째는 모범 사례 부분입니다. 현재 Volo에는 사용자가 배우고 사용할 수 있는 간단한 예제 데모만 있을 뿐 사용자가 Volo 프레임워크를 배우고 이해할 수 있는 중소 규모의 프로젝트는 없습니다. 앞으로 더욱 강화되어야 할 부분입니다. 여러분이 추진할 것을 추천하는 프로젝트가 있다면 이슈를 열어 함께 논의해 보시기 바랍니다.
이상은 CloudWeGo 2주년을 맞아 Volo 오픈소스 1주년에 대한 리뷰와 전망입니다.
프로젝트 주소
GitHub: https://github.com/cloudwego 공식 웹사이트: www.cloudwego.io
"Celebrateing More Than Years 2"의 불법 복제 리소스가 npm에 업로드되어 npmmirror가 unpkg 서비스 를 중단해야 했습니다. Microsoft의 중국 AI 팀은 수백 명의 사람들을 모아 미국으로 떠났습니다. 프론트엔드 시각화 라이브러리와 Baidu의 유명한 오픈 소스 프로젝트 ECharts - Fish 사기꾼을 지원하기 위한 "going to the sea"는 TeamViewer를 사용하여 398만 개를 전송했습니다! 원격 데스크톱 공급업체는 무엇을 해야 합니까? Zhou Hongyi: Google은 시간이 얼마 남지 않았습니다. 모든 제품을 오픈소스로 만드는 것이 좋습니다. 한 유명 오픈소스 회사의 전직 직원이 소식을 전했습니다. 부하 직원의 도전을 받은 후 기술 리더는 분노했습니다. Google은 Android 가상 머신에서 ChromeOS를 실행하는 방법을 보여주었습니다. 여기서 time.sleep(6)은 어떤 역할을 합니까? 마이크로소프트, 중국 AI 팀이 "미국을 위해 준비 중"이라는 루머에 대응 사무용 소프트웨어의 마트료시카 같은 충전에 대한 인민일보 온라인 논평: "세트"를 적극적으로 해결해야만 미래를 가질 수 있다