lastest update: 20250415
본 글의 아이디어를 만들어주신, 아래의 분들께 감사의 인사를 드립니다.
(20250414-3) PyHFT 개발 - 고성능 메시지 미들웨어 개발 에선 기능 구현과 최적화를 시도했다.
HFT 플랫폼을 세일즈하는 회사의 브로슈어
벤치마크로 설정한 메시지 브로커인데, 기존의 rustlang 기반의 메시지 브로커가 217,174msg/sec 여서 조금 충격적이다. 아마도 publisher가 파이썬인 관계로 거기서 병목이 생기는 것 같다. 이 부분은 다음 게시물에 추가 튜닝을 해볼 생각이다.
인하우스 개발
현재까지 Critical Path의 latency는 다음과 같다.
| Rust-zmq | Python-zmq | 비고 | |
|---|---|---|---|
| Total time elapsed (s) | 0.2313 | 1.1178 | - |
| Average latency (ms) | 0.0025 | 13.9880 | - |
| Median latency (ms) | 0.0010 | 14.5678 | - |
| Minimum latency (ms) | 0.0001 | 1.9570 | - |
| Maximum latency (ms) | 0.0090 | 23.1042 | - |
| Standard deviation (ms) | 0.0029 | 6.3415 | - |
| 95th Percentile latency (ms) | 0.0081 | — | 8.1 us |
| 99th Percentile latency (ms) | 0.0087 | — | 8.7 us |
| Approximate throughput (msg/s) | 217174.04 | 913.06 | - |
| theoretical latency (ms/message) | 0.00460 | 1.095 | 238x |
message middle-ware의 레이턴시를 줄이는것도 중요하지만, HFT 전략의 경우 시장 데이터 수집을 해야한다. 여기서 추가되는 요구사항은 Logging을 할때 트레이딩 흐름에 방해될만큼의 레이턴시가 발생하면 안된다.
목표는 거의 무시할 수 있을 정도로 빠르게 로깅이 처리되어야 한다.