Helio ping_iouring_server


소개

이 서버는 레디스 명령을 받아 분석(parsing)합니다.
'PING'을 받으면 'PONG'을 리턴하고, 기타 명령은 'OK'를 리턴합니다.
(실제 레디스 명령을 실행하는 것은 아닙니다.)
여러 개 스레드를 사용할 수 있고, io_uring, fiber를 사용합니다.

목차


성능 테스트

📦 성능 테스트 환경

ping_iouring_server를 스레드 1개, 2개, 5개, 10개로 테스트했습니다.
성능 테스트 툴은 redis-benchmark를 사용합니다. benchmark를 1개 실행하기도 하고, 2개, 3개, 4개, 5개를 동시에 실행해서 테스트했습니다.

  • 테스트 장비(H/W): LG노트북 gram Intel i5-1335U(13th) 2.50GHz
    코어:10, 논리 프로세서:12, L1 캐시: 928KB, L2: 6.5MB, L3: 12.0MB
  • 호스트 OS: Windows 11, VM: CentOS 9 (10코어 설정)
  • 컴파일 build-dbg$ ninja -j1 ping_iouring_server
  • 서버 실행: build-dbg$ ping_iouring_server --proactor_threads=1
    스레드 개수를 1, 2, 5, 10로 테스트했다.
  • 테스트 툴 실행: redis-benchmark를 하나 또는 여러 개 동시 실행해서 테스트했습니다.
    $ bin/redis-benchmark -p 6380 -t set -d 10 -n 1000000 -q
  • 측정 단위: 초당 명령 실행 수 rps(requests per second).
  • p50 설명: 50%를 처리하는데 1개당 처리 시간입니다. p50=1.695msec이면 100만개의 요청 중에 50만개를 처리하는데 1개당 1.694msec 이내로 처리했다는 것입니다.

📦 요약

Server Thread=10, benchmark 10개(동시 실행) 일 때가 93361 rps로 가장 높게 나왔습니다.
p50 기준으로 보면 Thread=5, benchmark 5개가 1.423 msec로 가장 빠르게 나왔습니다.

  • Server Thread=1,   benchmark   2개: 30406 rps, p50=2.679 msec, CPU Server:   66%, benchmark:   77%
  • Server Thread=2,   benchmark   3개: 77349 rps, p50=1.695 msec, CPU Server: 134%, benchmark: 156%
  • Server Thread=5,   benchmark   5개: 86145 rps, p50=1.423 msec, CPU Server: 296%, benchmark: 226%
  • Server Thread=10, benchmark 10개: 93361 rps, p50=2.655 msec, CPU Server: 314%, benchmark: 269%

📦 Thread=1 테스트

  • 서버 실행: build-dbg$ ping_iouring_server --proactor_threads=1
  • 테스트 툴 실행: $ bin/redis-benchmark -p 6380 -t set -d 10 -n 1000000 -q
  • 요약: benchmark 2개 일 때 30406 rps로 가장 높게 나왔다.
    • benchmark 1개 -> 29172 rps, CPU Server: 70%, benchmark: 64%, p50=1.311 msec
    • benchmark 2개 -> 30406 rps, CPU Server: 66%, benchmark: 77%, p50=2.679 msec
    • benchmark 3개 -> 24376 rps, CPU Server: 65%, benchmark: 74%, p50=4.975 msec
  • benchmark 1개, 4회 실행 -> 29172 rps, CPU Server: 70%, benchmark: 64%
    • 1회 SET: 28772 requests per second, p50=1.311 msec
    • 2회 SET: 30375 requests per second, p50=1.231 msec
    • 3회 SET: 29940 requests per second, p50=1.263 msec
    • 4회 SET: 27601 requests per second, p50=1.335 msec
    • CPU 사용량
  • benchmark 2개, 1회 실행 -> 30406 rps, CPU Server: 66%, benchmark: 77%
    • SET: 15204.73 requests per second, p50=2.679 msec
    • SET: 15202.65 requests per second, p50=2.679 msec
    • CPU 사용량
  • benchmark 3개, 1회 실행 -> 24376 rps, CPU Server: 65%, benchmark: 74%
    • SET: 8184.65 requests per second, p50=4.975 msec
    • SET: 8080.87 requests per second, p50=4.983 msec
    • SET: 8112.01 requests per second, p50=4.975 msec
    • CPU 사용량

📦 Thread=2 테스트

  • 서버 실행: build-dbg$ ping_iouring_server --proactor_threads=2
    benchmark 실행 전 wa가 100이다.
  • 테스트 툴 실행: $ bin/redis-benchmark -p 6380 -t set -d 10 -n 1000000 -q
  • 요약: benchmark 3개 일 때 77349 rps로 가장 높게 나왔다.
    • benchmark 1개 -> 21348 rps, CPU Server: 105%, benchmark: 61%, p50=1.239 msec
    • benchmark 2개 -> 46029 rps, CPU Server: 143%, benchmark: 131%, p50=1.527 msec
    • benchmark 3개 -> 77349 rps, CPU Server: 134%, benchmark: 156%, p50=1.695 msec
    • benchmark 4개 -> 69346 rps, CPU Server: 126%, benchmark: 149%, p50=2.495 msec
  • benchmark 1개, 2회 실행 -> 21348 rps, CPU Server: 105%, benchmark: 61%
    • 1회 SET: 21967.88 requests per second, p50=1.239 msec
    • 2회 SET: 20729.25 requests per second, p50=1.271 msec
    • CPU 사용량
  • benchmark 2개(동시 실행) -> 46029 rps, CPU Server: 143%, benchmark: 131%
    • SET: 22928.94 requests per second, p50=1.527 msec
    • SET: 23101.62 requests per second, p50=1.527 msec
    • CPU 사용량
  • benchmark 3개(동시 실행) -> 77349 rps, CPU Server: 134%, benchmark: 156%
    • SET: 25661.42 requests per second, p50=1.695 msec
    • SET: 25817.78 requests per second, p50=1.695 msec
    • SET: 25871.21 requests per second, p50=1.687 msec
    • CPU 사용량
  • benchmark 4개(동시 실행) -> 69346 rps, CPU Server: 126%, benchmark: 149%
    • SET: 17421.91 requests per second, p50=2.495 msec
    • SET: 17278.92 requests per second, p50=2.495 msec
    • SET: 17289.97 requests per second, p50=2.503 msec
    • SET: 17358.10 requests per second, p50=2.495 msec
    • CPU 사용량

📦 Thread=5 테스트

  • 서버 실행: build-dbg$ ping_iouring_server --proactor_threads=5
    benchmark 실행 전 Cpu0~4번까지 100 wa이다.
  • 테스트 툴 실행: $ bin/redis-benchmark -p 6380 -t set -d 10 -n 1000000 -q
  • 요약: benchmark 5개 일 때 86145 rps로 가장 높게 나왔다.
    • benchmark   1개 -> 22830 rps, CPU Server: 112%, benchmark: 57%, p50=1.191 msec
    • benchmark   2개 -> 54688 rps, CPU Server: 221%, benchmark: 114%, p50=0.863 msec
    • benchmark   3개 -> 78307 rps, CPU Server: 280%, benchmark: 164%, p50=1.007 msec
    • benchmark   4개 -> 80022 rps, CPU Server: 278%, benchmark: 189%, p50=1.223 msec
    • benchmark   5개 -> 86145 rps, CPU Server: 296%, benchmark: 226%, p50=1.423 msec
    • benchmark   6개 -> 85520 rps, p50=1.727 msec
    • benchmark 10개 -> 74631 rps, CPU Server: 302%, benchmark: 258%, p50=3.295 msec
  • benchmark 1개, 4회 실행 -> 22830 rps, CPU Server: 112%, benchmark: 57%
    • 1회 SET: 19782.79 requests per second, p50=1.191 msec, 11월 08일
    • 2회 SET: 18838.07 requests per second, p50=1.247 msec, 11월 08일
    • 3회 SET: 26352.54 requests per second, p50=0.895 msec, 11월 09일
    • 4회 SET: 26351.85 requests per second, p50=0.927 msec, 11월 09일
    • CPU 사용량
  • benchmark 2개(동시 실행) -> 54688 rps, CPU Server: 221%, benchmark: 114%
    • SET: 27357.54 requests per second, p50=0.863 msec
    • SET: 27331.37 requests per second, p50=0.863 msec
    • CPU 사용량
  • benchmark 3개(동시 실행) -> 78307 rps, CPU Server: 280%, benchmark: 164%
    • SET: 26232.26 requests per second, p50=1.007 msec
    • SET: 26116.48 requests per second, p50=1.007 msec
    • SET: 25959.19 requests per second, p50=1.007 msec
    • CPU 사용량
  • benchmark 4개(동시 실행) -> 80022 rps, CPU Server: 278%, benchmark: 189%
    • SET: 20198.35 requests per second, p50=1.223 msec
    • SET: 20192.64 requests per second, p50=1.215 msec
    • SET: 20129.63 requests per second, p50=1.223 msec
    • SET: 19503.44 requests per second, p50=1.215 msec
    • CPU 사용량
  • benchmark 5개(동시 실행) -> 86145 rps, CPU Server: 296%, benchmark: 226%
    • SET: 17514.36 requests per second, p50=1.423 msec
    • SET: 17409.77 requests per second, p50=1.399 msec
    • SET: 17291.46 requests per second, p50=1.407 msec
    • SET: 16989.18 requests per second, p50=1.399 msec
    • SET: 16942.26 requests per second, p50=1.407 msec
    • CPU 사용량: us+sy=463%, hi+si=428% -> CPU를 사용하는 시간과 interrupt로 대기하는 시간이 큰 차이나지 않는다.
  • benchmark 6개(동시 실행) -> 85520 rps
    • SET: 14706.75 requests per second, p50=1.727 msec
    • SET: 14588.53 requests per second, p50=1.711 msec
    • SET: 14265.34 requests per second, p50=1.687 msec
    • SET: 14189.63 requests per second, p50=1.679 msec
    • SET: 13904.72 requests per second, p50=1.647 msec
    • SET: 13868.09 requests per second, p50=1.639 msec
  • benchmark 10개(동시 실행) -> 74631 rps, CPU Server: 302%, benchmark: 258%
    • SET: 7545.46 requests per second, p50=3.295 msec
    • SET: 7515.35 requests per second, p50=3.335 msec
    • SET: 7511.45 requests per second, p50=3.287 msec
    • SET: 7495.30 requests per second, p50=3.415 msec
    • SET: 7478.42 requests per second, p50=3.351 msec
    • SET: 7447.57 requests per second, p50=3.303 msec
    • SET: 7440.86 requests per second, p50=3.287 msec
    • SET: 7420.65 requests per second, p50=3.311 msec
    • SET: 7404.61 requests per second, p50=3.239 msec
    • SET: 7376.64 requests per second, p50=3.263 msec
    • CPU 사용량: us+sy=489%, hi+si=467% -> CPU를 사용하는 시간과 interrupt로 대기하는 시간이 큰 차이나지 않는다.

📦 Thread=10 테스트

  • 서버 실행: build-dbg$ ping_iouring_server --proactor_threads=10
  • 테스트 툴 실행: $ bin/redis-benchmark -p 6380 -t set -d 10 -n 1000000 -q
  • 요약: benchmark 10개 일 때 93361 rps로 가장 높게 나왔다.
    • benchmark   1개 -> 24204 rps, p50=0.975 msec
    • benchmark   2개 -> 44896 rps, p50=0.943 msec
    • benchmark   3개 -> 61057 rps, p50=0.959 msec
    • benchmark   4개 -> 69990 rps, p50=0.783 msec
    • benchmark 10개 -> 93361 rps, CPU Server: 314%, benchmark: 269%, p50=2.655 msec
    • benchmark 20개 -> 75359 rps, p50=7.199 msec
  • benchmark 1개 -> 24204 rps
    • SET: 24204.87 requests per second, p50=0.975 msec
  • benchmark 2개(동시 실행) -> 44896 rps
    • SET: 22510.86 requests per second, p50=0.943 msec
    • SET: 22386.89 requests per second, p50=0.951 msec
  • benchmark 3개(동시 실행) -> 61057 rps
    • SET: 20525.87 requests per second, p50=0.959 msec
    • SET: 20267.94 requests per second, p50=0.975 msec
    • SET: 20265.07 requests per second, p50=0.983 msec
  • benchmark 4개(동시 실행) -> 69990 rps
    • SET: 17820.55 requests per second, p50=0.759 msec
    • SET: 17686.59 requests per second, p50=0.751 msec
    • SET: 17309.72 requests per second, p50=0.783 msec
    • SET: 17175.64 requests per second, p50=0.807 msec
  • benchmark 10개(동시 실행) -> 93361 rps, CPU Server: 314%, benchmark: 269%
    • SET: 9570.57 requests per second, p50=2.639 msec
    • SET: 9449.56 requests per second, p50=2.655 msec
    • SET: 9429.96 requests per second, p50=2.639 msec
    • SET: 9369.88 requests per second, p50=2.687 msec
    • SET: 9340.56 requests per second, p50=2.655 msec
    • SET: 9314.63 requests per second, p50=2.655 msec
    • SET: 9282.90 requests per second, p50=2.655 msec
    • SET: 9248.38 requests per second, p50=2.607 msec
    • SET: 9246.33 requests per second, p50=2.647 msec
    • SET: 9114.36 requests per second, p50=2.551 msec
    • CPU 사용량: us+sy=459%, hi+si=536% -> CPU를 사용하는 시간보다 interrupt로 소비하는 시간이 더 많다.
  • benchmark 20개(동시 실행) -> 75359 rps
    • SET: 3801.36 requests per second, p50=7.175 msec
    • SET: 3801.66 requests per second, p50=7.319 msec
    • SET: 3785.24 requests per second, p50=7.479 msec
    • SET: 3785.40 requests per second, p50=7.239 msec
    • SET: 3784.44 requests per second, p50=7.399 msec
    • SET: 3778.45 requests per second, p50=7.287 msec
    • SET: 3779.83 requests per second, p50=7.351 msec
    • SET: 3777.08 requests per second, p50=7.399 msec
    • SET: 3776.79 requests per second, p50=7.295 msec
    • SET: 3773.41 requests per second, p50=7.199 msec
    • SET: 3759.34 requests per second, p50=7.567 msec
    • SET: 3757.97 requests per second, p50=7.127 msec
    • SET: 3761.94 requests per second, p50=7.279 msec
    • SET: 3757.77 requests per second, p50=7.295 msec
    • SET: 3752.47 requests per second, p50=7.095 msec
    • SET: 3750.80 requests per second, p50=6.975 msec
    • SET: 3749.59 requests per second, p50=7.111 msec
    • SET: 3744.00 requests per second, p50=7.055 msec
    • SET: 3745.96 requests per second, p50=7.079 msec
    • SET: 3746.15 requests per second, p50=7.047 msec

실행 옵션

실행 옵션 보기: build-dbg$ ping_iouring_server --helpfull

  • Flags from helio/examples/pingserver/ping_iouring_server.cc:
    • --http_port (Http port.); default: 8080;
    • --iouring_depth (Io uring depth); default: 512;
    • --port (Redis port); default: 6380;
    • --tls (Enable tls); default: false;
    • --tls_cert (); default: "";
    • --tls_key (); default: "";
    • --tls_verify_peer (Require peer certificate. Please note that this flag requires loading of server certificates (not sure why).); default: false;
    • --unixsocket (); default: "";
    • --use_incoming_cpu (If true uses incoming cpu of a socket in order to distribute incoming connections); default: false; (true인 경우 들어오는 연결을 분산하기 위해 소켓의 들어오는 CPU를 사용합니다.)
  • Flags from helio/util/fibers/proactor_pool.cc:
    • --proactor_affinity_mode (can be on, off or auto); default: "on";
    • --proactor_threads (Number of io threads in the pool); default: 0;
  • Flags from helio/util/fibers/uring_proactor.cc:
    • --enable_direct_fd (If true tries to register file descriptors); default: false;
  • Flags from helio/build-dbg/_deps/abseil_cpp-src/absl/flags/parse.cc:
    • --flagfile (comma-separated list of files to load flags from); default: ;
    • --fromenv (comma-separated list of flags to set from the environment [use 'export FLAGS_flag1=value']); default: ;
    • --tryfromenv (comma-separated list of flags to try to set from the environment if present); default: ;
    • --undefok (comma-separated list of flag names that it is okay to specify on the command line even if the program does not define a flag with that name); default: ;
  • Flags from helio/build-dbg/_deps/glog-src/src/logging.cc:
    • --alsologtoemail (log messages go to these email addresses in addition to logfiles); default: "";
    • --alsologtostderr (log messages go to stderr in addition to logfiles); default: false;
    • --colorlogtostderr (color messages logged to stderr (if supported by terminal)); default: false;
    • --colorlogtostdout (color messages logged to stdout (if supported by terminal)); default: false;
    • --drop_log_memory (Drop in-memory buffers of log contents. Logs can grow very quickly and they are rarely read before they need to be evicted from memory. Instead, drop them from memory as soon as they are flushed to disk.); default: true;
    • --log_backtrace_at (Emit a backtrace when logging at file:linenum.); default: "";
    • --log_dir (If specified, logfiles are written into this directory instead of the default logging directory.); default: "";
    • --log_link (Put additional links to the log files in this directory); default: "";
    • --log_prefix (Prepend the log prefix to the start of each log line); default: true;
    • --log_utc_time (Use UTC time for logging.); default: false;
    • --log_year_in_prefix (Include the year in the log prefix); default: true;
    • --logbuflevel (Buffer log messages logged at this level or lower (-1 means don't buffer; 0 means buffer INFO only; ...)); default: 0;
    • --logbufsecs (Buffer log messages for at most this many seconds); default: 30;
    • --logcleansecs (Clean overdue logs every this many seconds); default: 300;
    • --logemaillevel (Email log messages logged at this level or higher (0 means email all; 3 means email FATAL only; ...)); default: 999;
    • --logfile_mode (Log file mode/permissions.); default: 436;
    • --logmailer (Mailer used to send logging email); default: "";
    • --logtostderr (log messages go to stderr instead of logfiles); default: false;
    • --logtostdout (log messages go to stdout instead of logfiles); default: false;
    • --max_log_size (approx. maximum log file size (in MB). A value of 0 will be silently overridden to 1.); default: 1800;
    • --minloglevel (Messages logged at a lower level than this don't actually get logged anywhere); default: 0;
    • --stderrthreshold (log messages at or above this level are copied to stderr in addition to logfiles. This flag obsoletes --alsologtostderr.); default: 2;
    • --stop_logging_if_full_disk (Stop attempting to log to disk if the disk is full.); default: false;
    • --timestamp_in_logfile_name (put a timestamp at the end of the log file name); default: true;
  • Flags from helio/build-dbg/_deps/glog-src/src/utilities.cc:
    • --symbolize_stacktrace (Symbolize the stack trace in the tombstone); default: true;
  • Flags from helio/build-dbg/_deps/glog-src/src/vlog_is_on.cc:
    • --v (Show all VLOG(m) messages for m <= this. Overridable by --vmodule.); default: 0;
    • --vmodule (per-module verbose level. Argument is a comma-separated list of =. is a glob pattern, matched against the filename base (that is, name ignoring .cc/.h./-inl.h). overrides any value given by --v.); default: "";

서버 로그

log level 2(--v=2)로 실행했을 때 로그입니다.

📦 서버 실행

build-dbg$ ping_iouring_server --logtostderr --proactor_threads=2 --v=2

📦 redis-ecli 접속 시 서버 로그

redis-ecli -p 6380 [접속]

📦 PING 명령 실행 시 서버 로그

redis-ecli> ping -> PONG

📦 SET 명령 실행 시 서버 로그

redis-ecli> set key value -> OK

📦 EXIT (redis-ecli 종료)

redis-ecli> exit

📦 서버 종료 (Ctrl+C)



소스 설명

소스는 다음 3개 파일로 구성됩니다.

  • ping_iouring_server.cc (269줄): main()이 있음.
  • resp_parser.h (82줄): RESP 파서 헤더 파일
  • resp_parser.cc (358줄): RESP 파서 C++ 파일

RESP는 REdis Serialization Protocol의 약자(略字)입니다. RESP는 레디스 서버와 클라이언트(예: redis-cli, lettuce(Java Library)), 서버와 서버(마스터-복제) 간에 통신할 때 사용하는 형식(format)/규약(protocol)입니다. 특수문자를 포함할 수 있습니다. 즉 binary safe 합니다.
RESP에 대한 자세한 설명은 여기를 참조하세요.

📦 resp_parser.h

제로 카피 파서(zero-copy parser)입니다. 사용자는 'RespExpr'에 계속 액세스하는 동안 파서가 'COMMAND_READY'를 반환하는 경우 'str'을 무효화해서는 안 됩니다. 그러나 파서가 'MORE_INPUT'을 반환하는 경우 파서는 '소비된(consumed)' 결과에 따라 내부적으로 중간 상태를 캐시하므로 사용자는 'str'을 무효화할 수 있습니다. 파서는 최소 임계값 미만이 전달되고 'COMMAN_READY'에 도달하지 않은 경우 문자열 또는 그 일부를 사용한다고 보장하지 않습니다.

It's a zero-copy parser. A user should not invalidate str if the parser returns COMMAND_READY as long as he continues accessing RespExpr. However, if parser returns MORE_INPUT a user may invalidate str because parser caches the intermediate state internally according to 'consumed' result. A parser does not guarantee to consume the string or part of it if less than a minimal threshold was passed and COMMAN_READY is not reached.

주요한 정의들

  • enum ParseResult : uint8_t { OK, MORE, INVALID, };
  • enum State : uint8_t { START = 0, INLINE, ARRAY_LEN, PARSE_ARG, BULK_STR, FINISH_ARG, CMD_COMPLETE, };
  • State state_ = START; (초기값)
  • enum Status { RESP_OK, MORE_INPUT, INVALID_ARRAYLEN, INVALID_BULKLEN, INVALID_STRING, INVALID_INT };
  • Status last_status_ = RESP_OK; (초기값)

📦 resp_parser.cc

redis-cli에서 "SET KEY VALUE"를 입력하면 resp 포멧으로 아래와 같이 변경되어 서버에 전달됩니다.
"*3<CR><LF>$3<CR><LF>SET<CR><LF>$3<CR><LF>KEY<CR><LF>$5<CR><LF>VALUE<CR><LF>"
<CR>는 carriage return(\r)을 나타내고, <LF>는 line feed(\n)를 나타냅니다.

아래 RespParser::Parse() 함수는 resp 포멧으로 변경된 문자열을 처리(parsing)합니다.

RespParser::Parse() 함수 소스 요약

처리과정 설명

  1. 처음에 InitStart()를 호출해서 '*'를 확인하고 state_ = ARRAY_LEN;
  2. switch에서 ARRAY_LEN 이면 ConsumeArrayLen()를 호출해서 '3'을 추출해서 저장하고 state_ = PARSE_ARG;
  3. PARSE_ARG 이면 ParseArg()를 호출해서 '$3'에서 '3'을 추출하고 state_ = BULK_STR;
  4. BULK_STR 이면 ConsumeBulk()를 호출해서 'SET'을 추출하고 state_ = FINISH_ARG;
  5. FINISH_ARG 이면 HandleFinishArg()를 호출해서 데이터(문자열)이 더 있으면 state_ = PARSE_ARG; 없으면 state_ = CMD_COMPLETE;
  6. state_ == PARSE_ARG 이면 3.으로 가서 "$3<CR><LF>KEY<CR><LF>"를 계속 처리하고 state_ = CMD_COMPLETE 이면 while()을 종료한다.

RESP(REdis Serialization Protocol) 구분자 설명

  • 클라이언트가 서버로 명령을 보낼 때 구분자: 서버에서 받아서 처리
    • multibulk: 구분자 '*' 배열을 표시 포멧: *3<CR><LF> -> ConsumeArrayLen()
    • bulk: 구분자 '$' 특수문자가 포함된 문자열 포멧: $3<CR><LF>KEY<CR><LF> -> ParseArg()
  • 서버가 클라이언트로 응답을 보낼 때 구분자: 클라이언트에서 받아서 처리
    • integer: 구분자 ':' 정수 표시 포멧: :1234<CR><LF>
    • inline: 구분자 '+','-' 단순 문자열 표시 포멧: +OK<CR><LF>, +PONG<CR><LF>, -ERR no such key<CR><LF>

함수 리스트

  • auto RespParser::Parse(Buffer str, uint32_t* consumed, vector<Buffer>* res) -> Status { ... }
  • void RespParser::InitStart(uint8_t prefix_b, vector<Buffer>* res)
  • void RespParser::CacheState(vector<Buffer>* res)
  • auto RespParser::ParseInline(Buffer str) -> Status { ... } -> INLINE: +,-
  • auto RespParser::ParseNum(Buffer str, int64_t* res) -> ParseResult { ... } -> 숫자 추출
  • auto RespParser::ConsumeArrayLen(Buffer str) -> Status { ... } -> ARRAY_LEN: multibulk(*)
  • auto RespParser::ParseArg(Buffer str) -> Status { ... } -> PARSE_ARG: bulk($),integer(:)
  • auto RespParser::ConsumeBulk(Buffer str) -> Status { ... } -> BULK_STR
  • void RespParser::HandleFinishArg() -> FINISH_ARG
  • void RespParser::ExtendLastString(Buffer str)

📦 ping_iouring_server.cc

◎ main() 함수 요약

◎ PingListener 클래스 요약

◎ PingListener 클래스 PickConnectionProactor() 함수 요약

◎ PingConnection 클래스 요약

◎ PingConnection 클래스 HandleRequests() 함수 요약

여기서 resp_parser.Parse()를 호출해서 파싱하고 'PONG' 또는 'OK'를 리턴한다.



Email 답글이 올라오면 이메일로 알려드리겠습니다.