TechEmpower Motivation & Questions 한글 번역

TechEmpower

Motivation

Choosing a web application framework involves evaluation of many factors. While comparatively easy to measure, performance is frequently given little consideration. We hope to help change that.

웹 애플리케이션 프레임워크를 선택하는 데 여러가지 요소의 평가가 필요합니다. 

비교적 쉽게 측정할 수 있지만, 성능은 거의 고려되지 않는다. 우리는 그것을 바꿀 수 있기를 바랍니다. 

=> 쉽게 측정할 수 있는데 일반 개발자들은 그런거 고려안하고 하니까 대신 해준다는 말인듯

Application performance can be directly mapped to hosting dollars, and for companies both large and small, hosting costs can be a pain point. Weak performance can also cause premature and costly scale pain by requiring earlier optimization efforts and increased architectural complexity. Finally, slow applications yield poor user experience and may suffer penalties levied by search engines.

애플리케이션 성은 호스트비용에 직접적으로 매핑 될 수 있으며,  대기업과 중소 기업 모두 호스팅 비용이 문제가 될 수 있습니다.

부실한 성능은 최적화 노력과 아키텍처 복잡성의 증가를 필요로 하므로 조기에 비용이 많이 드는 고통을 야기할 수 있습니다.

마지막으로 느린 애플리케이션 프로그램은 사용자 경험이 부족하고 검색 엔진에 의해 부과된 패널티를 받을 수 있습니다.

What if building an application on one framework meant that at the very best your hardware is suitable for one tenth as much load as it would be had you chosen a different framework? The differences aren't always that extreme, but in some cases, they might be. Especially with several modern high-performance frameworks offering respectable developer efficiency, it's worth knowing what you're getting into.

하나의 프레임워크에 애플리케이션을 구축할 때 하드웨어에 적합한 프레임워크를 선택할 시간을 투자하는 것이 어떨까요?

항상 차이나는 건 아니지만, 몇 케이스에선 그렇게 될 수 있습니다.

특히 개발 효율성을 제공하는 몇몇 현대적인 고성능 프레임워크를 통해 무엇을 얻고 있는지 알 수 있습니다.

Terminology

framework

We use the word framework loosely to refer to any HTTP server implementation upon which you could build a web application—a full-stack framework, a micro-framework, or even a web platform such as Rack, Servlet, or plain PHP.

우리는 네가 a full-stack framework, a micro-framework, or even a web platform such as Rack, Servlet, or plain PHP와 같은 웹 어플리케이션을 작성할 수 있는 http 서버 구현을 참조하기 위해 프레임워크라는 용어를 씁니다.

platform

For us, platforms are broadly defined as anything situated between the programming language and the web framework (examples are Servlet, Netty, and Rack). By comparison to a full-stack framework or micro-framework, a platform may include a bare-bones HTTP server implementation with rudimentary request routing and virtually none of the higher-order functionality of frameworks such as form validation, input sanitization, templating, JSON serialization, and database connectivity. Frameworks are often built on top of platforms. To be thorough, and to compute framework overhead, we test several platforms as if they were frameworks.

우리에게 플랫폼이란 프로그래밍 언어와 웹 프레임워크 사이에 광범위하게 정의되어 있습니다. (예로 Sevlet, Netty, Rack)

풀 스택 프레임워크 또는 마이크로 프레임 워크와 비교할 때, 플랫폼 에는 기본적인 요청 라우팅을 갖춘 bare-bones HTTP 서버 구현과 폼 유효성 검사, 입력 소독, 템플릿 작성, JSON과 같은 프레임 워크의 고차원 기능 직렬화 및 데이터베이스 연결을 지원합니다.

프레임워크는 종종 플랫폼위에 만들어집니다. 프레임워크의 오버헤드를 철저하게 계산하고 우리는 플렛폼을 마치 프레임워크처럼 테스트합니다.

permutation

A combination of attributes that compose a full technology stack being tested (take node.js for example, we might have one permutation with MongoDB and another with MySQL). Some frameworks have seen many permutations contributed by the community; others only one or few.

테스트되는 전체 기술 스택을 구성하는 특성의 조합입니다.

(예를 들어, Moder와 다른 하나는 MongoDB와 MySQL을 가진 순열을 가지고 있을지도 모른다.) 

몇몇 프레임워크는 커뮤니티가 기여한 순열을 보았습니다. 다른 것은 단지 하나 또는 소수 일 뿐 입니다.

순열이란?

서로 다른 $n$개의 원소에서 $r$개를 중복없이 골라 순서에 상관있게 나열하는 것을 $n$개에서 $r$개를 택하는 순열이라고 한다

기호로는 $_nP_r, P\left(n,r\right)$등 여러가지가 있지만 자주 쓰이는 것은 $_nP_r$이다.뭔가 거창한 설명이 붙었지만 순열은 초등학교 때부터 알게 모르게 써왔던 수학 개념중 하나다[1]. 계산하는 방법도 초등학교에서 해왔던 방법 그대로이며, 단지 미지수가 추가된 것 뿐. 수식으로 나타내면 

$_nP_r=n\times\left(n-1\right)\times\left(n-2\right)\times\cdots\times\left(n-r+1\right)$[2]. 이를 팩토리얼을 사용하여 좀더 간략화 하면 $_nP_r=n!/\left(n-r\right)!$이다.

나무위키 참조

==> 여기서는 테스트해본 것들의 리스트를 말하는 듯합니다.

test type

One of the workloads we exercise, such as JSON serialization, single-query, multiple-query, fortunes, data updates, and plaintext.

JSON 직렬화, 단일 쿼리, 다중 쿼리, 운세, 데이터 업데이트 및 일반 텍스트와 같이 우리가 수행하는 작업 부하 중 하나입니다.

test

An individual test is a measurement of the performance of a permutation's implementation of a test type. For example, a test might be measuring Wicket paired with MySQL running the single-query test type.

개별 테스트는 테스트유형의 순열 구현 성능을 측정한 것입니다.

예를 들어, 단일 쿼리 테스트 유형을 실행하는 MySQL과 쌍을 이루는 Wicket을 테스트할 수 있습니다.

implementation

Sometimes called "test implementations," these are the bodies of code and configuration created to test permutations according to the requirements. These are frequently contributed by fans, advocates, or the maintainers of frameworks. Together with the toolset, test implementations are the meat of this project.

"테스트 구현"이라고도 불리는 이 코드 는 요구 사항 에 따라 순열을 테스트하기 위해 만들어진 코드 및 구성의 본문입니다

팬, 지지자 또는 프레임 워크의 유지 관리자가 자주 기여합니다. 툴셋과 함께 테스트 구현은 이 프로젝트의 핵심입니다.

toolset

A set of Python scripts that run our tests.

도구모음 : 우리의 테스트를 실행하는 파이선 스크립트 세트

run

An execution of the benchmark toolset across the suite of test implementations, either in full or in part, in order to capture results for any purpose.

어떤 목적 으로든 결과를 캡쳐하기 위해 전체 또는 일부의 테스트 구현 제품군 전반에서 벤치 마크 툴 세트를 실행합니다.

preview

A capture of data from a run used by project participants to sanity-check prior to an official round.

프로젝트 참가자가 공식적인 라운드 이전에 사용한 데이터의 수집에 사용되는 데이터 캡처.

round

A posting of "official" results on this web site. This is mostly for ease of consumption by readers and good-spirited & healthy competitive bragging rights. For in-depth analysis, we encourage you to examine the source code and run the tests on your own hardware.

"공식"결과를 이 웹사이트에 게시하였다. 이는 대부분 독자가 쉽게 사용할 수 있고 건강하고 경쟁력있는 자랑 할 수있는 권리입니다. 심층 분석을 위해 소스 코드를 검사하고 자신의 하드웨어에서 테스트를 실행하는 것이 좋습니다.

Expected questions

We expect that you might have a bunch of questions. Here are some that we're anticipating. But please contact us if you have a question we're not dealing with here or just want to tell us we're doing it wrong.

예상되는 질문

우리는 여러분이 많은 질문을 할 것으로 기대합니다. 여기에 우리가 예상하는 것들이 있습니다.

여기에 우리가 예상하는 것들이 있습니다.

그러나 우리가 여기에서 다루지 않는 질문이 있거나 우리가 잘못하고 있다고 우리에게 말하고 싶다면 우리에게 연락해주세요.

Frameworks and configuration

1. "You call x a framework, but it's a platform." See the terminology section above. We are using the word "framework" loosely to refer to anything found on the spectrum ranging from full-stack frameworks, micro-frameworks, to platforms. If it's used to build web applications, it probably qualifies. That said, we understand that comparing a full-stack framework versus platforms or vice-versa is unusual. We feel it's valuable to be able to compare these, for example to understand the performance overhead of additional abstraction. You can use the filters in the results viewer to adjust the rows you see in the charts.

1, x를 프레임워크라고 부르지만 그것은 플랫폼입니다. 위의 용어 섹션을 참고하세요.

우리는 full-stack frameworks, micro-frameworks, to platform에 이르기까지 넓은 모든 것을 나타내기 위해 프레임워크라는 단어를 사용합니다. 웹 어플리케이션 구축하는데 사용되는 경우 자격이 있을 수 있습니다.

 즉, full-stack frameworks와 flatforms 혹은 vice-versa를 비교하는 것은 전혀 이해할 수 없는 일입니다.

예를 들어 추가적인 추출의 성능 오버 헤드를 이해하기 위해 이를 비교할 수있는 것이 중요하다고 생각합니다. 

결과 뷰어의 필터를 사용하여 차트에 표시되는 행을 조정할 수 있습니다.

2. You configured framework x incorrectly, and that explains the numbers you're seeing." Whoops! Please let us know how we can fix it, or submit a GitHub pull request, so we can get it right.

"You configured framework x incorrectly, and that explains the numbers you're seeing."라는 말을 본다면 

어떻게 해결 할 수 있는 지 알려주거나, GitHub pull request 를 제출하여 알려주세요.

3. "Why include this Gemini framework I've never heard of?" We have included our in-house Java web framework, Gemini, in our tests. We've done so because it's of interest to us. You can consider it a stand-in for any relatively lightweight minimal-locking Java framework. While we're proud of how it performs among the well-established field, this exercise is not about Gemini.

"왜 들어 본 적없는 Gemini framework를 포함 합니까?" 우리는 내부 Java 웹 프레임워크인 Gemini를 테스트에 포함 시켰습니다. 

우리가 관심을 가지기 때문에 우리는 그렇게했습니다. 상대적으로 가벼운 소형 자바 프레임워크를 사용하는 것은 일종의 표준으로 간주할 수 있습니다. 우리가 잘 정립 된 분야에서 어떻게 작동하는지 자랑 스럽지만 이 실험은 Gemini에 관한 것이 아닙니다.

4. "Why don't you test framework X?" We'd love to, if we can find the time. Even better, craft the test implementation yourself and submit a GitHub pull request so we can get it in there faster!

"왜 프레임워크 X를 테스트 하지 않죠?" 우리는 더 좋은 방법을 찾는다면 더 좋아할 것입니다. 

더 좋은 방법은 초안을 스스로 테스트하고 GitHub에 제출해주세요. 그러면 더 빨리 얻을 수 있습니다.

5. "Some frameworks use process-level concurrency; have you accounted for that?" Yes, we've attempted to use production-grade configuration settings for all frameworks, including those that rely on process-level concurrency. For the EC2 tests, for example, such frameworks are configured to utilize the two virtual cores provided on an c3.large (in previous rounds, m1.large) instance. For the i7 tests, they are configured to use the eight hyper-threading cores of our hardware's i7 CPUs.

"일부 프레임워크는 프로세스 수준의 동시성을 사용합니다. 그걸 설명했나요?"

예. 우리는 프로세스 수준의 동시성에 의존하는 것을 포함하여 모든 프레임워크에 대해 프로덕션 수준의 구성 설정을 사용하였습니다.

예를 들어 EC2 테스트의 경우 이러한 프레임 워크는 c3.large(이전 라운드에는 m1.large) 인스턴스에 제공된 두 개의 가상 코어를 사용하도록 구성됩니다.

i7 테스트의 경우 하드웨어 i7 cpu의 8가지 하이퍼스레딩 코어를 사용하도록 구성됩니다.

6 "Have you enabled APC for the PHP tests?" Yes, the PHP tests run with APC and PHP-FPM on nginx.

" PHP 테스트를 위해 APC 를 활성화 했습니까 ?" 예, PHP 테스트는 APC 및 PHP-FPM과 함께 nginx에서 실행됩니다.

7 "Why are you using a (slightly) old version of framework X?" It's nothing personal! With so many frameworks we have a never-ending game of whack-a-mole. If you think an update will affect the results, please let us know (or better yet, submit a GitHub pull request) and we'll get it updated!

"왜 프레임워크 X의 이전 버전을 사용하고 있습니까?"

그것은 개인적인 것이 아닙니다. 너무 많은 프레임 워크는 끝이지 않은 게임을 하고 있다. (?)

만약 업데이트 결과에 영향을 미친다고 생각되면 알려 주시기 바랍니다. 

(GibHub 에 pull request 제출하는 것이 더 낫습니다.)

8. "It' unfair and possibly even incorrect to compare X and Y!" It may be alarming at first to see the full results table, where one may evaluate frameworks vs platforms; MySQL vs Postgres; Go vs Python; ORM vs raw database connectivity; and any number of other possibly irrational comparisons. Many readers desire the ability to compare these and other permutations. If you prefer to view an unpolluted subset, you may use the filters available at the top of the results page. We believe that comparing frameworks with plausible and diverse technology stacks, despite the number of variables, is precisely the value of this project. With sufficient time and effort, we hope to continuously broaden the test permutations. But we recommend against ignoring the data on the basis of concerns about multi-variable comparisons. Read more opinion on this at Brian Hauer's personal blog.

"X와 Y를 비교하는 것은 불공평하며 부정확할 수 도 있습니다!"

처음에는 frameworks vs platforms; Mysql vs Postgres; Go vs Python; ORM vs raw database connective 등 다른 많은 비합리적 비교 가능성이 있는 전체 결과 표를 볼 수 있습니다.

많은 독자들은 이러한 순열과 다른 순열을 비교할 수 있는 능력을 원합니다.

만약 바뀌지않은 하위 세트를 보려면, 결과 페이지의 맨 위에 있는 필터를 사용할 수 있습니다. 우리는 변수의 수와 다양한 기술 스택과 비교하여 체계적인 프레임워크를 비교하는 것이 정확하게 이 프로젝트의 가치에 해당한다고 믿습니다.

충분한 시간과 노력으로 테스트 순열을 지속적으로 확장할 수 있기를 발반디ㅏ. 그러나 다중 변수 비교에 대한 우려를 바탕으로 데이터를 무시하지 않는 것이 좋습니다. 브라이언 하우저의 개인 블로그에서 이것에 대해 더 많은 의견을 읽어 보세요.

9. "If you are testing production deployments, why is logging disabled?" At present, we have elected to run tests with logging features disabled. Although this is not consistent with production deployments, we avoid a few complications related to logging, most notably disk capacity and consistent granularity of logging across all test implementations. In spot tests, we have not observed significant performance impact from logging when enabled. If there is strong community consensus that logging is necessary, we will reconsider this.

"프로덕션 개발을 테스트하는 중이라면 로깅이 비활성화된 이유는 무엇입니까?"

현재 로그 기능을 사용하지 않도록 설정한 상태에서 테스트를 실행하도록 선택했습니다.

비록 이것이 프로덕션 개발과 일치하지 않지만, 우리는 로깅과 관련된 몇가지 복합성을 피할 수 있고, 

특히 디스크용량 및 모든 테스트 개발에 대한 로깅과 관련된 문제를 피할 수 있습니다.

테스트에서 로깅이 활성화 되었을 때 성능에 큰 영향을 주지 않음을 확인했습니다.

로깅이 필요한다는 강력한 커뮤니티의 의견이 있는 경우 이를 다시 고려할 것입니다.

10 "Tell me about the Windows configuration." We are very thankful to the community members who have contributed Windows tests. In fact, nearly the entirety of the Windows configuration has been contributed by subject-matter experts from the community. Thanks to their effort, we now have tests covering both Windows paired with Linux databases and Windows paired with Microsoft SQL Server. As with all aspects of this project, we welcome continued input and tuning by other experts. If you have advice on better tuning the Windows tests, please submit GitHub issues or pull requests.

"윈도우 구성에 대해 알려주세요"

윈도우 테스트에 기여한 커뮤니티 구성원들에게 감사합니다.

사실 상, 거의 모든 윈도우즈 구성 요소는 커뮤니티의 주제별 전문가들에 의해 기여되었습니다.

이들의 노력 덕분에 이제 윈도우 데이터베이스와 쌍을 이룬 윈도우와 MicrosoftSQLServer와 쌍을 이룬 윈도우를 모두 테스트할 수 있습니다.

이 프로젝트의 모든 측면과 마찬가지로, 우리는 다른 전문가들의 지속적인 투입과 조정을 환영합니다.

윈도우 테스트를 보다 효과적으로 조정하는 방법에 대한 조언이 있으면 Github에 요청해주세요.

The tests

11. "Framework X has in-memory caching, why don't you use that?" In-memory caching, as provided by some frameworks, yields higher performance than repeatedly hitting a database, but isn't available in all frameworks, so we omitted in-memory caching from these tests. Cache tests are planned for later rounds.

"프레임워크 X는 메모리 캐싱이 있습니다." 일부 프레임워크에서 제공하는 메모리 내 캐싱은 반복적으로 데이터베이스에 도달하는 것보다 더 높은 성능을 제공하지만 모든 프레임워크에서 사용할 수 있는 것은 아니므로 이 테스트에서 메모리 내 캐싱을 생략했습니다.

12. "What about other caching approaches, then?" Remote-memory or near-memory caching, as provided by Memcached and similar solutions, also improves performance and we would like to conduct future tests simulating a more expensive query operation versus Memcached. However, curiously, in spot tests, some frameworks paired with Memcached were conspicuously slower than other frameworks directly querying the authoritative MySQL database (recognizing, of course, that MySQL had its entire data-set in its own memory cache). For simple "get row ID n" and "get all rows" style fetches, a fast framework paired with MySQL may be faster and easier to work with versus a slow framework paired with Memcached.

다른 캐싱 접근은 어떨까요?" 

패스~

13. "Why doesn't your test include more substantial algorithmic work?" Great suggestion. We hope to in the future!

" 어째서 더 많은 실질적인 알고리즘 작업을 포함하지 않나요?"라고 제안이 있었습니다.

우리는 앞으로 그러길 희망합니다.

14. "What about reverse proxy options such as Varnish?" We are expressly not using reverse proxies on this project. There are other benchmark projects that evaluate the performance of reverse proxy software. This project measures the performance of web applications in any scenario where requests reach the application server. Given that objective, allowing the web application to avoid doing the work thanks to a reverse proxy would invalidate the results. If it's difficult to conceptualize the value of measuring performance beyond the reverse proxy, imagine a scenario where every response provides user-specific and varying data. It's also notable that some platforms respond with sufficient performance to potentially render a reverse proxy unnecessary.

"Varnish와 같은 역 방향 프록시 옵션은 어떻게 됩니까?"

이 프로젝트에서 역방향 프로시를 명시적으로 사용하지 않습니다.

역 방향 프록시 소프트웨어의 성능을 평가하는 벤치마크 프로젝트가 있습니다.

이 프로젝트는 애플리케이션 서버에 도달하는 모든 시나리오에서 웹 애플리케이션의 성능을 측정합니다.

이러한 목표를 고려할 때 웹 애플리케이션이 역방향 프록시 덕분에 작업을 수행하지 못하게 하면 결과가 무효화됩니다.

역 방향 프록시를 뛰어넘는 성능 측정 값을 개념화하는 것이 어렵다면, 모든 응답이 사용자별 및 다양한 데이터를 제공하는 시나리오를 상상해 보세요.

또한 일부 플랫폼에서는 잠재적으로 역 방향 프록시를 필요로 하지 않을 만큼 충분한 성능으로 응답합니다.

15. "Do all the database tests use connection pooling?" Yes, our expectation is that all tests use connection pooling.

모든 데이터베이스 테스트는 'Connection pooling'을 사용합니까?"

예, 모든 테스트가 'Connection pooling'을 사용한다는 것입니다.

16. "How is each test run?" Each test is executed as follows:

1. Restart the database servers.
2. Start the platform and framework using their start-up mechanisms.
3. Run a 5-second primer at 8 client-concurrency to verify that the server is in fact running. These results are not captured.
4. Run a 15-second warmup at 256 client-concurrency to allow lazy-initialization to execute and just-in-time compilation to run. These results are not captured.
5. Run a 15-second captured test for each of the concurrency levels (or iteration counts) exercised by the test type. Concurrency-variable test types are tested at 8, 16, 32, 64, 128, and 256 client-side concurrency. The high-concurrency plaintext test type is tested at 256, 1,024, 4,096, and 16,384 client-side concurrency.
6. Stop the platform and framework.

"각 테스트는 어떻게 실행됩니까?" 각 테스트는 다음과 같이 실행됩니다.

a. 데이터베이스 서버를 재시작합니다.

b. 시작 매커니즘을 이용하여 프래임워크 와 플랫폼을 시작합니다.

c.  클라이언트가 실제로 실행중인지 확인하기 위해 5초간 8클라이언트 분량의 프라이머를 실행합니다. 이 결과는 캡처되지 않습니다.

d.  lazy-initialization이 실행되고, just-in-time 컴파일이 실행되도록 256 클라이언트가 동시에 15 초 워밍업합니다. 

이 결과는 캡처되지 않습니다.

e. 테스트 유형에 따라 발휘되는 각각의 동시성 수준 (또는 반복 카운트) 각각에 대해 15초간 캡처하는 테스트를 실행합니다.

보안 가변형 테스트 유형은 8, 16, 32, 64, 128 및 256개의 클라이언트가 동시에 테스트합니다.

높은 동시성 일반 테스트 유형은 256, 1,024, 4,096 및 16,384개의 클라이언트가 동시에 테스트합니다.

f. 플랫폼과 프레임워크를 중지하세요.

17. "Hold on, 15 seconds is not enough to gather useful data." This is a reasonable concern. But in examining the data, we have seen no evidence that the results have changed by reducing the individual test durations from 60 seconds to 15 seconds. The duration reduction was made necessary by the growing number of test permutations and a target that the full suite complete in less than one day. With additional effort, we aim to build a continuously-running test environment that will pull the latest source and begin a new run as soon as a previous run completes. When we have such an environment ready, we will be comfortable with multi-day execution times, so we plan to extend the duration of each test when that happens.

"잠시만요, 15초는 유용한 데이터를 모으기에 충분하지 않습니다."

이것은 합리적인 문제입니다. 그러나 데이터를 검토할 때,  개별 테스트 기간을 60초에서 15초로 줄임으로써 결과가 변경되었다는 어떠한 증거도 발견하지 못했습니다. 지속 기간 감소(60초 -> 15초)는 테스트 리스트의 수가 증가하고 전체 제품군이 하루 안에 완료된다는 목표에 따라 필요했습니다.

추가적인 노력을 통해 우리는 이전의 테스트가 완료되자마자 최신 소스로 새로운 테스트를 시작하는 연속적인 테스트환경을 구축하고자 한다. 이러한 환경이 준비되었을 때, 여러 날의 실행 시간에 익숙해지므로 각 테스트의 지속 시간을 연장할 계획입니다.

18. "Also, a 15-second warmup is not sufficient." 

On the contrary, we have not yet seen evidence suggesting that any additional warmup time is beneficial to any framework.

 In fact, for frameworks based on JIT platforms such as the Java Virtual Machine (JVM), spot tests show that the JIT has even completed its work already after just the primer and before the warmup starts—the warmup (256-concurrency) and real 256-concurrency tests yield results that are separated only by test noise. However, as with test durations, we intend to increase the duration of the warmup when we have a continuously-running test environment.

"또한 15 초 워밍업으로는 충분하지 않습니다." 

반대로, 우리는 추가 워밍업 시간이 어떤 프레임 워크에 도움이된다는 증거를 아직 보지 못했습니다.

실제로, 자바 가상 머신(JVM)과 같은 JIT플랫폼에 기초한 프레임워크의 경우, JIT가 작성한 작업은 프라이머가 겨우 완료되기 전에 완료되었으며. 워밍업과 실제 256개의 동시 테스트는 테스트노이즈에 의 분리되어 결과를 야기한다 (?) 이해불가

하지만 테스트 기간과 마찬가지로, 우리는 지속적으로 실행되는 테스트 환경이있을 때 워밍업 기간을 늘릴 계획입니다.

Environment

19. "What is Wrk?" Although many web performance tests use ApacheBench from Apache to generate HTTP requests, we now use Wrk for this project. ApacheBench remains a single-threaded tool, meaning that for higher-performance test scenarios, ApacheBench itself is a limiting factor. Wrk is a multithreaded tool that provides a similar function, allowing tests to run for a prescribed amount of time (rather than limited to a number of requests) and providing us result data including total requests completed and latency information.

환경

"Wrk는 무엇인가?" 라고 많은 웹 성능 테스트가 Apaech의 ApacheBench를 사용하여 HTTP 요청을 생성하지만, 이제는 이 프로젝트에 Wrk를 사용합니다.  ApacheBench, 고성능 테스트 시나리오를 의미하는 단일 스레드 도구로 ApcacheBench 자체가 제한 요소입니다.

Wrk는 비슷한 기능을 제공하는 멀티 스레드 도구로서, 요청 수가 제한되지 않고 지정된 시간 동안 테스트를 실행하고 완료된 총 요청 및 대기 시간 정보를 포함한 결과 데이터를 제공합니다.

20. "Doesn't benchmarking on Amazon EC2 invalidate the results?" Our opinion is that doing so confirms precisely what we're trying to test: performance of web applications within realistic production environments. Selecting EC2 as a platform also allows the tests to be readily verified by anyone interested in doing so. However, we've also executed tests on our Core i7 (Sandy Bridge) workstations running Ubuntu as a non-virtualized comparison. Doing so confirmed our suspicion that the ranked order and relative performance across frameworks is mostly consistent between EC2 and physical hardware. That is, while the EC2 instances were slower than the physical hardware, they were slower by roughly the same proportion across the spectrum of frameworks.

"AmazonEC2에 대한 벤치마킹은 결과를 무효화하지 않습니까?"라고 말합니다.

우리의 의견은 실제 테스트 환경내에서 웹 어플리케이션의 성능을 정확하게 확인하는 것입니다.

또한 플랫폼으로 EC2를 선택하면 테스트에 관심이 있는 사람이 쉽게 확인할 수 있습니다. 

그러나 우분투를 실행하는 Core i7 (Sandy Bridge) 워크 스테이션에 대한 가상화되지 않은 비교 테스트도 수행했습니다. 

이렇게함으로써 순위 체계와 프레임 워크 간의 상대적인 성능은 EC2와 물리적 하드웨어간에 거의 일관적이라는 의심이 확인되었습니다. 

즉, EC2 인스턴스는 실제 하드웨어보다 느리지만 프레임 워크 전체에서 거의 같은 비율로 느려졌습니다.

21. "Tell me about your physical hardware." For the tests we refer to as "i7" tests, we're using our office workstations. These use Intel i7-2600K processors, making them a little antiquated, to be honest. These are connected via an unmanaged low-cost gigabit Ethernet switch. In previous rounds, we used a two-machine configuration where the load-generation and database role coexisted. Although these two roles were not crowding one another out (neither role was starved for CPU time), as of Round 7, we are using a three-machine configuration for the physical hardware tests. The machine roles are:

• Application server, which hosts the application code and web server, where applicable.
• Database server, which hosts the common databases. Starting with Round 5, we equipped the database server with a Samsung 840 Pro SSD.
• Load generator, which makes HTTP requests to the Application server via the Wrk load generation tool.

"실제 하드웨어에 대해 알려주십시오." 

우리가 "i7" 테스트를 참조합니다.

우리는 사무실 워크 스테이션을 사용하고 있습니다. 이들은 인텔 i7-2600K 프로세서를 사용하여 솔직히 말해서 약간 구식입니다. 이들은 관리되지 않는 저비용 기가비트 이더넷 스위치를 통해 연결됩니다. 이전 라운드에서는 로드 생성과 데이터베이스 역할이 공존하는 2 대의 시스템 구성을 사용했습니다. 이 두 가지 역할이 서로 섞이지는 않았지만 (라운드는 CPU 시간으로 인해 낭비되지 않았습니다), 라운드 7의 시점에서 실제 하드웨어 테스트를 위해 세 가지 시스템 구성을 사용하고 있습니다. 시스템 역할은 다음과 같습니다.

적용 가능한 경우 응용 프로그램 코드 및 웹 서버를 호스팅하는 응용 프로그램 서버.

공통 데이터베이스를 호스팅하는 데이터베이스 서버. 라운드 5부터 데이터베이스 서버에 삼성 840 Pro SSD를 장착했습니다.

로드 생성기 : Wrk로드 생성 도구를 통해 응용 프로그램 서버에 HTTP 요청을 수행합니다.

22. "What is Resin? Why aren't you using Tomcat for the Java frameworks?" Resin is a Java application server. The GPL version that we used for our tests is a relatively lightweight Servlet container. We tested on Tomcat as well but ultimately dropped Tomcat from our tests because Resin was slightly faster across all Servlet-based frameworks.

"Resin이란 무엇입니까? Java 프레임 워크에 Tomcat을 사용하지 않는 이유는 무엇입니까?" Resin은 Java 응용 프로그램 서버입니다. 우리가 테스트에 사용한 GPL 버전은 상대적으로 가벼운 서블릿 컨테이너입니다. 우리는 Tomcat에서도 테스트했지만, Resin은 모든 서블릿 기반 프레임 워크에서 약간 더 빠르기 때문에 궁극적으로 Tomcat을 테스트에서 제외했습니다.

23. "Do you run any warmups before collecting results data?" Yes. See "how is each test run" above. Every test is preceded by a warmup and brief (several seconds) cooldown prior to gathering test data.

"결과 데이터를 수집하기 전에 warmup을 실행하십니까?"예."각 테스트 실행 방법"을 참조하십시오. 테스트 데이터를 수집하기 전에 모든 테스트를 수행하기 전에 워밍업을 위한 짧은 시간(초)이 선행됩니다.

24. "I am about to start a new web application project; how should I interpret these results?" Most importantly, recognize that performance data should be one part of your decision-making process. High-performance web applications reduce hosting costs and improve user experience. Additionally, recognize that while we have aimed to select test types that represent workloads that are common for web applications, nothing beats conducting performance tests yourself for the specific workload of your application. In addition to performance, consider other requirements such as your language and platform preference; your invested knowledge in one or more of the frameworks we've tested; and the documentation and support provided by the framework's community. Combined with an examination of the source code, the results seen here should help you identify a platform and framework that is high-performance while still meeting your other requirements.

" 새로운 웹 애플리케이션 프로젝트를 시작하려고 합니다. 이 결과를 어떻게 해석해야 할까요?"

가장 중요한 것은 성능 데이터가 의사 결정 과정의 한 부분이 되어야 한다는 것입니다. 

.고성능 웹 애플리케이션은 호스팅 비용을 절감하고 사용자 환경을 개선합니다.

또한 웹 응용 프로그램에 공통적인 작업을 나타내는 테스트 유형을 선택하는 것이 목표이지만, 응용 프로그램의 특정 작업에 대해 

성능 테스트를 수행한 것이 뛰어난 것은 아닙니다. 

==> 그니까 동일한 작업을 한 것 중에서 좋은 걸 뽑은거지, 특정 작업을 했을 때 더 좋은지 테스트한 게 아니라는 말 같다.

성능뿐 아니라, 귀하의 언어 및 플랫폼 선호도와 같은 기타 요구 사항을 고려하고, 당사가 테스트한 프레임워크 중 하나 이상과 

프레임워크 커뮤니티에서 제공하는 문서 및 지원을 고려해야 합니다. 

 소스 코드와 함께 제공된 결과와 함께, 여기서 보는 결과는 다른 요구 사항을 충족하는 고성능 플랫폼과 프레임워크를 식별하는 데 도움이 됩니다.

25. "Why are the leaderboards for JSON Serialization and Plaintext so different on EC2 versus i7?" Put briefly, for fast frameworks on our i7 physical hardware, the limiting factor for the JSON test is our gigabit Ethernet; whereas on EC2, the limit is the CPU. Assuming proper response headers are provided, at approximately 200,000 non-pipelined and 550,000 pipelined responses per second and above, the network is saturated.

JSON 직렬화와 일반 텍스트의 리더 보드가 EC2와 i7에서 차이점은 무엇입니까?"

간단히 말해 i7 실제 하드웨어의 빠른 프레임 워크를 위해 JSON 테스트의 제한 요소는 기가비트 이더넷입니다.

 EC2에서는 한계가 CPU입니다. 

적절한 응답 헤더를 제공한다고 가정했을 때, 초당 약 20만개의 Non-파이프 라인과 55만개 이상의 파이프 라인이 있는 경우, 네트워크는 포화 상태이다.

26. "Where did earlier rounds go?" To better capture HTTP errors reported by Wrk, we have restructured the format of our results.json file. The test tool changed at Round 2 and some framework IDs were changed at Round 3. As a result, the results.json for Rounds 1 and 2 would have required manual editing and we opted to simply remove the previous rounds from this site. You can still see those rounds at our blog: Round 1, Round 2.

"이전 라운드는 어디로 갔습니까?" Wrk가보고 한 HTTP 오류를보다 잘 캡처하기 위해 results.json 파일의 형식을 재구성했습니다.

.라운드 2에서 테스트 도구가 변경되었으며 라운드 3에서 일부 프레임워크 ID가 변경되었습니다. 결과적으로 Rounds1과 2의 results.json은 수동 편집이 필요할 것이며, 이 사이트에서 이전 라운드를 간단히 제거하기로 결정했습니다. 우리 라운드에서 여전히 라운드를 볼 수 있습니다 : Round 1 , Round 2 .

27. "What does 'Did not complete' mean?" Starting with Round 9, we have added validation checks to confirm that implementations are behaving as we have specified in the requirements section of this site. An implementation that does not return the correct results, bypasses some of the requirements, or even formats the results in a manner inconsistent with the requirements will be marked as "Did not complete." We have solicited corrections from prior contributors and have attempted to address many of these, but it will take more time for all implementations to be correct. If you are a project participant and your contribution is marked as "Did not complete," please help us resolve this by contacting us at the GitHub repository. We may ultimately need a pull request from you, but we'd be happy to help you understand what specifically is triggering a validation error with your implementation.

"'Did not complete'는 무엇을 의미합니까?" 라운드 9부터는 이 사이트 의 요구 사항 섹션에서 지정한대로 구현이 작동하는지 확인하기 위해 유효성 검사를 추가했습니다 . 올바른 결과를 반환하지 않거나, 일부 요구 사항을 무시하거나, 요구 사항과 일치하지 않는 방식으로 결과를 형식화하는 구현은 "Did not complete"으로 표시됩니다

프로젝트 참여자가 "완료하지 않은" 상태로 표시된 경우에는 GitHub저장소에 연락하여 이 문제를 해결하는 것이 좋습니다..

궁극적으로 사용자로부터 요청을 받아야 할 수도 있습니다. 

그러나 구현시 유효성 검사 오류를 구체적으로 유발하는 요소를 이해할 수 있도록 도와 드리겠습니다.

28. "Why are Stripped test implementations hidden by default?" Since the introduction of Stripped test implementations, we have debated whether they should be included at all. A Stripped test implementation is one that is specially crafted to excel at our benchmark. By comparison, a "Realistic" test implementation should be demonstrative of the general-purpose, best-practices compliant, and production-class approach for the given framework. We have decided to hide Stripped tests by default because we feel that while their results have some value, that value is exceedingly low for the vast majority of consumers of the data. You may still view the results for Stripped tests by enabling the Stripped Implementation Approach in the filters control panel.

"왜 Stripped 테스트 구현이 기본적으로 숨겨져 있습니까?"

Strippedtest구현 이후에, 우리는 테스트 구현에 반드시 포함되어야 하는지에 대해 논의했습니다.

Stripped 테스트 구현은 벤치 마크에서 탁월한 성능을 발휘하도록 특별히 고안된 것입니다. 

상대적으로,"현실 주의적"시험 구현은 주어진 프레임워크에 대한 실용적이고 실용적인 접근법 및 생산 클래스 접근 방식을 입증해야 합니다.

 우리는 결과에 약간의 가치가 있어, 대부분의 데이터가 소비자들에게 매우 낮은 가치로 있다고 느끼기 때문에, 기본적으로 strippedtest를 숨기기로 결정했습니다. 

필터 제어판에서 StrippedImplementation접근법을 활성화하여 Stripped테스트 결과를 볼 수 있습니다.

29. "What exactly causes a test implementation to be classified as Stripped?" It's not possible to paint an exact picture, but conceptually, a Stripped implementation is characterized by being configured or engineered expressly to the requirements of our benchmark tests. By comparison, a Realistic implementation will use a production-grade configuration of a general-purpose web application framework that meets our requirements. When we first introduced the notion of Stripped, it referred to configurations of otherwise normal software that had been stripped of some normal behaviors. For example, removing some middleware from Rails or Django. However, we have broadened the definition of Stripped to also refer to bespoke software that has been crafted expressly to meet our test types' requirements.

테스트 구현이 정확히 Stripped로 분류되는 이유는 무엇입니까?" 

정확한 그림을 그릴 수는 없지만 개념적으로 Stripped 구현은 벤치 마크 테스트의 요구 사항에 맞게 구성됩니다

이에 비해 실제 구현에서는 우리의 요구 사항을 충족하는 범용 웹 응용 프로그램 프레임워크의 산업적 구성을 사용합니다.

우리가 Stripped라는 개념을 처음 도입했을 때, 그것은 정상적인 행동을 벗어난 정상적인 소프트웨어의 구성을 언급했습니다.

예를 들어 Rails 또는 Django에서 일부 미들웨어를 제거합니다.

그러나 우리는 Stripped 또한 테스트 유형 요구 사항을 충족시키기 위해 특별히 제작된 맞춤형 소프트웨어를 의미합니다

오역 지적 환영합니다.