Closed hiqsociety closed 2 years ago
To figure out what happen you may try to fire a single http request and check out the logs from both sides(client&server). Sorry for the tentative suggestion, maybe paste your server demo will help us reproduce the problem.
try with wrk -t 1 -d 10 -c 100 http://127.0.0.1:8888/ error as mentioned
using golang 1.18.1 compiled with go build -ldflags "-w -s" main.go
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package main
import (
"context"
"fmt"
"github.com/cloudwego/hertz/pkg/app"
"github.com/cloudwego/hertz/pkg/app/server"
"github.com/cloudwego/hertz/pkg/common/utils"
"github.com/cloudwego/hertz/pkg/protocol/consts"
)
type Test struct {
A string
B string
}
func main() {
h := server.Default()
h.GET("/", func(c context.Context, ctx *app.RequestContext) {
fmt.Fprintf(ctx, "Hello, World!\n")
//ctx.Redirect(consts.StatusMovedPermanently, []byte("http://www.google.com/"))
})
//h.StaticFS("/", &app.FS{Root: "./", GenerateIndexPages: true})
h.GET("/ping", func(c context.Context, ctx *app.RequestContext) {
ctx.JSON(consts.StatusOK, utils.H{"ping": "pong"})
})
h.GET("/json", func(c context.Context, ctx *app.RequestContext) {
ctx.JSON(consts.StatusOK, &Test{
A: "aaa",
B: "bbb",
})
})
h.GET("/redirect", func(c context.Context, ctx *app.RequestContext) {
ctx.Redirect(consts.StatusMovedPermanently, []byte("http://www.google.com/"))
})
v1 := h.Group("/v1")
{
v1.GET("/hello/:name", func(c context.Context, ctx *app.RequestContext) {
fmt.Fprintf(ctx, "Hi %s, this is the response from Hertz.\n", ctx.Param("name"))
})
}
h.Spin()
}
Got it! Thanks for your report. We will check on this.
I will remove the bug label here, coz the root cause behind this error is that wrk close connection rudely by just reset the connection. More info you could find here: https://github.com/wg/wrk/issues/360.
At this moment netpoll (the default network impl under hertz) will print this connection reset error directly. We will take a deep look at it and discuss a final solution for this kind of situation. For now you can just ignore the error here.
Thanks again for the report!
cc @Hchenn @joway
it's not professional to say to ignore this. apache bench and wrk cannot show any results. in any case, this http stress testing doesnt work. any work arounds to stress test hertz now? doesnt make sense at all as i have tested so many that works.
Sorry, I forgot about the ab.
The reason that ab -n 100 -c 100 http://127.0.0.1:8888/
didn't return is that hertz does not close the connection after processing a non-keepalived request. I'll fix it, and for now you may add the -k
flag to work around with it.
If it's still not working, pls let me know.
Now you can use ab to benchmark Hertz with short connection.
possible to show us how to test with wrk or apache bench? coz cant test against fasthttp etc. got this as response
ab -n 100 -c 100 http://127.0.0.1:8888/ This is ApacheBench, Version 2.3 <$Revision: 1843412 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)...apr_pollset_poll: The timeout specified has expired (70007)