부록: 성능 벤치마크

아홉 서버를 각자 별도 프로세스에서 측정했다.

Spring Boot는 기본 설정으로 실행한다: 설정한 프로퍼티가 없으며, Tomcat, Jackson, Thymeleaf는 스타터가 가져오는 그대로다. Spider Silk도 인자로 고르는 서버와 템플릿 엔진 외에는 기본 설정으로 실행한다. 두 서버 모두 최대 200개의 플랫폼 스레드 풀을 쓰며, 어느 쪽도 가상 스레드를 쓰지 않는다.

Spider Silk의 네이티브 이미지는 Jetty용으로만 빌드했다.

각 케이스는 두 프레임워크에서 같은 응답을 받는 요청 하나다.

json-list 본문은 필드 다섯 개짜리 레코드 100개이며, 두 프레임워크는 이를 바이트 단위까지 똑같이 보낸다. json-post 케이스는 그 문서를 POST /items`의 본문으로 보내며, 두 프레임워크는 이를 레코드로 읽고 그 개수로 응답한다. `/fortunes 페이지는 TechEmpower 벤치마크의 fortune 12개를 담은 표이며, 그중 하나는 HTML 이스케이프가 필요하고 하나는 일본어다. 두 Thymeleaf 페이지는 같은 템플릿 파일이며 같은 바이트로 렌더링된다. jte 페이지는 빈 줄, 그리고 텍스트 안의 "와 '를 이스케이프하지 않는다는 점이 다르며, 이는 HTML이 허용하는 형태다. 핸들러가 응답하는 값은 모두 시작할 때 한 번 만들어 두므로, 요청은 데이터가 아니라 프레임워크, 직렬화기, 렌더러를 측정한다.

benchmark/run.sh가 전체 실행을 이끈다.

최대 부하 상태에서 이전 프로세스가 멈춘 직후에 시작한 프로세스는 부팅이 최대 1.5배까지 느리므로, 부팅 시간은 부하 케이스와 따로 잰다.

부하는 wrk 4.1.0이 루프백으로 스레드 4개와 keep-alive 연결 64개를 써서 건다. 서버는 성능 코어 네 개인 CPU 0~3에, wrk는 저전력 효율 코어 네 개인 CPU 4~7에 고정한다. 모든 JVM과 네이티브 이미지에는 -Xms1g -Xmx1g를 준다. JVM은 Temurin 25이며 기본 컬렉터인 G1을 쓴다. -native 이미지는 GraalVM CE 25.2.4로 빌드하며, 이 배포판의 컬렉터는 Serial GC뿐이다. -native-oracle과 -native-pgo 이미지는 Oracle GraalVM 25.4.4로 빌드하며, 기본 컬렉터인 Serial GC를 그대로 쓴다. 기본 설정으로 빌드하면 Oracle GraalVM은 기계 학습 모델로 코드에서 메서드마다 프로파일을 추론한다. PGO 이미지는 그 자리에 기록한 프로파일을 쓴다.

보고하는 처리량과 각 지연 시간 백분위수는 세 라운드의 중앙값을 각각 따로 구한 것이다. 라운드 간 대부분 케이스의 처리량은 중앙값에서 10% 이내에 머물렀다. `spider-silk-jetty`는 한 라운드에서 `text`의 중앙값보다 36% 높았고, `json-list`에서 13% 높았다. `spring-boot`는 `json`에서 중앙값보다 11% 높았다. 네이티브 이미지 중에서는 여덟 케이스에서 한 라운드가 중앙값보다 10%~15% 높았고, 두 케이스에서 11%~12% 낮았다: `json`의 `spring-boot-native`와 `json-post`의 `spider-silk-jetty-native`다. 세 라운드의 중앙값은 그런 라운드를 걸러 낸다. 실행 중 실패한 요청은 없었다.

실행 중에도 데스크톱 세션은 켜져 있었으며, 터미널, Dropbox, 유휴 상태의 로컬 텍스트 음성 변환 서버가 열려 있었고, 이들은 쉬는 동안 CPU 하나의 몇 퍼센트를 쓴다. 웹 브라우저 창은 열려 있지 않았다.

처리량은 초당 요청 수다. 지연 시간은 wrk가 요청을 보낸 때부터 응답을 받을 때까지 잰 시간이며, 단위는 밀리초다. CPU는 측정 동안 서버 자신이 쓴 CPU 시간이며, 400%는 측정 내내 코어 네 개가 바빴다는 뜻이다.

아래 비율은 Spider Silk의 처리량을 Spring Boot의 처리량으로 나눈 값이므로, 1보다 크면 Spider Silk가 앞선다. 마지막 세 열은 같은 GraalVM으로 빌드한 두 애플리케이션의 네이티브 이미지끼리 견준다.

아래 각 칸은 네이티브 이미지의 처리량을 같은 애플리케이션의 JVM 처리량에 대한 비율로 나타낸 것이며, Spider Silk는 Jetty 위의 값이다.

Oracle GraalVM의 기본 설정은 GraalVM CE보다 0.97배~1.60배 많은 요청을 처리하며, 기록한 프로파일은 그 위에 1.12배~1.43배를 더한다. PGO 이미지는 한 곳을 빼고 모든 백분위수에서 GraalVM CE 이미지보다 지연 시간도 낮다. spring-boot-native-pgo의 p99는 json-list에서 GraalVM CE의 32.79 ms에 비해 9.77 ms이지만, json-post에서는 p50이 8.87 ms에서 3.63 ms로 내려가는 동안 p99는 31.50 ms로 GraalVM CE의 28.53 ms보다 낫지 않다.

부팅 시간은 프로세스를 띄우기 직전부터 첫 200까지를 열 번 잰 값의 중앙값이다. 메모리는 그 시점의 프로세스 상주 메모리(RSS)다.

폴링은 curl 자체의 기동을 포함해 약 14 ms 간격으로 이루어지므로, 네이티브 이미지의 부팅 시간은 그 눈금 위에 놓인다. Spider Silk의 PGO 이미지는 열 번 중 네 번은 첫 폴링에 9~10 ms로, 나머지는 두 번째 폴링에 23~24 ms로 응답했다. PGO 이미지는 부팅 시점의 메모리도 적다: GraalVM CE의 37 MB와 73 MB에 비해 28 MB와 51 MB다.

Spring Boot 자신의 로그는 JVM에서 Started SpringBootBenchmark in 0.72 seconds, GraalVM CE 네이티브 이미지에서 in 0.024 seconds를 보고한다. 표와의 차이는 JVM 자체의 기동 시간과 첫 응답까지의 시간이다.

부하 중 JVM 프로세스는 770~870 MB를 차지했으며, 그 대부분은 -Xms1g가 확보하는 1 GiB 힙이다. 네이티브 이미지는 55~351 MB를 차지했으며, spring-boot-native의 json-post에서 가장 많았다.

각 네이티브 이미지는 깨끗한 프로젝트에서 세 번씩, 계측 이미지는 한 번씩 빌드했다. 빌드 시간은 애플리케이션 컴파일, 해당하는 경우 Spring의 AOT 처리, native-image 실행을 포함한다. 애플리케이션이 의존하는 Spider Silk 모듈은 이미 컴파일되어 있었으므로 포함하지 않는다.

native-image는 모든 빌드에서 CPU 여덟 개를 6.5~7.1의 부하로 썼다. PGO 빌드는 Oracle GraalVM의 기본 빌드보다 시간이 약 3분의 1 덜 걸리며, 그 바이너리는 GraalVM CE의 바이너리보다 약 4분의 1 작다. PGO 이미지에는 먼저 계측 빌드와 프로파일 수집 실행이 필요하며, 계측 이미지는 GraalVM CE 이미지의 2.6배 크기다. JVM 애플리케이션의 의존성은 Spider Silk가 9.6 MB, Spring Boot가 21 MB다.

benchmark/json-bench는 HTTP 없이 JSON 엔진만을 HTTP 케이스가 보내는 문서로 잰다: json-list의 레코드 100개와 json의 27바이트 객체다. 소수부가 있는 숫자를 셋씩 가진 장소 100개와 상태가 enum인 주문 100개도 재는데, 이를 보내는 HTTP 케이스는 없다. 같은 레코드 100개를 더 여러 형태로도 잰다: 이스케이프할 것이 없는 것, 문자열이 한글인 것, 키가 역순인 것, 설명이 영어와 한글로 200자인 것, Python의 json.dumps와 pretty printer가 쓰듯 공백을 넣은 것, id가 13자리와 18자리인 것, 문자열이 0~1자인 것이다. 역순 키와 공백을 넣은 키는 다른 프로그램이 쓴 문서를, 긴 설명은 상품 페이지 같은 산문을 대표한다. 측정은 2026-10-11에 같은 머신에서, AC 전원과 performance 플랫폼 프로파일로 실행했다. 커밋 11b9a13 위에 변경을 얹어 Java 25용으로 컴파일한 silk-json을 대상으로, JMH 1.37로 포크 둘, 포크마다 각 1초짜리 워밍업 다섯 번과 측정 다섯 번, CPU 0~3에 고정, -Xms1g -Xmx1g, Temurin 25로 쟀다. 각 칸은 연산당 평균 시간과 연산당 할당 바이트이며, 후자는 JMH의 gc 프로파일러가 잰 값이다.

생성된 코덱은 목록을 Jackson 시간의 40%에 쓰고 24%에 읽으며, 할당은 3분의 1에서 절반 사이이고, 작은 객체는 Jackson 시간의 5분의 1이 안 되는 시간에 쓴다. 손으로 작성한 라이터는 트리와 코덱 사이에 놓이는데, 코덱이 상수에서 키를 복사하는 자리에서 라이터는 문서가 이미 쓴 키들 가운데서 키를 찾기 때문이다. 코덱은 10 KB 문서를 fastjson2 시간의 92%에 읽고, 작은 객체는 그 92%의 시간에 쓴다. fastjson2는 10 KB 문서 쓰기에서 3% 차이로 여전히 앞선다. 그 우위는 문자열을 쓰는 데서 나오며, 이스케이프할 문자열이 없는 곳에서 더 벌어진다: 평범한 레코드에서 1.17배, 한글 레코드에서 1.11배다. fastjson2는 String의 바이트를 sun.misc.Unsafe로 직접 읽는데, JDK는 이를 거두어들이는 중이고 코어는 쓰지 않는다. 코덱은 문자열의 문자를 getChars로 복사해 내고 하나씩 검사한다. 올바른 라이터라면 설 수 없는 바닥, 곧 문자열의 바이트를 아무 검사 없이 복사하는 쓰기는 평범한 레코드를 2.7 µs에 써서 fastjson2의 3.7 µs보다 빠르다. 그 복사본을 8바이트씩 검사하면 4.0 µs가 되므로, 우위는 전부 문자열 표현의 몫이다. 코덱은 따옴표와 역슬래시를 평범한 문자를 쓰는 같은 루프에서 이스케이프하며, 문자마다 표를 찾는 대신 비교한다. 그 전에는 첫 따옴표가 문자열의 나머지를 더 느린 루프로 보냈고, 같은 쓰기에 5.3 µs가 들었다. JDK 25의 JIT 컴파일러는 char를 byte로 좁히는 루프를 벡터화하지 않으므로, 쓰기 전에 문자열 전체를 검사하는 단계는 빨라지지 않고 오히려 느리게 측정됐다. 코덱은 멤버의 키와 값을 호출 하나, put(JsonKey, …​)로 쓰며, 이 호출은 라이터의 상태를 한 번 검사한다. 1000 미만의 수는 저장 한 번으로, 한글 음절 같은 3바이트 문자는 4바이트 저장 한 번으로 쓴다. 이전 빌드와 연달아 재면, 이로써 평범한 레코드가 4.4 µs에서 4.2 µs로, 한글 레코드가 4.4 µs에서 4.0 µs로 줄었다. 릴리스가 Java 25를 요구하기 전에 대상으로 삼던 Temurin 21에서도 비율은 같았다: fastjson2는 평범한 레코드를 1.15배, 한글 레코드를 1.13배 빠르게 쓰고, 코덱은 목록을 fastjson2 시간의 88%에 읽는다.

64자 이상의 문자열은 다른 경로를 탄다. JDK의 US_ASCII 인코더가 JIT 컴파일러의 인트린식으로 이를 버퍼에 좁혀 쓴다. 또 다른 인트린식인 문자열 자신의 indexOf가 따옴표와 역슬래시를 찾고, 그 앞까지 좁힌 바이트는 제어 문자만 8개씩 검사한다. 이스케이프는 그 뒤에 좁혀 둔 바이트를 다시 좁히지 않고 뒤로 민다. 인코더는 ASCII 밖의 첫 문자에서 멈추고, 문자열의 나머지는 한 문자씩 쓰는 루프로 간다. 이전 빌드들과 연달아 재면, 이로써 설명이 긴 레코드가 15.0 µs에서 8.6 µs로, 다시 6.9 µs로 줄었다. fastjson2는 여전히 이를 1.08배 빠르게 쓴다. 한글로 된 긴 설명은 코덱이 fastjson2 시간의 62%에 쓴다. Java 25에는 문자열의 Latin-1 바이트를 char로 넓히지 않고 복사하는 유일한 공개 호출인 MemorySegment.setString이 있다. 이를 거쳐 복사하고 바이트를 8개씩 검사하면 10 KB 목록 쓰기가 4.9 µs에서 5.4 µs로, 긴 설명 쓰기가 6.8 µs에서 7.1 µs로 느려졌으므로, 코덱은 이를 쓰지 않는다. 코덱은 이 문서에 0.7 KB를 더 할당하는데, 문서마다 한 번 만드는 인코더와 그 둘레의 버퍼 둘이다. 평범한 문자열은 Temurin 21, Temurin 25, GraalVM의 JIT 컴파일러 모두에서 약 16자부터 이 경로가 이득이다. 이스케이프가 있는 문자열은 컴파일러에 따라 48자에서 96자부터야 이득이고, 기준값 64는 그 둘 사이에 있다. 이 경로가 처음에 10 KB 목록에 지운 2~2.5%의 비용은 더는 보이지 않는다: 같은 빌드에서 이 경로를 빼면 목록 쓰기는 4.72 µs가 아니라 4.68 µs다.

enum 상수는 JsonKey로 한 번만 인코딩한 이름으로 쓰고 읽는다. 이름은 키처럼 복사해 쓰고, 읽을 때는 문자열을 만들지 않고 제자리에서 비교한다. 이전 빌드와 연달아 재면, 이로써 주문 쓰기가 2.9 µs에서 2.4 µs로, 읽기가 4.6 µs에서 3.0 µs로 줄었고, 지금은 fastjson2 시간의 91%와 96%다. 생성된 코덱은 enum이 어디에 있든 이렇게 한다: 프로퍼티, Optional, 컬렉션 원소, 맵 값이다.

코덱은 한글 레코드를 fastjson2 시간의 72%에 읽는다. ASCII 밖의 바이트가 있는 문자열은 같은 패스에서 검사하며 문자로 디코드하고, 그 앞의 ASCII는 검사 없이 넓힌다. 그 전에는 바이트를 검사한 뒤 JDK에 다시 디코드를 맡겼고, 같은 읽기에 11.0 µs가 들었다. fastjson2는 이를 검사하지 않는다: 과잉 길이 시퀀스나 UTF-8로 쓴 서로게이트가 값 안에서 U+FFFD가 되며, 코덱은 그런 문서를 거부한다. 생성된 읽기는 선언된 키를 먼저 순서대로 시도한다. 그 순서를 벗어난 키는 다음 멤버가 있는 자리의 4바이트로 switch해서 찾으며, 이 4바이트는 JsonInput.keyHead()가 읽는다. 이전 빌드와 연달아 재면, 이로써 목록이 6.0 µs에서 5.5 µs로, 역순 목록이 9.5 µs에서 8.0 µs로 줄었다. 문서가 선언 순서를 한 번 벗어나면 그 뒤의 키는 곧장 그 switch로 가며, 이로써 역순 레코드가 7.2 µs가 됐다. fastjson2는 여전히 이를 1.17배 빠르게 읽는다. 읽기는 키 앞과 쉼표 뒤의 공백도 건너뛰며, 쉼표 하나와 공백 하나를 먼저 확인한다. 이전 빌드와 연달아 재면, 이로써 json.dumps가 공백을 넣은 레코드가 10.0 µs에서 6.6 µs로 줄어 fastjson2 시간의 95%가 됐고, 들여쓴 레코드가 11.6 µs에서 8.6 µs로 줄었다. 이번 실행에서 들여쓴 레코드는 fastjson2 시간의 1.11배가 걸렸다. 8~16자리 정수는 두 워드로 읽으며, 이로써 18자리 id가 6.5 µs에서 5.9 µs로 줄었다. 코덱은 13자리와 18자리 id를 fastjson2 시간의 86%와 83%에 읽는다. 빈 문자열과 한 글자 문자열은 할당 없이 표에서 꺼내며, 이로써 그런 문자열을 가진 레코드가 3.4 µs와 13.9 KB에서 2.8 µs와 5.5 KB로 줄어 fastjson2 시간의 73%가 됐다. fastjson2는 긴 설명도 1.21배 빠르게 읽는다. fastjson2는 sun.misc.Unsafe를 거쳐 묶은 JDK 내부 메서드로 문자열의 끝을 찾고 String을 만들며, 공개 API에는 이에 맞먹는 것이 없다.

장소마다 소수 넷째 자리까지의 위도, 여섯째 자리까지의 경도, 첫째 자리까지의 평점이 있다. 코덱은 이를 fastjson2 시간의 96%에 같은 할당으로 읽고, Jackson 시간의 5분의 1에 읽는다. readDouble은 숫자를 그 자릿수에서 변환하며, 이런 숫자에는 곱셈이나 나눗셈 한 번이면 된다. 그 전에는 숫자마다 문자열을 만들어 Double.parseDouble에 넘겼고, 같은 읽기에 12.6 µs와 43.9 KB가 들었다. Jackson 3는 기본으로 빠른 파서로 double을 파싱하므로, USE_FAST_DOUBLE_PARSER를 켜도 달라지는 것이 없었다. 코덱은 장소를 fastjson2 시간의 98%에 그 절반의 할당, 곧 문서 자체보다 조금 많은 할당으로 쓰고, Jackson 시간의 절반이 안 되는 시간에 쓴다. JsonOutput은 double의 가장 짧은 십진수를 JDK 19부터 Double.toString이 쓰는 알고리즘으로 버퍼에 바로 늘어놓으며, 같은 텍스트를 쓴다. 그 전에는 숫자마다 Double.toString으로 문자열을 만들어 복사했고, 같은 쓰기에 16.5 µs와 35.6 KB가 들었다.

WebResponse.json이 본문을 보내듯 스레드의 버퍼에서 스트림으로 바로 쓰면, 목록은 3.8 µs와 184바이트가 든다. 이는 toBytes()가 문서를 복사해 넣는 배열보다 1.0 µs와 10.5 KB 적다. fastjson2의 JSON.writeTo도 그만큼 아끼므로, 이 절약은 라이브러리가 아니라 프레임워크의 몫이다. HTTP json-list 케이스에서는 같은 변경으로 요청당 할당이 Jetty에서 14.4 KB에서 3.8 KB로, Tomcat에서 13.2 KB에서 2.6 KB로 줄었으며, 30초 부하 동안의 GC 로그로 셌다.

fastjson2의 속도에는 표에 드러나지 않는 조건이 따른다. --sun-misc-unsafe-memory-access=deny에서 fastjson2 2.0.57은 초기화되지 않는다: JDKUtils.<clinit>이 arrayBaseOffset에서 실패하고, 이후의 모든 호출이 NoClassDefFoundError를 던진다. -Dfastjson2.creator=reflect도 같은 방식으로 실패하며, fastjson2에는 sun.misc.Unsafe 없이 도는 모드가 없다. JDK 24 이상에서는 첫 호출이 sun.misc.Unsafe의 메서드가 앞으로의 릴리스에서 제거된다는 경고를 찍는다. JEP 471과 JEP 498이 정한 순서는 경고, 기본값으로 거부, 제거다. JDK 26과 JDK 27의 기본값은 아직 경고이고, 거부를 기본값으로 삼거나 메서드를 제거하는 JEP는 아직 없다. VarHandle로 옮겨 가는 fastjson2의 2.1.x 브랜치는 2026년 2월 이후 변경이 없다. JVM에서 -Dfastjson2.creator=reflect를 주면 fastjson2는 실행 중에 클래스를 만들지 않으며, 목록을 평소의 네 배인 24.5 µs와 111.2 KB에 읽고 5.7 µs에 쓴다. GraalVM 네이티브 이미지에서 fastjson2는 String fast path와 생성 클래스를 끄고 리플렉션으로 바인딩하며, 이를 위해 바인딩하는 타입마다 reachability 메타데이터가 필요하다. fastjson2 2.0.57은 GraalVM CE 25.2.4에서 jar에 든 설정만으로는 네이티브 이미지로 빌드되지 않는다. 그 설정은 JSONFactory를 비롯한 몇 클래스를 빌드 시 초기화하고, 그 클래스들이 붙든 객체는 설정이 실행 시로 남겨 둔 클래스에 닿으며, native-image는 이를 거부한다. 패키지 전체를 빌드 시 초기화해 빌드한 이미지는 레코드를 잘못 읽는다: "available":false는 syntax error : 102로 실패하고 true는 읽힌다. fastjson2는 false를 sun.misc.Unsafe로 읽는데, 그 바이트 배열 오프셋은 JDKUtils가 이미지를 빌드한 JVM에서 계산한 값이다. 그 오프셋은 16이고, 이미지 자신의 값은 12다. JDKUtils는 fastjson2 자신의 설정이 빌드 시 초기화하는 클래스 가운데 하나이므로, 빌드되는 어떤 이미지에서도 오프셋이 틀린다. silk-json은 배열의 VarHandle 뷰로 읽으며, 이 뷰는 오프셋을 들고 있지 않다.

json-bench/native-bench.sh는 케이스 여섯 개를 GraalVM CE 25.2.4의 기본값으로 네이티브 이미지로 빌드하고, NativeBench가 JMH 없이 잰다: 3초 워밍업 뒤 1초 라운드 열 번의 중앙값이다. 같은 측정기를 Temurin 25에서 돌린 것이 JVM 열이다.

네이티브 이미지는 JVM 시간의 1.3배에서 2.6배가 걸리며, HTTP 케이스의 네이티브 이미지가 JVM보다 적은 요청에 응답하는 것과 같은 방향이다. -O3로 빌드한 이미지는 케이스마다 0%에서 8% 덜 걸렸고, -march=native로 빌드한 이미지는 6% 덜 걸리는 것부터 11% 더 걸리는 것까지 갈렸으므로, 어느 옵션도 JVM과의 차이를 닫지 못한다. fastjson2는 이미지가 문서를 잘못 읽었으므로 표에서 뺐다. HTTP 케이스에서 직렬화기와 파서는 각 요청의 한 몫이며, 결과 해석이 이를 처리량과 견준다.