Cache performs two gets on misses
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- python
- Lĩnh vực
- performance
Hướng nghiên cứu
Bắt đầu bằng cách theo dõi CacheController.cached_request() và conditional_headers(), sau đó kiểm tra các chỗ sử dụng self.cache.get khác được đề cập trong issue. Tái hiện một cache miss và xem lại các test hiện có hoặc logging xung quanh những entry point này; done cần được định nghĩa là một hành vi đã được thống nhất để tránh một lần get thứ hai không cần thiết mà không làm hỏng việc xử lý conditional headers.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
We observe two cache.get() calls whenever we miss. The first attempt is made in CacheController.cached_request(). We see the "No cache entry available" in logs. However, we immediately see another cache.get() call after this. This seems to be because CacheController.conditional_headers() makes another call to self.cache.get().
This doesn't appear to be ideal, but I'm not sure what change to propose. I see some other usage of self.cache.get in the Controller as well. Since we don't rely on etag/last-modified headers, we may just use a custom Controller that has a condition_headers that simply returns {}, but raising here to see if there's any shared appreciation for trying to limit the number of get calls to make to the cache, or ideas for how otherwise to improve that.
- Ngôn ngữ chính
- Python
- Star
- 505
- Fork
- 153
- Merge trung bình
- 5 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 5
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của psf/cachecontrol
-
Cache Deserialization (part two) -- warning message incorrect?Có thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
psf/cachecontrol#209 · 5 bình luận ·
-
Race condition in send()Có thể đã có người làm @JulienPalard đã nhận 148 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
psf/cachecontrol#424 · 1 bình luận ·
-
HTTP 302 Found responses with Cache Headers not being cachedCó thể đã có người làm @cburroughs đã nhận 281 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 42/100
psf/cachecontrol#384 · 18 bình luận ·
-
Head request is not cached even with cacheable_methods=("GET", HEAD") without a previous GETCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
psf/cachecontrol#337 · 6 bình luận ·
-
Investigate failure to load caches above `2^32 - 1` bytesCó thể làm lại được @woodruffw đã nhận 854 ngày trước và không có pull request nào đang mở. Đang mở
psf/cachecontrol#336 · 4 bình luận · 1 reaction · 1 người được giao ·
Tất cả issue của psf/cachecontrol
Issue tương tự
-
good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
btclib-org/btclib-node#1955 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation v0.9.2
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 72/100
khuisman/mcp-gee-sweet#1033 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
ossf/cve-bin-tool#5966 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 2 ngày
-
write_iceberg ignores the table's write.parquet.compression-codec propertyCó thể đã có người làm @YuangGao đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Eventual-Inc/Daft#7606 ·
Maintainer thường phản hồi trong vòng 1 ngày