Replace the field `bufKV` with two `[]byte` fields and remove the filed `buf`.
- Reduce Cookie from **224** to **192** bytes.
- In the benchmark tests, although there is no significant performance improvement, it theoretically reduces memory usage by **14.3%**.
* add test which will cause error
* rename test
* fix improper memory reuse in NewFastHTTPHandler
* move deep copy from VisitAll to f
* copy value string only for cookie
* Remove a redundant field and clarify the comments.
* Revert "Using atomic instead of mutex and delete scratch slice (#1833)"
This reverts commit 19c50cdc44.
* Support for delayed retry logic
* Support for resetting the request timeout before retrying
* Users can decide whether to retry based on the request error and the number of retries.
Estimating the time required for a request to complete is relatively straightforward, but when retries are factored in, it becomes challenging to gauge this time accurately.
The current client implementation does not immediately return when encountering an RST packet while sending a request, but instead ignores it. This behavior is inconsistent with the net/http package and does not make logical sense.
In some cases, the goroutines started by one test do not terminate smoothly before the next round of tests begins, causing interference between tests.
Performance Impact: This results in test completion times not increasing linearly with the count value.
Correctness Impact: It affects the accuracy of memory allocation test cases.
The `testClientDoTimeoutError` and `testClientGetTimeoutSuccess` test function does not immediately return or fatal when the test fails. Instead, it continues to stringify the byte slice that was passed as the `dst` parameter to the `Client.GetTimeout` method. If the test fails due to a timeout, the request may still be ongoing, and there might be a data race between writing to `dst` and the stringification operation.
* using atomic instead of mutex and delete scratch slice
* optimize struct
* fix default bool
* escape data race
* avoid the momentary change of wp.workersCount.
* removed unused tail (for now)
* little fixes
* fixed allocations
This option immediately exits the loop when the maximum number of vorkers is reached, rather than creating a new vorker if the limit is reached. This reduces the frequency of unnecessary operations and potential locks in sync.Pool
* Update for linter workerpool.go
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Update for lint#2 workerpool.go
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Update for lint#3 workerpool.go
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Update for lint#4 workerpool.go
* eliminating potential data races
---------
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
Add a multifunctional `Dialer` struct and reimplement the function API
Reimplement the existing function interfaces of the fasthttpproxy package through Dialer. Refactor Dialer.GetDialFunc to ensure that its performance is comparable to the original function interfaces when the proxy does not change with the request address.
In the current implementation, there are several places where it's assumed that SetReadDeadline and similar functions logically won't affect a closed connection. However, these assumptions may not hold in certain specific situations. Therefore, instead of asserting that such errors will never occur, simply return the errors encountered during the execution of these methods.
Fix the MaxConns semaphore issue in HostClient.
Currently, the conns length and connsCount count in HostClient do not correctly implement the MaxConns semaphore mechanism.
This fix ensures that the waiter wake-up chain does not break.
* Reduce sizeof ResponseHeader and RequestHeader
+ Reduce ResponseHeader from 320 to 312 bytes
+ Reduce RequestHeader from 360 to 352 bytes
+ In the benchmark tests, although there is no significant performance improvement, it theoretically reduces memory usage by 2.2% to 2.5%.
* Remove redundant comment
* The StreamRequestBody should not read content beyond what is required.
The StreamRequestBody feature on the server side should not read content that does not belong to the current request body.This is more logical and consistent with the result of not using the StreamRequestBody feature.Fixes: https://github.com/valyala/fasthttp/issues/1816.
* Update server_test.go
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Update http.go
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
---------
Co-authored-by: Erik Dubbelboer <erik@dubbelboer.com>
* Fix RequestHeader parser (#1808)
When FastHTTP receives a header value suffixed or prefixed with tabs, they should be stripped.
* Remove redundant code
* Add test for header parser including tabs (#1808)
Since our userData slice isn't shrunk when we delete values, it can
still keep pointing to things that have been removed. Set these pointers
to nil so that the key and value can be garbage collected.
Fixes https://github.com/valyala/fasthttp/issues/1812
* Fix possible race condition on request ctx done #1662
* Fix possible race condition on request ctx done #1662
* Fix Comment
* fix remove the use of lock
* fix remove Comment
1. Reduce RequestHeader from 368 bytes to 360 bytes
2. Reduce Request from 816 bytes to 800 bytes
3. Reduce Response from 432 bytes to 416 bytes
4. Reduce Client from 312 bytes to 288 bytes
5. Reduce HostClient from 416 bytes to 392 bytes
6. Reduce PipelineClient from 176 bytes to 168 bytes
7. Reduce pipelineConnClient from 216 bytes to 208 bytes
8. Reduce Cookie from 232 bytes to 224 bytes
9. Reduce FS from 184 bytes to 160 bytes
10. Reduce fsHandler from 168 bytes to 160 bytes
11. Reduce ResponseHeader from 328 bytes to 320 bytes
12. Reduce headerScanner from 128 bytes to 120 bytes
13. Reduce TCPDialer from 104 bytes to 96 bytes
14. Reduce workerPool from 152 btyes to 144 btyes
Kashiwa
Kirill
dependabot[bot]
Sigmund Xia 夏天睿
newacorn
Erik Dubbelboer
NikoMalik
Juan Calderon-Perez
byte0o
Sniper91