修改后的get_input_body不能正确获取到post上传的文本信息 about hi-nginx HOT 44 CLOSED

我想第一个do已经到尾部了。第二个do应该没作用。
建议你第一个do里单独标记cl首部，以便在第二个do里走循环。

from hi-nginx.

哦，感谢感谢！

from hi-nginx.

好像还是不行。
wire_shark抓包如下（上传的readme.md是hi-nginx的readmemd）：

代码日志显示在这个if (r->request_body == NULL || r->request_body->bufs == NULL)中判断成功了。然后函数返回了。

修改后的代码如下：

ngx_str_t http_get_input_body(ngx_http_request_t *r)
{
size_t len;
size_t total = 0;
size_t pos = 0;
ngx_buf_t *buf;
ngx_chain_t *cl;
ngx_chain_t *clcpy;
ngx_str_t body = ngx_null_string;

if (r->request_body == NULL || r->request_body->bufs == NULL)
{
	ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "[%d][%s]request body is NULL", __LINE__, __FUNCTION__);
	return body;
}

clcpy = cl = r->request_body->bufs;

do { /** 本while循环用来确定申请的buf的长度 */
	buf = cl->buf;
	total += buf->last - buf->pos;
	//body.append((const char *)buf->pos, len);
	cl = cl->next;
} while (cl);
ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "[%d][BODY] data length = [%zu]", __LINE__, total);

body.data = ngx_palloc(r->pool, sizeof(char)*(total + 1));
if( NULL == body.data ){
	return body;
}
body.data[total]	= 0;

do {
	buf = clcpy->buf;
	len = buf->last - buf->pos;
	//body.append((const char *)buf->pos, len);
	memcpy( body.data + pos, buf->pos, len);
	pos += len;
	//ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "[BODY] data = [%s]", len, (const char *)buf->pos);
	clcpy = clcpy->next;
} while (clcpy);
	
if (r->request_body->temp_file){
	/*
	file_mmap fm;
	auto ret = fm.get((char *)r->request_body->temp_file->file.name.data);
	body.append(ret.first, ret.second.st_size);
	*/
	ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "[BODY] temp_file = [%s]", 
						r->request_body->temp_file->file.name.len, (const char *)(char *)r->request_body->temp_file->file.name.data);
}

ngx_log_error(NGX_LOG_ERR, r->connection->log, 0, "[%d][%s]request body is NULL[%*s]", __LINE__, __FUNCTION__, body.len, body.data);
return body;

}

from hi-nginx.

if (r->request_body == NULL || r->request_body->bufs == NULL)
这段导致提前返回的话，说明NGINX没有接收到啊

from hi-nginx.

wire_shark抓包确实抓到了。而且http返回也正常。 如果nginx其他模块（如: nginx_upload_module）处理之后会清空r->request_body这个指针吗？

from hi-nginx.

hi-nginx 不知道nginx_upload_module是怎么处理上传的。如果你要开发一个PERL模块。可以不必使用nginx_upload_module来处理上传。

from hi-nginx.

嗯，是在 set_output_headers_body_init中实现的，我的用c重写了除了hi::upload函数之外的所有函数(目前还没找到合适的MPFDparser)。从代码逻辑上说body获取的buf为空的话, 那么 upload函数也就是不会保存任何文件以。您可以在您的demo以及get_input_body函数里打日志， 用我这个perl脚本试试。 看body能不能拿到上传的文件内容。
我的nginx配置中：

#file upload文件大小限制，默认1m
client_max_body_size     	50m;
client_body_buffer_size		60m;

日志打印出来的content_length_n与wire_shark获取到的长度也是相同的。

from hi-nginx.

hi-NGINX支持混编c和c++源代码。原则上不需要替换C++源代码，直接混用，利用已有C++代码比较好。

from hi-nginx.

我自己用C重造轮子，搞一个路由模块。so加载方式api等都与您现在的不一样了。但是核心的nginx相关处理都还是用hi-nginx的，所以不是简单的替换，是原样的模仿。
不仅支持so加载；而且编译的时候可以注册函数并直接编译进nginx中。第二种省去了so的加载，计划做内置模块使用。
目前主要问题就是body获取的问题。 MPFDparser这个东西后面计划引入gmime或者其他的mime来搞。

这是我的一个例子的c文件（efsw我也重写了, 同时加入了一些自己的东西，方便后面做自动重启）：

#include <assert.h>
#include <string.h>
#include <errno.h>
#include <cjson/cJSON.h>
#include <efsw/http_common.h>
#include <efsw/http_export.h>

HTTP_MODULE_URI_EXPORT("/hello")
HTTP_MODULE_AUTHOR_EXPORT("dangyajun")
HTTP_MODULE_PASSWD_EXPORT("123456")
HTTP_MODULE_EMAIL_EXPORT("[email protected]")
HTTP_MODULE_VERSION_EXPORT( "v0.0.1")

cJSON* http_post(struct http_context* ctx, struct http_request* req, struct http_response* resp, int* status){
assert( NULL != ctx && NULL != req && NULL != resp && NULL != status );
if( NULL == ctx || NULL == req || NULL == resp || NULL == status ){
printf("[%s] args check error!\n", FUNCTION );
return NULL;
}
cJSON* json = cJSON_CreateObject();
if( NULL == json ){
*status = 505;
errno = -ENOMEM;
printf("[%s] cJSON_CreateObject error!\n", FUNCTION );
return NULL;
}

cJSON_AddStringToObject(json, "hello", "world[post]");
*status = 200;
return json;

}

from hi-nginx.

我把[URL] https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_req_body.c
中的获取body函数ngx_http_lua_ngx_req_get_body_data也用C重写替换下，拿到的body还是空的。 有没有可能这个版本的nginx在处理上传文件的时候有bug? 我下午计划试试其他（至少两个）nginx版本

https://github.com/webcpp/hi-nginx/releases/tag/release-2.2.7 nginx to 1.23.4
https://github.com/webcpp/hi-nginx/releases/tag/release-2.1.2.4 nginx to v1.19.10

from hi-nginx.

建议你先停掉其他可能影响测试结果的上传插件。比如 nginx_upload_module

from hi-nginx.

嗯， 我把其他插件都禁掉了。 现在在hi-nginx-release-2.1.2.4上实验，结果body依然是空的。
再换一个版本。
依然是空的。

我再重新对齐一下代码以及其功能

from hi-nginx.

再问您一个问题， 代码中有用request_body这个的只有上面贴出来的这个函数有。同时GDB下断点查到的request_body这个成员确实是指向NULL的. 不知道这是什么原因？见图：

from hi-nginx.

你看看临时文件有没有值

from hi-nginx.

没有， 我搜到了一篇文章： https://blog.csdn.net/weixin_39611930/article/details/111848491?spm=1001.2101.3001.6650.1&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-111848491-blog-128603687.235%5Ev39%5Epc_relevant_3m_sort_dl_base2&utm_relevant_index=2

里面说：准备nginx 的变量$request_body 即为http请求的body数据
只有在 location中 有 proxy_pass,fastcgi_pass,scgi_pass命令存在时，$request_body变量才会有
值。
这句话是在不能理解。。我的nginx.conf中没有配置这几项 proxy_pass,fastcgi_pass,scgi_pass

from hi-nginx.

nginx核心本身不会主动读取请求体，这个工作是交给请求处理阶段的模块来做，但是nginx核心提供了ngx_http_read_client_request_body()接口来读取请求体，另外还提供了一个丢弃请求体的接口-ngx_http_discard_request_body()，在请求执行的各个阶段中，任何一个阶段的模块如果对请求体感兴趣或者希望丢掉客户端发过来的请求体，可以分别调用这两个接口来完成。这两个接口是nginx核心提供的处理请求体的标准接口，如果希望配置文件中一些请求体相关的指令（比如client_body_in_file_only，client_body_buffer_size等）能够预期工作，以及能够正常使用nginx内置的一些和请求体相关的变量（比如$request_body和$request_body_file），一般来说所有模块都必须调用这些接口来完成相应操作，如果需要自定义接口来处理请求体，也应尽量兼容nginx默认的行为。

详细见: https://www.jb51.net/article/77230.htm
所以按着这个博客里面的说法， r->request_body == NULL是对的，这一块还需要我们自己进行处理，当然系统提供了一个对应的API。 如果你在你的测试例子中可以成功上传文件并且在get_input_body中拿到的string，我觉得大概率也是为空的，不知道这么说跟你实际碰到的一样不？
当然如果你的跟我的不一样我也不知道为啥了，但是如果get_input_body中拿到的string是空的，这一块就是因为缺失了ngx_http_read_client_request_body()函数的调用。您觉得呢？

from hi-nginx.

老版本(HEAD detached at hi-nginx release-2.0.3.3)的hi::nginx确实有调用这个函数。而新版本没有
ngx_http_hi_module.cpp:728: ngx_int_t rc = ngx_http_read_client_request_body(r, ngx_http_hi_body_handler);

from hi-nginx.

可能是我在升级版本重构代码的过程中出于我已经忘了的理由，改变了处理逻辑。搞错了某些东西。

from hi-nginx.

是的。我gdb本地调试模式加了ngx_http_read_client_request_body(r, ngx_http_hi_body_handler)的文件;这一行确实能看到缓存的文件，不过是连mime header都有的文件。 ngx_http_hi_body_handler是一个直接返回的空实现。
您改了之后，我紧跟你的实现。
主要我对nginx一点都不熟悉。
我先把application/x-www-form-urlencoded分支先搞定

from hi-nginx.

应该已经搞定了。你重新拉看看。我这边测试对enctype="multipart/form-data"表单是没问题了。

from hi-nginx.

能看到body了，但是实际获取的内容是被截断的。而且body开始的部分还是带bound等http header的信息。
另外下面几个参数不管怎么改都不能在temp下看到文件。不知道什么原因

r->request_body_in_file_only = 1;
r->request_body_in_persistent_file = 1;
r->request_body_in_clean_file = 1;
r->request_body_file_group_access = 1;
r->request_body_file_log_level = 0;

from hi-nginx.

The following fields of the request determine how the request body is read:

request_body_in_single_buf - Read the body to a single memory buffer.
request_body_in_file_only - Always read the body to a file, even if fits in the memory buffer.
request_body_in_persistent_file - Do not unlink the file immediately after creation. A file with this flag can be moved to another directory.
request_body_in_clean_file - Unlink the file when the request is finalized. This can be useful when a file was supposed to be moved to another directory but was not moved for some reason.
request_body_file_group_access - Enable group access to the file by replacing the default 0600 access mask with 0660.
request_body_file_log_level - Severity level at which to log file errors.
request_body_no_buffering - Read the request body without buffering.
The request_body_no_buffering flag enables the unbuffered mode of reading a request body. In this mode, after calling ngx_http_read_client_request_body(), the bufs chain might keep only a part of the body. To read the next part, call the ngx_http_read_unbuffered_request_body(r) function. The return value NGX_AGAIN and the request flag reading_body indicate that more data is available. If bufs is NULL after calling this function, there is nothing to read at the moment. The request callback read_event_handler will be called when the next part of request body is available.

https://nginx.org/en/docs/dev/development_guide.html

from hi-nginx.

好了，能看到缓存的带有http_header的file了， 另外我觉得get_input_body这个函数有问题。if (r->request_body->temp_file) 这块代码逻辑应该先于对r->request_body->bufs的处理。 因为如果已经缓存成文件就没必要在进行内存拷贝了，直接把temp_file用mmap映射到内存即可。 您觉得呢？
我查了资料下面这些这几个配置在nginx.conf里也可以配置。
r->request_body_in_file_only = 1;
r->request_body_in_persistent_file = 1;
r->request_body_in_clean_file = 1;
r->request_body_file_group_access = 1;
r->request_body_file_log_level = 0;

std::string get_input_body(ngx_http_request_t *r)
{
    size_t len;
    ngx_buf_t *buf;
    ngx_chain_t *cl;
    std::string body;

    if (r->request_body == NULL || r->request_body->bufs == NULL)
    {
        return body;
    }

    cl = r->request_body->bufs;

    do
    {
        buf = cl->buf;
        len = buf->last - buf->pos;
        body.append((const char *)buf->pos, len);
        cl = cl->next;
    } while (cl);

    if (r->request_body->temp_file)
    {
        file_mmap fm;
        auto ret = fm.get((char *)r->request_body->temp_file->file.name.data);
        body.append(ret.first, ret.second.st_size);
    }

    return body;
}

from hi-nginx.

通常上传文件的大小是应该有所限制的。不宜过大。过大文件上传应该使用其他方式。在一个合理的限制内，优先内存存储还是临时文件储存，选择是因人而异的。内存储存性能更好，临时文件用mmap也很快。看个人选择吧。

from hi-nginx.

上面说到的body获取的内容是被截断的这个我知道原因了，ngx_log_error进行日志打印的时候截断了，实际把获取到的内容通过for( size_t i = 0; i < body.len; ++i )printf("%c", ((char*)body.data)[i]);输出的确实是完整的内容。只不过鸡肋的一点就是带有mime的头信息。这个bug应该归咎于ngx_log_error。

from hi-nginx.

你好，您这里有没有单进程单线程的并发数据？我这里测这个修改的性能数据（路由表中就两个节点， 路由单独测试性能100W+/秒），同样简单两个节点，性能只有200+……有点寒酸啊~

from hi-nginx.

怎么测的？测的哪个模块？
这是以前的文档：
https://github.com/webcpp/hi-nginx-tutorial/tree/master/tutorail
里面的内容还是有效的。有以前的压测记录。

from hi-nginx.

等等我单独用我的1.8Ghz的开发板试试。晚点给你回复。

from hi-nginx.

现在的记录：
系统：
16核，016G，LINUX MINT21.2

限制：
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 61944
max locked memory (kbytes, -l) 1999648
max memory size (kbytes, -m) unlimited
open files (-n) 65535
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 61944
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

NGINX配置：
user root;
worker_processes 1;
worker_connections 65535;
access_log off;
error_log /dev/null;
autoblacklist off;
location ~ .pdp {
py_load;
py_search_path "/usr/local/nginx/app/python";
py_uri_pattern ".*.pdp$";
py_expires 0m;
}

python模块：
def handler(req,res):
res.set_header('Content-Type', 'text/plain;charset=UTF-8')
res.status = 200
res.content = 'hello world'

wrk压测：
wrk -c30000 -d30s -t16 http://localhost/test.pdp
Running 30s test @ http://localhost/test.pdp
16 threads and 30000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 13.33ms 12.53ms 2.00s 98.32%
Req/Sec 7.76k 7.24k 35.01k 83.31%
2033113 requests in 30.09s, 381.96MB read
Socket errors: connect 1771, read 222, write 0, timeout 1444
Requests/sec: 67578.33
Transfer/sec: 12.70MB

from hi-nginx.

如果开1s的缓存：
py_expires 1s;
那么：
wrk -c30000 -d30s -t16 http://localhost/test.pdp
Running 30s test @ http://localhost/test.pdp
16 threads and 30000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 6.40ms 35.50ms 1.95s 99.80%
Req/Sec 11.68k 6.20k 66.06k 68.29%
5081241 requests in 30.10s, 1.50GB read
Socket errors: connect 1774, read 1271, write 0, timeout 2922
Requests/sec: 168827.02
Transfer/sec: 51.04MB

from hi-nginx.

以上单进程NGINX配置及相关压测，仅供参考。

from hi-nginx.

单独的router的测试。有｛/hello, /helloserver, /api/sys｝这三个。数量增加对性能影响不是线性也不是指数级的，demo的例子单核单线程现在1000W用5.88秒,每秒160W+的性能。如果是正则，用上jit之后应该更快.

我代码发现两个字符串相关的bug, 跟大小端有关。稍等

from hi-nginx.

好了bug修复了，现在出现了好多连接是time_wait的连接。 这样正常吗？
我的所有测试没有缓存。都是经过router调用http请求的方法返回的数据。
QPS还是神奇的低.200多每秒
实在不行我得学学火山图了……尴尬

from hi-nginx.

也许可参考https://zhuanlan.zhihu.com/p/415307243

from hi-nginx.

还有这个https://www.ucloud.cn/yun/40525.html

from hi-nginx.

这样的结果合理吗？ 我知道原因了， 我的测试脚本不断地创建http连接，同时导致了TIME_WAIT连接数很多。 我也用wrk进行测试。单进程在orangepi3B(Rockchip RK3566, 四核 64 位 Cortex-A55 处理器，22nm 先进工艺，主频最高 1.8GHz)上测试单进程单线程的例子。 然后用我的主机测试get请求， 连接保持keepalive。所有的测试都开启了epoll.数据如下图：

这样好像跟您的benchmark还是有点距离，合理否？

另外我把日志禁掉之后突然发现性能还有所下降。。失败率还提高了。top看到的单核CPU有时候也打满了。

下面这个图是我测试我本机本上的demo, 一共4个worker. 我笔记本是物理四核心2.0GHZ的处理器。没失败，但是相比您那边的恐怖上十万差距有点大.测了好几次，基本都在24K+这里飘着。

from hi-nginx.

第一，我是LINUX，你的好像不是。平台差异巨大。
第二，NGINX配置的话，也不一致。
第三，如果做了反响代理的后端服务器，那么吞吐能力自然要低些，毕竟多了一层。这多出来的一层可能有非常大的影响。
第四，你可以在既有环境中做个静态的同内容测试，可以大体了解相关环境的具体上限。这应该是你参考的重点。
第五，如果你用的是你自己开发的PERL模块，那么影响结果的因素会更多。脚本引擎和开发代码都会实质性左右测试结果。
第六，综上来看，我提供的测试数据不宜与你的测试数据做比较。第四点才应该是你参考的重点。

from hi-nginx.

重点是，相比于你之前的服务器架构，采用hi-nginx能否提高性能，加快应用开发并减少维护成本。如果综合以上三者来看，收益并不明显，那么并没有一定要采用hi-nginx的充分理由。

from hi-nginx.

我这边的，
⒈服务端是linux，
⒉wrk用的是wsl下面的wrk(最多8线程). 你看我后面的这几张图都是wrk命令。
⒊没有做任何代理。
⒋没有用perl.全程c语言。无脚本。
⒌又在笔记本又在嵌入式板子上orangepi测试主要我后面计划把这个部署到我多个板子上。
⒍我的需求并不是看齐160k的那个例子。 我参考你的67K的无缓存的，后面我还会我修改的部分继续优化来进行提升。

能否告知下你测试环境的CPU性能数据？ 我的测试环境CPU都是不超过2.0GHZ的。

from hi-nginx.

重点是，相比于你之前的服务器架构，采用hi-nginx能否提高性能，加快应用开发并减少维护成本。如果综合以上三者来看，收益并不明显，那么并没有一定要采用hi-nginx的充分理由。

我对这个不看重的。不是商业化项目，业余爱好。

from hi-nginx.

lscpu数据：
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: GenuineIntel
Model name: 13th Gen Intel(R) Core(TM) i5-1340P
CPU family: 6
Model: 186
Thread(s) per core: 2
Core(s) per socket: 12
Socket(s): 1
Stepping: 2
CPU max MHz: 4600.0000
CPU min MHz: 400.0000
BogoMIPS: 4377.60
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mc
a cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss
ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art
arch_perfmon pebs bts rep_good nopl xtopology nonstop_
tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes6
4 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xt
pr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_
timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefet
ch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced t
pr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase ts
c_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx sm
ap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xget
bv1 xsaves avx_vnni dtherm ida arat pln pts hwp hwp_not
ify hwp_act_window hwp_epp hwp_pkg_req hfi umip pku osp
ke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b
fsrm md_clear serialize arch_lbr ibt flush_l1d arch_ca
pabilities
Virtualization features:
Virtualization: VT-x
Caches (sum of all):
L1d: 448 KiB (12 instances)
L1i: 640 KiB (12 instances)
L2: 9 MiB (6 instances)
L3: 12 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer
sanitization
Spectre v2: Mitigation; Enhanced IBRS, IBPB conditional, RSB fillin
g, PBRSB-eIBRS SW sequence
Srbds: Not affected
Tsx async abort: Not affected

from hi-nginx.

你看看ulimit -a

from hi-nginx.

pc.txt
这是我的笔记本root下的主要数据，仅供参考。

from hi-nginx.

我知道我哪里还有可以优化的地方了。非常感谢！

from hi-nginx.