FizzBoom 기준(참여 요청)

나는 최근에 어둠의 백엔드에서 어떻게 가장 큰 성능을 얻을 수 있는지 시험해 왔다.저reimplemented는 각종 언어와 웹 프레임워크에서Dark의 핵심, 특히 OCAml, F#과Rust에서 이해했습니다.
알림으로 Dark는 백엔드 웹 서비스와 API를 구축하는 데 사용되는 언어와 플랫폼입니다.실현에 있어서, 그것은 기본적으로 웹 서버와 데이터베이스에 연결된 해석기이다.이 언어는 정적 유형의 함수식, 변할 수 없는 언어로 쓰레기 수집이다.
어둠의 사용자는 우리 서버에서 실행되는 임의의 코드를 작성할 수 있으며, 느리고 행동이 나쁜 제3자 웹 서버에 대해 HTTP 호출을 할 수 있다.이것은 우리가 서버에서 계산과 IO를 효율적으로 지원해야 한다는 것을 의미한다.이 기준은 이 점을 평가하는 데 목적을 두고 있다.

거품.
Fuzz Buzz는 모두가 알고 있는 면접 문제로 과거 시대에 적용될 수도 있고 적용되지 않을 수도 있지만 면접에 진전이 없기 때문에 오늘날에도 존재한다.3이나 5로 나누어질 수 있는 숫자를 100개씩 보여 달라고 합니다. 'fizz' 나 'buzz' 를 각각 출력할 수 있습니다.
FizzBoom은 같은 기준 테스트로 숫자를 3과 5로 나눌 수 있을 때를 제외하고'fizzbuzz'를 출력하지 않고 로컬 서버에 HTTP 호출을 하는 데 1초의 응답 시간이 걸린다.다음은 이 사진이 어둠 속의 모습이다.

let range = List::range 1 100
List.map range \i ->
                  if i % 15 == 0
                  then
                    HttpClient::get "http://localhost:8000/delay/1"
                  else if i % 3 == 0
                       then "Fizz"
                       else if i % 5 == 0
                            then "Buzz"
                            else toString i

참여를 호소하다
보통 누군가가 기준을 세워 야외에 내놓는다.그들은 예외 없이 몇 가지를 소홀히 했고, 무리를 지은 언어 창도자들은 이것이 얼마나 불공평한지 비난했다.이런 불공평함을 피하기 위해 언어 창도자들에게 기회를 만들어 기준을 발표하기 전에 기준을 개선하고 싶습니다.나는 아래에서 이 목표들을 토론할 것이지만, 당신이 원한다면 직접 issues 로 뛰어넘을 수 있습니다.
이 기준은 두 개의 숫자를 평가하는데 wrk를 사용하여 계산한다.

초당/fizzbuzz에 대한 HTTP 호출 요청, 후자는FuzzBuzz를 JSON

으로 되돌려줍니다

초당/fuzzboom에 대한 HTTP 호출 요청을 JSON 형식으로 FizzBoom으로 되돌려줍니다.

초보적인 데이터Chris의reporting these는F#이좋다(25k요구/초)는것을 나타냈고,Rust와OCAml은FizzBuzz방면에서양호하다(각16k요구/초)는것을 나타냈다.

    Benchmark name                Req/s
    ---------------------------------------------------------
    fsharp-giraffe:               24962.95
    fsharp-giraffe-async:         19476.78
    fsharp-suave-async:            1147.71
    fsharp-suave-partial-async:   Skipping broken benchmark
    ocaml-httpaf:                 14034.62
    ocaml-httpaf-lwt:             14158.74
    rust-hyper:                   15985.69
    rust-hyper-async:             Skipping broken benchmark

그러나 이것은 우리가 어떤 플랫폼에서도 비동기적인 조작을 정확하게 하지 않았다는 것을 보여준다. FizzBoom은 모든 플랫폼에서 1req/s의 속도로 운행하고 있다.분명히 이것은 내가 쓴 코드가 작용하지 않기 때문이지, 실제로는 언어와 구조에 대한 반영이 아니다.

    Benchmark name                Req/s
    --------------------------------------------------------
    fsharp-giraffe:               1.00
    fsharp-giraffe-async:         8.99
    fsharp-suave-async:           1.00
    fsharp-suave-partial-async:   Skipping broken benchmark
    ocaml-httpaf:                 0.10
    ocaml-httpaf-lwt:             0.10
    rust-hyper:                   Invalid fizzboom output
    rust-hyper-async:             Skipping broken benchmark

네가 가장 좋아하는 언어의 성능을 향상시키다
기본 테스트에서 자신의 언어가 잘될까 봐 걱정하거나 도움을 청하고 싶을 때 다음과 같은 몇 가지 일을 할 수 있습니다.

언어 최적화 웹 서버: 성능이 좋지 않은 웹 서버를 사용했을 수도 있습니다. 설정이 좋지 않거나 연결이 좋지 않을 수도 있습니다

복구 언어의 비동기 기준: 제3자 웹 서버에 HTTP 호출을 할 때 서버는 IO가 실행될 때 CPU를 풀어 다른 요청을 처리해야 한다.나는 아직 그것을 어떤 언어에서도 정상적으로 작동하게 하지 않았다. (왜 모든 플랫폼에서 보잘것없는 것이 아닌지 모르겠지만, 우리는 해냈다.)

언어의 구축 성능 최적화: 가능한 한 최적화할 수 있도록 구축 설정을 복원합니다.

나도 통역사의 실시를 개선하는 것에 흥미가 있지만 매우 신중하다.통역사에 대한 주요한 지도는 수정하고 확장하기 쉽다는 것이다. 다크는 큰 변화를 겪고 있는 언어이기 때문에 JIT, 어셈블리 또는 엿보기공으로 통역사를 최적화하는 것은 내가 흥미를 느끼는 일이 아니다.그러나 모든 언어에 적용되든 당신이 가장 좋아하는 언어의 특정한 기능을 보여주든 큰 성공을 거두고 작은 변화를 실현하는 것은 가치가 있다.그럼에도 불구하고, 나는 이 문제에 있어서 상당히 보수적이다. 나는 그것을 게임으로 만들고 싶지 않다. 게임에서 우리는 비관용적인 코드를 써서 아무도 유지하고 싶지 않은 승리를 짜내고 싶지 않다.
만약 네가 도와주기를 원한다면, 나는 이미 위에 issues를 기입하고 some rules to keep the benchmark fair를 썼다.나는 대부분의 테스트 결과가 효력을 발생하게 되면 가능한 한 빨리 기준 테스트 결과를 발표하기를 바란다.
너는 Darkhere에 등록해서 우리의 contributor Slack나 우리의 GitHub repo에서 우리의 진도를 볼 수 있다.어둠을 따라(또는) 계속하거나 따라the blog using RSS.