TechEmpower Benchmarks Document 한글 번역

TechEmpower Framework Benchmarks Document

Server Roles

When running the benchmark suite, we use three server roles. These roles can be fulfilled by three distinct computers (physical hardware), three virtual machines, by a single computer acting in all three roles simultaneously, or any other blend.

The full benchmark requires at least three server roles:

• app server: The server that hosts each framework during a run, inclusive of web servers where applicable.
• load server: The server that generates client load during a run. Also known as the client or client machine.
• database server: The server that runs the databases used during a run. Also known as the DB server.

서버 역할

벤치 마크가 제품군을 실행할 때는 세 가지 서버 역할을 사용합니다. 이 역할은 세 가지 별개의 컴퓨터(물리적 하드웨어),  세 가상 컴퓨터, 세 가지 역할을 동시에 수행하는 단일 컴퓨터 또는 다른 혼합을 통해 수행할 수 있습니다.

전체 벤치 마크에는 적어도 세 가지 서버 역할이 필요합니다.

앱 서버 : 실행 중에 각 프레임 워크를 호스팅하는 서버 (적용 가능한 경우 웹 서버 포함)

로드 서버 : 실행 중에 클라이언트로드를 생성하는 서버. client또는 client machine으로도 알려져 있습니다.

데이터베이스 서버 : 실행 중인 데이터베이스를 실행하는 서버. 또한 DB서버라고도 합니다.

This codebase (TechEmpower/FrameworkBenchmarks aka TFB) must be run on the app server. The codebase contains a number of framework directories, each of which contains one or more framework test implementations. While our current setup has many directories, we are working to consolidate related code into fewer directories with more tests per directory.

이 코드 베이스(TecheMowwer/FrameworkBers라고도 함)는 App서버에서 실행되어야 합니다. 코드 베이스에는 하나 이상의 프레임워크 디렉터리가 포함되어 있으며, 각 프레임워크는 하나 이상의 프레임워크 테스트 구현을 포함하고 있습니다

현재 설정된 디렉토리에는 디렉터리가 많지만 디렉터리 별로 더 많은 테스트를 통해 관련 코드를 더 적은 디렉터리로 통합할 수 있습니다.

When run, TFB will:

• Select which framework tests are to be run based on command-line arguments you provide
• Install the necessary software (both on the app server and other servers)
• Launch the framework(s) you've requested, each in turn
• Launch the necessary database servers
• Access the URIs listed in the requirements and verify the responses
• Launch the load generation software on the load server
• Gather the results
• Halt the framework, and repeat for the next framework as specified by command-line arguments

실행 시 TFB는 다음을 수행한다.

제공하는 명령줄 인수에 따라 실행할 프레임워크 테스트를 선택합니다.

필요한 소프트웨어(애플리케이션 서버 및 기타 서버 모두)설치

요청한 프레임워크를 모두 실행합니다.

필요한 데이터베이스 서버 실행

요구 사항에 나열된 URI에 액세스하고 응답을 확인합니다.

로드 서버에서 로드 생성 소프트웨어 시작

결과를 수집합니다.

프레임워크를 중지하고 명령줄 인수에서 지정한 다음 프레임워크에 대해 반복합니다.

TechEmpower Framework Benchmarks Document

Test Types

Each test type has their own requirements and specifications. Visit their sections for more details and complete requirements.

1. JSON Serialization: Exercises the framework fundamentals including keep-alive support, request routing, request header parsing, object instantiation, JSON serialization, response header generation, and request count throughput.
2. Single Database Query: Exercises the framework's object-relational mapper (ORM), random number generator, database driver, and database connection pool.
3. Multiple Database Queries: A variation of Test #2 and also uses the World table. Multiple rows are fetched to more dramatically punish the database driver and connection pool. At the highest queries-per-request tested (20), this test demonstrates all frameworks' convergence toward zero requests-per-second as database activity increases.
4. Fortunes: Exercises the ORM, database connectivity, dynamic-size collections, sorting, server-side templates, XSS countermeasures, and character encoding.
5. Database Updates: A variation of Test #3 that exercises the ORM's persistence of objects and the database driver's performance at running UPDATE statements or similar. The spirit of this test is to exercise a variable number of read-then-write style database operations.
6. Plaintext: An exercise of the request-routing fundamentals only, designed to demonstrate the capacity of high-performance platforms in particular. Requests will be sent using HTTP pipelining. The response payload is still small, meaning good performance is still necessary in order to saturate the gigabit Ethernet of the test environment.
7. Caching: Exercises the platform or framework's in-memory caching of information sourced from a database. For implementation simplicity, the requirements are very similar to the multiple database query test (Test #3), but use a separate database table and are fairly generous/forgiving, allowing for each platform or framework's best practices to be applied.

JSON 직렬화 : Keep-Alive 지원, 요청 라우팅, 요청 헤더 구문 분석, 객체 인스턴스화, JSON 직렬화, 응답 헤더 생성 및 요청 카운트 처리량을 포함한 기본 프레임 워크를 실습합니다.

단일 데이터베이스 쿼리 : 프레임 워크의 ORM (Object-Relational Mapper), 난수 생성기, 데이터베이스 드라이버 및 데이터베이스 연결 풀을 연습합니다.

다중 데이터베이스 쿼리 : 테스트 # 2 의 변형이며 World 테이블을사용합니다. 데이터베이스 드라이버와 연결 풀을 더 극적으로 처벌하기 위해 여러 행을 가져옵니다. 테스트 된 가장 높은 요청 당 쿼리 (20 개)에서이 테스트는 데이터베이스 작업이 증가함에 따라 모든 프레임 워크가 초당 0 요청 수렴으로 진행됨을 보여줍니다.

Fortunes : ORM, 데이터베이스 연결, 동적 크기 컬렉션, 정렬, 서버 측 템플릿, XSS 대책 및 문자 인코딩을 연습합니다.

데이터베이스 업데이트 :ORM의 객체 지속성 및 실행중인명령문 등에서데이터베이스 드라이버의 성능을 테스트하는 테스트 # 3 의 변형입니다UPDATE. 이 테스트의 정신은 다양한 수의 읽기 - 쓰 기 스타일 데이터베이스 작업을 수행하는 것입니다.

일반 텍스트 : 특히 고성능 플랫폼의 용량을 보여주기 위해 설계된 요청 라우팅 기본 사항 만 연습합니다. 요청은 HTTP 파이프 라이닝을 사용하여 전송됩니다. 응답 페이로드는 여전히 작기 때문에 테스트 환경의 기가비트 이더넷을 포화 시키려면 좋은 성능이 필요합니다.

캐싱 (Caching) : 데이터베이스에서 제공되는 정보의 플랫폼 또는 프레임 워크 내부 메모리 캐싱을 연습합니다. 구현의 단순성을 위해 요구 사항은 여러 데이터베이스 쿼리 테스트 ( 테스트 # 3 )와 매우 유사하지만 별도의 데이터베이스 테이블을 사용하고 상당히 관대하고 관대하므로 각 플랫폼 또는 프레임 워크의 모범 사례를 적용 할 수 있습니다.

General Test Requirements

The following requirements apply to all test types below.

1. All test implementations should be production-grade. The particulars of this will vary by framework and platform, but the general sentiment is that the code and configuration should be suitable for a production deployment. The word should is used here because production-grade is our goal, but we don't want this to be a roadblock. If you're submitting a new test and uncertain whether your code is production-grade, submit it anyway and then solicit input from other subject-matter experts.
2. All test implementations must disable all disk logging. For many reasons, we expect all tests will run without writing logs to disk. Most importantly, the volume of requests is sufficiently high to fill up disks even with only a single line written to disk per request. Please disable all forms of disk logging. We recommend but do not require disabling console logging as well.
3. Specific characters and character case matter. Assume the client consuming your service's JSON responses will be using a case-sensitive language such as JavaScript. In other words, if a test specifies that a map's key is id, use id. Do not use Id or ID. This strictness is required not only because it's sensible but also because our automated validation checks are picky.

1. 모든 테스트 구현은 산업용이어야 합니다. 자세한 내용은 프레임워크와 플랫폼에 따라 달라지겠지만, 일반적인 정서는 코드와 구성이 프로덕션 배포에 적합해야 한다는 것입니다. 산업용이라는 단어는 우리의 목표이기 때문에 여기서 사용되어야 한다. 그러나 우리는 이것이 방해가 되는 것을 원치 않는다. 만약 당신이 새로운 시험을 제출하고 코드가 있는지 확실치 않다면, 어쨌든 그것을 제출하고 다른 분야의 전문가들로부터 조언을 구하세요.

2. 모든 테스트 구현에서는 모든 디스크 로깅을 비활성화해야합니다 . 여러 가지 이유로 우리는 모든 테스트가 로그를 디스크에 쓰지 않고 실행될 것으로 기대합니다. 가장 중요한 것은 요청 당 디스크 한 개만 써도 디스크를 채우기에 충분한 양의 요청입니다. 모든 형태의 디스크 로깅을 비활성화하십시오. 콘솔 로깅을 비활성화 할 것을 권장하지만 필요하지는 않습니다.

3. 특정 문자 및 대소 문자가 중요합니다. 서비스의 JSON 응답을 사용하는 클라이언트가 JavaScript와 같은 대소 문자를 구별하는 언어를 사용한다고 가정합니다. 즉, 테스트에서 맵의 키가 id임을 지정하면 id를 사용하십시오. id 또는 ID를 사용하지 마십시오. 이러한 엄격함은 합리적이기 때문에 필요할뿐만 아니라 자동화 된 유효성 검사가 까다롭기 때문에 필요합니다.