`net.http.server` or `net.conn` concurrency issues

[xiusin]

Describe the bug

1. In net.http.server at https://github.com/vlang/v/blob/3e5f2541f2578bc147474d7a6aded98f5da867ec/vlib/net/http/server.v#L138, if a single link is used, the request content can be obtained normally. However, when switching between different links multiple times, there is a high probability of encountering the error error parsing request: none. If you sleep for 1 millisecond before this, it can resolve about 98% of the error issues.

2. During stress testing, https://github.com/vlang/v/blob/3e5f2541f2578bc147474d7a6aded98f5da867ec/vlib/net/http/server.v#L68 will hang for a while, and Vweb behaves the same way. This results in a concurrency performance that is 1 to 2 orders of magnitude lower than languages like Go.

Expected Behavior

• parse request content normally
• improve concurrent performance

Current Behavior

Describe info

Reproduction Steps

none

Possible Solution

No response

Additional Information/Context

No response

V version

V 0.3.4 01b2048

Environment details (OS name and version, etc.)

V full version: V 0.3.4 da153aa.01b2048
OS: macos, macOS, 13.3.1, 22E772610a
Processor: 8 cpus, 64bit, little endian, Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz

getwd: /Users/xxx
vexe: /opt/v/v
vexe mtime: 2023-06-09 05:51:33

vroot: OK, value: /opt/v
VMODULES: OK, value: /Users/xxx/.vmodules
VTMP: OK, value: /tmp/v_501

Git version: git version 2.23.0
Git vroot status: weekly.2023.19-137-g01b20485-dirty (6 commit(s) behind V master)
.git/config present: true

CC version: Apple clang version 14.0.0 (clang-1400.0.29.202)
thirdparty/tcc status: thirdparty-macos-amd64 46662e20-dirty

[medvednikov]

Thanks for the report!

Why close it?

[xiusin]

Thanks for the report!

Why close it?

I see no one paying attention to this issue, so I'm closing it for now.

If needed or confirmed the problem. I can open it again, I'm a bit obsessive-compulsive and will keep an eye on this if no one responds. 😂

[JalonSolov]

People don't always respond immediately. However, if it's closed, they are unlikely to respond at all (unless they are watching these notifications...).

[xiusin]

@JalonSolov Actually, you can add a question tag, such as "TBD" (To Be Determined). I closed the question because I wasn't quite sure if the first issue was caused by my own mistake or an issue with the library, and the second issue was based on certain load testing data. （from GPT, my English is not very good.）

[xiusin]

The testing code for the second issues is as follows:

module main

import vweb

struct VApp {
    vweb.Context
}

pub fn (mut app VApp) hello_api() vweb.Result {
    return app.text('hello world')
}

fn main() {
    vweb.run(&VApp{}, 8081)
}

crystal:

# A very basic HTTP server
require "http/server"

server = HTTP::Server.new do |context|
  context.response.content_type = "text/plain"
  context.response.print "Hello world!"
end

puts "Listening on http://127.0.0.1:8080"
server.listen(8080)

[Casper64]

The error error parsing request: none also occurs when not using any channels or workers and using some benchmarking software, so this issue is deeper than vweb. I think it might have something to do with the socket not being ready for read operations

[Casper64]

@xiusin when I use another benchmarking software like https://github.com/americanexpress/baton the error parsing request: none dissapears! Can you confirm this? Still not sure what could cause this...

[xiusin]

@Casper64 This error error parsing request: none is not caused by benchmarking, but occurs even with normal link switching. Currently, I am not sure if it is due to my usage, but I have to sleep for one millisecond in order to use it myself. The difference between Vweb and net.http.server is basically the same, and I can't figure out what is causing it.

[Casper64]

I have not been able to reproduce the bug every time. I believe most of the concurrency issues of vweb and http.server are related, but I've been unable to find it yet.

I'll give an update when I made some progress.

[xiusin]

As shown in the picture, the response will be interrupted during the pressure test, both for vweb and net.http.server.