[Nginx] 엔진엑스 기본 환경 설정

일반적으로 환경 설정 파일은 관리자가 편집하거나 프로그램으로 분석할 수 있는 텍스트 파일로, 여러 가지 값을 지정해 프로그램의 작동 방법을 결정합니다. 리눅스 기반 운영체제에서는 애플리케이션의 상당 부분이 크고 복잡한 환경 설정 파일에 의존해 수행됩니다.

엔진엑스의 장점 중 하나는 환경 설정이 비교적 간단하다는 점입니다. 습득해야할 원리도 지시어, 블록, 전체 논리 구조 등 몇 개 되지 않습니다. 실제의 환경 설정 과정은 대부분 지시어 값을 정하는 일로 이뤄집니다.

지시어 설정

---

엔진엑스 환경 설정 파일은 논리적으로 돼 있는 지시어 목록이라 할 수 있습니다. 애플리케이션 전체가 지시어에 부여하는 값에 의해 작동합니다. 기본적인 경로는 /usr/local/nginx/conf/nginx.conf 입니다.

#user nobody;

worker_processes 1;

첫번째 줄은 주석이고, 둘째 줄은 실질적인 문장으로, 지시어에 해당합니다. 첫 비트(worker_process)는 설정키를 나타내며 그 뒤에 한 개이 상의 값을 붙일 수 있습니다. 엔진엑스가 단일 작업자 프로세스로만 작동됨을 의미합니다.

엔진엑스는 모듈 구조로 작동하기 때문에 각 모듈은 특정 지시어의 묶음 형태로 제공됩니다. 가장 기본적인 지시어들은 엔진엑스 코어 모듈(Core module)에 포함돼 있습니다.

구조와 인클루드

include mime.types;

이름이 의미하는 것처럼 include 지시어는 특정 파일을 포함하는 기능을 수행합니다. 지시어가 있는 바로 그 위치에 해당 파일 내용이 삽입됩니다. 

nginx.conf:

user nginx nginx;

worker_processes 4;

include other_settings.conf;

other_settings.conf:

error_log logs/error.log;

pid logs/nginx.pid;

인클루드는 순환적으로 처리됩니다. 이 말은 앞의 경우에 other_settings.conf 파일 안에서 또 다른 파일을 인클루드할 수 있음을 의미합니다.

초기 환경 설정에서는 두 개의 파일, 즉 nginx.conf와 mime.types를 사용했습니다. 하지만 좀 더 발전된 환경 설정에서는 그 이상의 파일을 사용합니다.

표준 이름	설명
nginx.conf	애플리케이션의 기본 환경 설정
mime.types	파일 확장명과 MIME 타입 목록
fastcgi.conf	FastCGI 관련 환경 설정
proxy.conf	프록시 관련 환경 설정
sites.conf	엔진엑스에 의해 서비스되는 가상 호스트 웹사이트의 환경 설정. 도메인마다 파일을 분리해서 만들 것을 권장.

include 지시어는 파일명 글로빙(filename globbing)을 지원합니다. 즉, 파일명에 와일드카드 문자인 별표(*)를 사용할 수 있습니다.

지시어 블록

지시어는 모듈에 의해 도입되므로 새 모듈을 활성화하면 그 모듈에 포함된 지시어들을 사용할 수 있습니다. 또한 모듈은 환경 설정을 논리적 구조로 만들 수 있게 지시어 블록(directive block) 기능을 제공합니다.

events {

worker_connections 1024;

}

기본 환경 설정 파일에서 볼 수 있는 events 블록은 이벤트 모듈에 의해 도입됩니다. 모듈이 제공하는 지시어들은 블록 안에서만 사용할 수 있습니다. worker_connections는 events 블록의 문맥에서만 의미를 갖습니다. 하지만 한 가지 중요한 예외로, 일부 지시어들은 서버의 전 범위에 효력을 갖기 때문에 메인 블록이라 부르는 환경 설정 파일의 루트에 놓일 수 있습니다.

경우에 따라서는 한 블록 안에 또 다른 블록이 삽입될 수 있음에 유의합니다.

http {

server {

listen 80;

server_name example.com;

access_log /var/log/nginx/example.com.log;

location ^~ /admin/ {

index index.php;

}

}

}

http 블록 안에는 한 개 이상의 서버 블록을 선언할 수 있습니다. 하나의 server 블록은 하나의 가상 호스트를 구성합니다. 위의 예에서 server 블록은 example.com과 일치하는 Host HTTP 헤더를 갖는 모든 요청에 적용될 환경 설정을 포함합니다.

server 블록 안에 한 개이상의 location 블록을 삽입할 수 있습니다. 로케이션 블록은 요청 URI가 지정 경로와 일치할 경우에만 설정을 적용합니다.

환경 설정은 자식 블록(children block)에 상속됩니다. 위의 예에서 server 블록 레벨에 정의된 access_log 지시어는 서버가 수신하는 모든 HTTP 요청을 텍스트 파일에 기록하게 하는데, 다시 access_log 지시어를 사용해 로그를 중지시키지 않는 한 자식 블록인 location 블록 안에서도 여전히 유효합니다.

[...]

location ^~ /admin/ {

index index.php;

access_log off;

}

[...]

이 경우에 로그는 /admin/ 위치 경로를 제외한 웹사이트의 모든 곳에 적용됩니다. server 블록 레벨에서 적용한 access_log 지시어의 설정 값은 location 블록 레벨에서 설정한 값에 의해 변경됩니다.

지시어 값에서 사용되는 약자

지시어 값에서 파일 크기를 지정할 때 다음과 같은 약자를 사용할 수 있습니다.

- k 또는 K 킬로바이트

- m 또는 M 메가바이트

따라서 다음 두 구문은 모두 올바르게 사용된 것이며, 같은 의미를 갖습니다.

client_max_body_size 2M;

client_max_body_size 2048k;

또한 시간 값을 지정할 때는 다음과 같은 단축 문자를 사용할 수 있습니다.

- ms    밀리초

- s    초

- m    분

- h    시

- d    일

- w    주

- M    월(30일)

- y    연(365일)

이런 약자들은 시간 값을 사용하는 지시어에서 특히 유용합니다. 기본 시간단위는 초입니다.

client_body_timeout 3m;

client_body_timeout 180s;

client_body_timeout 180;

변수

모듈은 지시어 값을 정의할 때 활용할 수 있는 변수도 제공합니다. 예를 들어 엔진엑스 HTTP 코어 모듈에서는 $nginx_version 변수를 정의합니다. log_format 지시어를 설정할때 포맷 문자열 안에 모든 종류의 변수를 포함할 수 있습니다.

[...]

location ^~ /admin/ {

access_log logs/main.log;

log_format main '$pid - $nginx_version - $remote_addr';

}

[...]

일부 지시어는 변수 사용을 허용하지 않습니다.

문자열 값

지시어 값으로 사용되는 문자열은 세가지 형태로 나타나는데, 우선 따옴표를 사용하지 않고 문자열을 나타낼 수 있습니다.

root    /home/example.com/www;

하지만, 공백 문자(""), 세미콜론(;), 중괄호({}) 같은 특수 문자를 사용하려면 작은 따옴표나 큰따옴표 안에 지시어 값을 넣어야 합니다.

root    '/home/example.com/my web pages';

엔진엑스는 작은따옴표와 큰따옴표를 구분하지 않습니다.

기본 모듈 지시어

---

기본 모듈은 엔진엑스 기본 기능의 매개변수를 정의하는 지시어를 제공합니다. 기본 모듈은 컴파일할 때 제외시킬 수 없기 때문에 기본 모듈이 제공하는 지시어와 블록은 항상 사용이 가능합니다.

 - 코어 모듈(Core module) 프로세스 관리나 보안과 같은 필수적인 기능과 지시어

 - 이벤트 모듈(Events module) 네트워크 기능의 내부 작동 방식을 구성

 - 환경 설정 모듈(Configuration module) 인클루드 체계를 사용할 수 있게 한다.

엔진엑스 프로세스 구조

엔진엑스의 실행이 막 시작된 순간에는 마스터 프로세스(Master Process)라 부르는 특별한 프로세스 한 개만 존재합니다. 마스터 프로세스 자신은 어떤 클라이언트 요청도 처리하지 않으며 단지 그 일을 대신 수행할 작업자 프로세스를 낳아서 증식(invoke)하는데, 이때 작업자 프로세스의 사용자/그룹은 바뀝니다. 환경 설정에서 작업자 프로세스의 수, 작업자 프로세스당 최대 접속 수 등을 정할 수 있습니다.

코어 모듈 지시어

코어 모듈 지시어 대부분은 환경 설정 파일의 루트에 넣어야 하며 오직 한번만 사용할 수 있습니다. 하지만 일부는 여러 가지 문맥으로 유효하게 사용할 수 있는데, 그런 경우에는 환경 설정 파일의 루트에 지시어명과 함께 유효 문맥의 목록이 나타나며 이때도 마찬가지로 한번만 사용할 수 있습니다.

1. error_log (문맥: main, http, server, location)

error_log /file/path level;

가장 상세한 로그 레벨부터 차례로 debug, info, notice, warn, error, crit가 됩니다. 애플리케이션, HTTP 서버, 가상 호스트, 가상 호스트 디렉토리 각각에 대해 다른 레벨로 에러 로그를 설정할 수 있다.

로그 출력 방향을 /dev/null로 전환하면 에러 로그를 해제하는 것과 같은 효과를 얻을 수 있습니다. 환경 설정 파일의 루트 부분에 다음의 지시어를 사용합니다.

error_log /dev/null crit;

2. master_process 

master_process on;

on으로 설정하면 엔진엑스는 다수의 프로세스, 즉 하나의 메인 프로세스(마스터 프로세스)와 여러 개의 작업자 프로세스를 시작할 수 있습니다. off로 해제시키면 엔진엑스는 단일 프로세스만으로 작동합니다. 

3. thread_stack_size

thread_stack_size 1m;

스레드 스택의 크기를 정의합니다.

4. timer_resolution

timer_resolution 100ms;

내부 클록을 동기화하기 위해 gettimeofday() 시스템 호출 사이의 간격을 제어합니다. 이 값을 지정하지 않으면 커널 이벤트 알림이 있을 때마다 클록이 동기화됩니다.

5. worker_threads

worker_threads 8;

작업자 프로세스당 스레드 수를 정의합니다. 스레드는 기본적으로 사용이 해제돼 있습니다. 이고르 쉐프에 의하면 엔진엑스는 경량 프로세스로 구현됐으며, 아직은 멀티스레드를 완전히 지원하지 않는 것으로 알려져 있습니다.

6. worker_cpu_affinity

worker_cpu_affinitty 1000 0100 0010 0001;

worker_cpu_affinitty 10 10 01 01;

worekr_cpu_affinitty;

이 지시어는 worker_processes와 결합해 작동하며 CPU 코어와 작업자 프로세스의 관계에 영향을 줍니다. 작업자 프로세스 수만큼 숫자가 나열되며, 각 숫자의 자리 수는 CPU 코어 수와 같습니다.

CPU 친화성(affinity)은 멀티코어 CPU를 위해 권장하는 것일 뿐 하이퍼 스레딩(Hyper-Threading)(하나의 CPU가 2개 이상의 논리적 CPU처럼 작동하게 하는 기술로서 CPU 제조사 인텔의 용어다. 약칭 HT HTT라고도 하며 이는 자사의 CPU 제품에 구현된 동시 멀티스레딩 기술을 지칭한다)과 같은 기술을 사용하는 CPU를 대상으로 하는 것은 아닙니다.

7. worker_priority

worker_priority 0;

-20(가장 높음)부터 19(가장 낮음)까지의 숫자로 작업자 프로세스의 우선 순위를 정의합니다. 기본 값은 0입니다. 커널 프로세스는 우선순위 -5 수준에서 실행되므로 우선순위를 -5 이하로 설정하는 것은 권장하지 않습니다.

8. worker_processes (기본값: 1)

worker_processes 4;

작업자 프로세스 수를 정의합니다. 엔진엑스는 클라이언트 요청을 여러 개의 프로세스로 나눠 처리합니다. 기본 값은 1이지만 CPU가 2개 이상의 코어를 갖는다면 이 값을 증가시키도록 권장합니다.

또한 I/O 동작이 느려 프로세스가 멈춰 기다리는 상태가 되면 이때 들어오는 요청은 다른 작업자 프로세스에 위임될 수 있습니다.

9. worker_rlimit_core

worker_rlimit_core 100m;

작업자 프로세스당 코어 파일의 크기를 정의합니다.

10. worker_rlimit_nofile

worker_rlimit_nofile 10000;

작업자 프로세스가 동시에 사용할 수 있는 파일 수를 정의합니다.

11. worker_rlimit_sigpending

worker_rlimit_sigpending 10000;

사용자(호출 프로세스의 사용자 ID)당 대기할 수 있는 시그널 수를 정의합니다. 대기열(queue)이 꽉 차면 이 한계치를 넘은 시그널은 무시됩니다.

이벤트 모듈

이벤트 모듈은 네트워크 작동 환경을 설정하는 지시어를 제공합니다. 일부 매개변수는 애플리케이션 성능에 중요한 영향을 미칩니다.

다음 목록에 나타나는 모든 지시어는 반드시 환경 설정 파일의 맨 앞에 있는 events 블록 안에서만 사용해야 합니다. 이 지시어들은 어떤 다른 장소에서도 나타날 수 없습니다.

user nginx nginx;

master_process on;

worker_processes 4;

events {

worker_connections 1024;

use poll;

}

[...]

1. accept_mutex

accept_mutex on;

LISTEN 소켓을 오픈하기 위한 accept 뮤텍스의 사용/해제를 설정합니다.

2. accept_mutex_delay

accept_mutext_delay 500ms;

자원의 획득을 다시 시도하기 전에 작업자 프로세스가 기다려야 하는 시간의 양을 정의합니다. accept_mutex 지시어가 off로 설정돼 있으면 이 값은 사용되지 않습니다.

3. worker_connections

worker_connections 1024;

작업자 프로세스가 동시에 처리할 수 있는 접속 수를 정의합니다.

프로파일에 맞춘 환경 설정

엔진엑스가 다른 웹서버와 차별화되는 이유가 있습니다. 매우 초경량이며 최적화된 서버, 즉 매우 빠른 서버이기 때문입니다. 따라서 기본 환경 설정도 상당히 효율적이기 때문에 초기 설정할 때 큰 변화를 줄 필요가 없는 경우가 많습니다. 

주 환경 설정 파일인 nginx.conf의 내용은 거의 비어 있는 상태지만 이 파일을 열어 기본 환경 설정을 공부해봅시다. 그렇게 하는 이유는 어떤 지시어가 환경 설정 파일에 없을 때는 기본 값이 채택되기 때문입니다. 그러므로 환경 설정 원본에 나타나는 지시어뿐만 아니라 기본 값도 함께 고려하는 것이 필요합니다.

user root root;

worker_processes 1;

worker_priority 0;

error_log logs/error.log error;

log_not_found on;

event {

accept_mutex on;

accept_mutex_delay 500mx;

multi_accept off;

worker_connections 1024;

}

필요한 조정

즉각적인 변경이 필요한 일부 환경 설정 지시어와 설정 값을 살펴보겠습니다.

1. user root root;

이 지시어는 작업자 프로세스가 루트로 실행되게 합니다. 작업자 프로세스가 파일 시스템의 모든 사용권한을 얻게 되므로 보안상 위험합니다.

2. worker_processes 1;

이 설정은 단 하나의 작업자 프로세스만 생성합니다. 그것은 곧 모든 요청을 단 하나의 실행 흐름으로 처리하겠다는 것을 의미하며, 한편으로는 오직 하나의 CPU 코어에게만 실행을 위임한다는 의미도 있습니다. CPU 코어 하나에 최소한 한 개의 프로세스가 배정되게 이 값을 증가시킬 것을 강력히 권장합니다. 권장 값은 worekr_processes 4; (서버에 4코어 CPU가 장착돼 있는 경우)입니다.

3. worker_priority 0;

기본적으로 작업자 프로세스는 보통 수준의 우선순위로 실행됩니다. 시스템이 동시에 다른 작업을 수행 중이라면 엔진엑스 작업자 프로세스에 더 높은 우선순위를 부여하길 바랄 수 있습니다. 이런 경우에는 우선순위 값을 감소시킵니다. 값이 작을수록 더 높은 우선순위를 갖습니다. 가장 높은 우선순위 값인 -20부터 가장 낮은 우선순위 값인 19까지 값을 정할 수 있습니다. 얼마의 우선순위 값이 적당한지는 전적으로 서버 상황에 달려있기 때문에 권장 값을 정할 수는 없습니다. 하지만 커널 프로세스의 기본 우선순위인 -5 아래로는 설정하지 않도록 합니다.

4. log_not_found on;

이 지시어는 엔진엑스가 404 에러를 로그 파일에 기록할지 여부를 정합니다. 물론 이런 에러는 누락된 자원에 대한 정보를 제공하는 이점은 있지만, 대부분 웹브라우저가 파비ㅏ콘에 접근하려고 하거나 로봇이 인덱싱 명령에 접근을 시도하기 때문에 발생하는 경우가 많습니다. 로그 파일을 지저분하게 만드는 관습적인 파일에 대해서는 log_not_found를 해제하길 권장합니다. 하지만 서버 레벨에서 해제하지 않도록 합니다.

5. worker_connections 1024;

이 설정은 작업자 프로세스 수와 결합돼 서버가 동시에 수용할 수 있는 전체 접속 수를 결정합니다. 네 개의 작업자 프로세스를 사용 중이라면 각 프로세스가 1,024개의 접속을 수용하므로 서버는 총 4,096개의 동시 접속을 처리합니다. 이 설정은 하드웨어 구조와 성능에 맞게 조정할 필요가 있습니다. RAM이 더 많고 CPU 성능이 더 좋을수록 더 많은 동시 접속을 수용할 수 있습니다.

하드웨어 맞춤 설정

1. 적당한 하드웨어로 구성된 보통 웹사이트용의 표준 설정(standard)

2. 하드웨어가 그다지 좋지 않아 성능을 최적화해야 하는 통신량이 적은 웹사이트용의 로우트래픽 설정(low traffic)

3. 상용 서비스 같이 통신량이 많은 웹사이트에 적합한 하이트래픽 설정(high traffic)

CPU는 더 빨라지고, RAM은 더 싸지고, SSD 같은 새로운 기술이 등장합니다. 따라서 각자의 상황과 시기에 맞춰 조정할 필요가 있습니다. 지시어의 권장값은 CPU 코어당 한 개의 작업자 프로세스, RAM 크기에 맞는 최대 접속자 수 등과 같은 사양으로부터 직접 산출된 것입니다.

1. 로우 트래픽 설정

CPU: 듀얼코어, RAM: 2GB, 요청수: ~1/s

worker_processes 2;

worker_rlimit_nofile 1024;

worker_priority -5;

worker_cpu_affinity 01 10;

events {

multi_accept on;

worker_connections 128;

}

2. 표준 설정

CPU: 쿼드코어, RAM: 4GB, 요청수: ~50/s

worker_processes 4;

worker_rlimit_nofile 8192;

worker_priority 0;

worker_cpu_affinity 0001 0010 0100 1000;

events {

multi_accept off;

worker_connections 1024;

}

3. 하이 트래픽 설정

CPU: 8코어, RAM: 12GB, 요청수: ~1000/s

worker_processes 8;

worker_priority 0;

events {

multi_accept off;

worker_connections 8192;

}

성능에 결정적인 영향을 미치는 두 개의 조정 값으로 작업자 프로세스 수와 접속 한도가 있습니다. 작업자 프로세스 수를 부적절하게 설정하면 특정 CPU 코어만 집중적으로 사용되고 다른 코어는 사용되지 않거나 적게 사용되는 현상이 일어날 수 있습니다. 또한 RAM에 오버플로우가 일어나 시스템 충돌이 발생할 수도 있습니다. 불행히도 worker_connections 지시어 값을 계산하는 간단한 공식은 없기 때문에 예상되는 통신량 추정치에 기초해 산정할 수 밖에 없습니다.

서버 테스트

---

서버의 기본 환경 설정이 모두 구축됐습니다. 만든 설정이 정확한지 또는 상용 서비스에 적합한지 확인하는 작업을 먼저해야 합니다.

성능 테스트

엔진엑스의 기본 기능과 환경 설정을 구성하고 나면 계속해서 여러 가지 테스트를 시도하고 싶을 것입니다. 테스트를 실행하고, 환경설정을 수정하고, 서버를 재로드한 후 다시 테스트를 실생하고, 다시 환경 설정을 수정하는 방식으로 테스트를 수행하면 됩니다. 완벽하게 하자면 엔진엑스가 실행되는 컴퓨터에서 테스트 도구를 동시에 실행하는 피해야 합니다. 테스트 결과를 왜곡시키는 원인이 될 수 있기 때문입니다. 

httperf 비교적 널리 알려진 리눅스 운영체제 전용의 오픈소스 유틸리티로서 HP사가 개발

Autobench 테스트 체계를 개선해 상세한 보고서를 만들어주는 httperf용 Perl wrapper(Shell Wrapper는 셸 스크립트를 사용해 시스템 명령어나 유틸리티들을 매개변수와 함께 작성해 놓은 실행파일이다. Perl wrapper는 perl script를 사용한다는 점에서만 다르다)

OpenWebLoad 작은 규모의 오픈소스 부하 시험 애플리케이션입니다. 윈도우와 리눅스 플랫폼을 모두 지원한다.

이런 도구들은 방대한 양의 HTTP 요청을 발생시켜 서버에 부하를 걸고 그 결과를 수집해 분석하는 원리를 이용합니다.

Httperf

일단 설치되고 나면 다음 명령을 실행할 수 있습니다.

$ httperf --server 192.168.1.10 --port 80 --uri /index.html --rate 300 --num-conn 30000 --num-call 1 --timeout 5

--server : 테스트할 웹사이트의 호스트명

--uri: 다운로드할 파일의 경로

--rate: 초당 보낼 요청 수

--num-conn: 총 접속 수

--num-call: 접속당 보낼 요청 수

--timeout: 요청이 분실된 것으로 간주하는 한도 경과 시간

테스트 결과는 응답 시간과 성공한 요청 수를 보여줍니다. 성공률이 100%나 0ms에 가까운 응답 시간이 나온다면 요청 빈도를 증가시켜 서버가 약해지는 징조를 보일때까지 테스트를 반복합니다.

오토벤치

Autobench는 httperf를 더욱 효율적으로 활용하는 Perl Script로, 테스트를 연속적으로 수행하면서 서버가 포화될 때까지 자동으로 요청 빈도를 증가시킵니다. 오토벤치의 재미있는 특징 중 하나는 여러가지 그래프 생성 애플리케이션을 통해 열어볼 수 있는 .tsv 보고서를 생성하는 것입니다. 

오토벤치는 여러 호스트를 한번에 테스팅할 수 있음에도 최대한 단순화시키기 위해 단일 호스트 테스트만을 사용하겠습니다. 실행할 명령은 httperf와 똑같습니다.

$ autobench --single_hot --host1 192.168.1.10 --uri1 /index.html --quite --low_rate 20 --high_rate 200 --rate_step 20 --num_call 10 --num_conn 5000 --timeout 5 --file results.tsv

--host1: 테스트할 웹사이트의 호스트명

--uri1: 다운로드할 파일의 경로

--quiet: httperf 정보를 화면에 표시하지 않는다.

--low_rate: 테스트가 시작될 때의 초당 접속 수

--high_rate: 테스트가 끝날 때의 초당 접속 수

--rate_step: 각 테스트 후에 증가되는 접속 수 비율

--num_call: 접속당 보낼 요청 수

--num_conn: 총 접속 수

--timeout: 요청이 분실된 것으로 간주할 한도 경과 시간

--file: 테스트 결과를 출력할 파일명(.tsv 파일)

오픈웹로드

오픈웹로드는 다른 접근법을 사용하는데, 서버에 요청 부하를 걸어 그 중 몇개가 정확하게 처리되는지를 보는 게 아니라 접속 수를 변화시키면서 가능한 한 많은 요청을 서버로 보내며 매초 보고합니다.

$ openload example.com/index.html 10

첫 번째 인자는 테스트하려는 웹사이트의 URL입니다. 두번째 인자는 오픈할 접속 수입니다.

초마다 새로운 결과를 보여주는 줄이 나타납니다. Enter키를 누를 때까지 계속해서 요청을 보내며, Enter 키를 누르고 나면 결과 요약이 표시됩니다.

- Tps(초당 트랜잭션 수): 한 트랜잭션은 하나의 완성된 요청(요청과 응답)에 해당

- MaTps: 마지막 20초 동안의 평균 Tps

- Resp Time: 경과된 시간 동안의 평균 응답시간

- Err(에러율): 에러는 서버가 HTTP 200 OK가 아닌 다른 응답을 리턴할 때 발생한다.

- Count: 총 트랜잭션 수

접속 수가 너무 적으면 TPS 비율은 낮아지만 응답 시간은 최적입니다. 접속 수가 너무 많으면 상대적으로 높은 TPS를 얻을 수 있지만 응답 시간은 극단적으로 길어집니다. 따라서 가장 만족스런 중간 값을 찾아낼 필요가 있습니다.