New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lib/promscrape/client: replace fasthttp.HostClient with fasthttp.Client #4931
Conversation
This will allow to handle redirect easily as fasthttp.Client creates new fasthttp.HostClient on demand and caches created instances per URL. See: #1945 Signed-off-by: Zakhar Bessarab <z.bessarab@victoriametrics.com>
…nt items Change default expiration of HostClient map to use MaxIdleConnDuration instead of hardcoded value of 1m. This will allow to get more control on clients eviction, for example for VictoriaMetrics/VictoriaMetrics#4931
…Client for scraping targets in non-streaming mode While fasthttp.Client uses less CPU and RAM when scraping targets with small responses (up to 10K metrics), it doesn't work well when scraping targets with big responses such as kube-state-metrics. In this case it could use big amounts of additional memory comparing to net/http.Client, since fasthttp.Client reads the full response in memory and then tries re-using the large buffer for further scrapes. Additionally, fasthttp.Client-based scraping had various issues with proxying, redirects and scrape timeouts like the following ones: - #1945 - #5425 - #2794 - #1017 This should help reducing memory usage for the case when target returns big response and this response is scraped by fasthttp.Client at first before switching to stream parsing mode for subsequent scrapes. Now the switch to stream parsing mode is performed on the first scrape after reading the response body in memory and noticing that its size exceeds the value passed to -promscrape.minResponseSizeForStreamParse command-line flag. Updates #5567 Overrides #4931
…Client for scraping targets in non-streaming mode While fasthttp.Client uses less CPU and RAM when scraping targets with small responses (up to 10K metrics), it doesn't work well when scraping targets with big responses such as kube-state-metrics. In this case it could use big amounts of additional memory comparing to net/http.Client, since fasthttp.Client reads the full response in memory and then tries re-using the large buffer for further scrapes. Additionally, fasthttp.Client-based scraping had various issues with proxying, redirects and scrape timeouts like the following ones: - #1945 - #5425 - #2794 - #1017 This should help reducing memory usage for the case when target returns big response and this response is scraped by fasthttp.Client at first before switching to stream parsing mode for subsequent scrapes. Now the switch to stream parsing mode is performed on the first scrape after reading the response body in memory and noticing that its size exceeds the value passed to -promscrape.minResponseSizeForStreamParse command-line flag. Updates #5567 Overrides #4931
@zekker6 , thanks for the pull request! I used ideas from this pull request in the commit bc7cf49 , which finally switches from Closing this pull request as obsolete then. |
FYI, the commit bc7cf49 has been included in v1.97.0 release. |
This will allow to handle redirect easily as fasthttp.Client creates new fasthttp.HostClient on demand and caches created instances per URL.
See: #1945