Báo Cáo Profiling Get Rooms

Ngày: 2026-04-13
Khách sạn: Grand Millennium Kuala Lumpur (ID: 524557)
Search ID: e396d2b8612cc38f6587054cecddc9c3
Chế độ: Progressive

1. Tổng Quan

Tổng thời gian phản hồi get_rooms: ~3.35s (lần gọi đầu tiên, chưa có cache)

Bước	Thời gian	% Tổng
HTTP đến EasyGDS Gateway (`/api/v2/getrooms`)	1.84s	55%
HTTP đến Olympus (`handle_room_mapping`)	1.16s	35%
Tính giá (pricer, delta rooms)	0.08s	2%
Redis / logic khác	~0.27s	8%
Tổng cộng	3.35s	100%

2. Kết Quả cProfile (top 25 theo cumulative time)

   ncalls  tottime  percall  cumtime  percall  hàm
        1    0.000    0.000    3.355    3.355  hotels/__init__.py:169(get_rooms)
        1    0.000    0.000    3.355    3.355  hotels/__init__.py:265(_get_rooms_progressive)
        1    0.000    0.000    3.149    3.149  goquo/hotel.py:675(get_rooms)
        2    0.000    0.000    2.968    1.484  request_handler/__init__.py:17(handle)        ← 2 HTTP calls
        2    0.000    0.000    2.968    1.484  requests/api.py:103(post)
        2    0.000    0.000    2.953    1.476  requests/sessions.py:673(send)
       12    1.902    0.159    1.902    0.159  {ssl._SSLSocket.read}                         ← SSL I/O
        1    0.000    0.000    1.819    1.819  gateways/hotel.py:223(get_rooms)              ← HTTP #1: EasyGDS
        1    0.001    0.001    1.230    1.230  goquo/hotel.py:1158(_group_rooms)
        1    0.000    0.000    1.161    1.161  olympus/__init__.py:341(handle_room_mapping)  ← HTTP #2: Olympus
        1    0.000    0.000    1.161    1.161  olympus/__init__.py:74(do_request)

3. Nguyên Nhân Chậm

Cả 2 bottleneck đều là HTTP calls ra ngoài — không phải do logic nội bộ:

Bottleneck #1 — EasyGDS Gateway (1.84s)

Endpoint: POST /api/v2/getrooms với wait_time=100ms
Chủ yếu do SSL handshake + network latency (12 lần đọc SSL socket, tổng 1.9s)
Không thể loại bỏ — bắt buộc phải gọi để lấy rates mới nhất từ supplier

Bottleneck #2 — Olympus `handle_room_mapping` (1.16s)

Được gọi bên trong _group_rooms() để enrich tên/metadata room type
Mỗi lần gọi get_rooms đều phải gọi 1 lần HTTP đến Olympus
Dữ liệu mapping là dữ liệu tĩnh (tên room type không thay đổi theo thời gian)
Có thể cache vào Redis → tiết kiệm ~1.16s mỗi lần gọi cold

4. Kiểm Tra Logic Progressive ✅

Thực hiện 3 lần gọi liên tiếp trên cùng 1 khách sạn:

Lần gọi	Thời gian	Nguồn dữ liệu
Lần 1 — cold (chưa có cache)	3.335s	Gọi Gateway + Olympus
Lần 2 — progress=1, cache hit	0.002s	Lấy từ Redis cache
Lần 3 — progress=1, cache hit	0.001s	Lấy từ Redis cache

Logic progressive hoạt động đúng. Sau khi room_progress=1 được lưu vào cache, các lần gọi tiếp theo trả về trong ~2ms mà không cần gọi bất kỳ service nào.

5. Đề Xuất Tối Ưu

Ưu tiên	Hành động	Tiết kiệm dự kiến
Cao	Cache kết quả Olympus `handle_room_mapping` vào Redis (TTL: 1h)	~1.16s/lần cold call
Trung bình	Tăng `wait_time` của gateway `getrooms` để giảm số round-trip	Giảm số lần gọi
Thấp	Connection pool / keep-alive cho HTTPS đến gateway	Giảm SSL overhead

6. Luồng Hoạt Động Hiện Tại (Progressive)

Lần gọi #1 (cold):
  Kiểm tra Redis cache → không có
  → Gọi EasyGDS getrooms (1.84s)
  → _group_rooms() → gọi Olympus handle_room_mapping (1.16s)
  → Tính giá delta (0.08s)
  → Lưu vào Redis: {rooms, progress=1}
  → Trả về ~3.35s

Lần gọi #2 trở đi (warm):
  Kiểm tra Redis cache → có, progress=1
  → Trả về ngay ~0.002s ✅