- android - RelativeLayout 背景可绘制重叠内容
- android - 如何链接 cpufeatures lib 以获取 native android 库?
- java - OnItemClickListener 不起作用,但 OnLongItemClickListener 在自定义 ListView 中起作用
- java - Android 文件转字符串
我一直在分析 TCP 延迟(特别是从用户空间到内核空间的小消息的 write
),以便对 write
(承认这可能是特定于上下文的)。我注意到在我看来很相似的测试之间存在很大的不一致,我很想知道差异从何而来。我知道微基准测试可能会有问题,但我仍然觉得我缺少一些基本的理解(因为延迟差异约为 10 倍)。
设置是我有一个 C++ TCP 服务器接受一个客户端连接(来自同一 CPU 上的另一个进程),并在与客户端连接后进行 20 次系统调用以
写入
到套接字,一次发送一个字节。服务器的完整代码在本文末尾复制。这是使用 boost/timer
对每个 write
进行计时的输出(这增加了约 1 个麦克风的噪音):
$ clang++ -std=c++11 -stdlib=libc++ tcpServerStove.cpp -O3; ./a.out
18 mics
3 mics
3 mics
4 mics
3 mics
3 mics
4 mics
3 mics
5 mics
3 mics
...
我可靠地发现第一个 write
比其他的要慢得多。如果我将 10,000 个 write
调用包装在一个计时器中,平均每次 write
需要 2 微秒,但第一个调用总是超过 15 个麦克风。为什么会出现这种“升温”现象?
相关地,我进行了一个实验,在每个 write
调用之间,我做了一些阻塞 CPU 的工作(计算一个大质数)。这会导致所有 write
调用变慢:
$ clang++ -std=c++11 -stdlib=libc++ tcpServerStove.cpp -O3; ./a.out
20 mics
23 mics
23 mics
30 mics
23 mics
21 mics
21 mics
22 mics
22 mics
...
鉴于这些结果,我想知道在将字节从用户缓冲区复制到内核缓冲区的过程中是否发生了某种批处理。如果多个 write
调用快速连续发生,它们是否会合并为一个内核中断?
特别是我正在寻找关于write
将缓冲区从用户空间复制到内核空间需要多长时间的一些概念。如果有一些合并效应允许平均 write
在我连续执行 10,000 次时仅占用 2 个麦克风,那么得出 write
延迟为2个麦克风;看来我的直觉应该是每次write
需要20微秒。对于您在没有内核绕过的情况下可以获得的最低延迟(对一个字节的原始 write
调用)来说,这似乎出奇地慢。
最后一个数据是,当我在计算机上的两个进程(一个 TCP 服务器和一个 TCP 客户端)之间设置乒乓测试时,我平均每次往返 6 个麦克风(其中包括一个 read
,写入
,以及通过本地主机网络移动)。这似乎与上面看到的单次写入的 20 个麦克风延迟不一致。
TCP 服务器的完整代码:
// Server side C/C++ program to demonstrate Socket programming
// #include <iostream>
#include <unistd.h>
#include <stdio.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <string.h>
#include <boost/timer.hpp>
#include <unistd.h>
// Set up some blocking work.
bool isPrime(int n) {
if (n < 2) {
return false;
}
for (int i = 2; i < n; i++) {
if (n % i == 0) {
return false;
}
}
return true;
}
// Compute the nth largest prime. Takes ~1 sec for n = 10,000
int getPrime(int n) {
int numPrimes = 0;
int i = 0;
while (true) {
if (isPrime(i)) {
numPrimes++;
if (numPrimes >= n) {
return i;
}
}
i++;
}
}
int main(int argc, char const *argv[])
{
int server_fd, new_socket, valread;
struct sockaddr_in address;
int opt = 1;
int addrlen = sizeof(address);
// Create socket for TCP server
server_fd = socket(AF_INET, SOCK_STREAM, 0);
// Prevent writes from being batched
setsockopt(server_fd, SOL_SOCKET, TCP_NODELAY, &opt, sizeof(opt));
setsockopt(server_fd, SOL_SOCKET, TCP_NOPUSH, &opt, sizeof(opt));
setsockopt(server_fd, SOL_SOCKET, SO_SNDBUF, &opt, sizeof(opt));
setsockopt(server_fd, SOL_SOCKET, SO_SNDLOWAT, &opt, sizeof(opt));
address.sin_family = AF_INET;
address.sin_addr.s_addr = INADDR_ANY;
address.sin_port = htons(8080);
bind(server_fd, (struct sockaddr *)&address, sizeof(address));
listen(server_fd, 3);
// Accept one client connection
new_socket = accept(server_fd, (struct sockaddr *)&address, (socklen_t*)&addrlen);
char sendBuffer[1] = {0};
int primes[20] = {0};
// Make 20 sequential writes to kernel buffer.
for (int i = 0; i < 20; i++) {
sendBuffer[0] = i;
boost::timer t;
write(new_socket, sendBuffer, 1);
printf("%d mics\n", int(1e6 * t.elapsed()));
// For some reason, doing some blocking work between the writes
// The following work slows down the writes by a factor of 10.
// primes[i] = getPrime(10000 + i);
}
// Print a prime to make sure the compiler doesn't optimize
// away the computations.
printf("prime: %d\n", primes[8]);
}
TCP 客户端代码:
// Server side C/C++ program to demonstrate Socket programming
// #include <iostream>
#include <unistd.h>
#include <stdio.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <string.h>
#include <unistd.h>
int main(int argc, char const *argv[])
{
int sock, valread;
struct sockaddr_in address;
int opt = 1;
int addrlen = sizeof(address);
// We'll be passing uint32's back and forth
unsigned char recv_buffer[1024] = {0};
// Create socket for TCP server
sock = socket(AF_INET, SOCK_STREAM, 0);
setsockopt(sock, SOL_SOCKET, TCP_NODELAY, &opt, sizeof(opt));
address.sin_family = AF_INET;
address.sin_addr.s_addr = INADDR_ANY;
address.sin_port = htons(8080);
// Accept one client connection
if (connect(sock, (struct sockaddr *)&address, (socklen_t)addrlen) != 0) {
throw("connect failed");
}
read(sock, buffer_pointer, num_left);
for (int i = 0; i < 10; i++) {
printf("%d\n", recv_buffer[i]);
}
}
我尝试使用和不使用标志 TCP_NODELAY
、TCP_NOPUSH
、SO_SNDBUF
和 SO_SNDLOWAT
,我的想法是这可能会阻止批处理(但我的理解是这种批处理发生在内核缓冲区和网络之间,而不是在用户缓冲区和内核缓冲区之间)。
这是乒乓测试的服务器代码:
// Server side C/C++ program to demonstrate Socket programming
// #include <iostream>
#include <unistd.h>
#include <stdio.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <string.h>
#include <boost/timer.hpp>
#include <unistd.h>
__inline__ uint64_t rdtsc(void)
{
uint32_t lo, hi;
__asm__ __volatile__ (
"xorl %%eax,%%eax \n cpuid"
::: "%rax", "%rbx", "%rcx", "%rdx");
__asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
return (uint64_t)hi << 32 | lo;
}
// Big Endian (network order)
unsigned int fromBytes(unsigned char b[4]) {
return b[3] | b[2]<<8 | b[1]<<16 | b[0]<<24;
}
void toBytes(unsigned int x, unsigned char (&b)[4]) {
b[3] = x;
b[2] = x>>8;
b[1] = x>>16;
b[0] = x>>24;
}
int main(int argc, char const *argv[])
{
int server_fd, new_socket, valread;
struct sockaddr_in address;
int opt = 1;
int addrlen = sizeof(address);
unsigned char recv_buffer[4] = {0};
unsigned char send_buffer[4] = {0};
// Create socket for TCP server
server_fd = socket(AF_INET, SOCK_STREAM, 0);
address.sin_family = AF_INET;
address.sin_addr.s_addr = INADDR_ANY;
address.sin_port = htons(8080);
bind(server_fd, (struct sockaddr *)&address, sizeof(address));
listen(server_fd, 3);
// Accept one client connection
new_socket = accept(server_fd, (struct sockaddr *)&address, (socklen_t*)&addrlen);
printf("Connected with client!\n");
int counter = 0;
unsigned int x = 0;
auto start = rdtsc();
boost::timer t;
int n = 10000;
while (counter < n) {
valread = read(new_socket, recv_buffer, 4);
x = fromBytes(recv_buffer);
toBytes(x+1, send_buffer);
write(new_socket, send_buffer, 4);
++counter;
}
printf("%f clock cycles per round trip (rdtsc)\n", (rdtsc() - start) / double(n));
printf("%f mics per round trip (boost timer)\n", 1e6 * t.elapsed() / n);
}
这是乒乓测试的客户端代码:
// #include <iostream>
#include <unistd.h>
#include <stdio.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <string.h>
#include <boost/timer.hpp>
#include <unistd.h>
// Big Endian (network order)
unsigned int fromBytes(unsigned char b[4]) {
return b[3] | b[2]<<8 | b[1]<<16 | b[0]<<24;
}
void toBytes(unsigned int x, unsigned char (&b)[4]) {
b[3] = x;
b[2] = x>>8;
b[1] = x>>16;
b[0] = x>>24;
}
int main(int argc, char const *argv[])
{
int sock, valread;
struct sockaddr_in address;
int opt = 1;
int addrlen = sizeof(address);
// We'll be passing uint32's back and forth
unsigned char recv_buffer[4] = {0};
unsigned char send_buffer[4] = {0};
// Create socket for TCP server
sock = socket(AF_INET, SOCK_STREAM, 0);
// Set TCP_NODELAY so that writes won't be batched
setsockopt(sock, SOL_SOCKET, TCP_NODELAY, &opt, sizeof(opt));
address.sin_family = AF_INET;
address.sin_addr.s_addr = INADDR_ANY;
address.sin_port = htons(8080);
// Accept one client connection
if (connect(sock, (struct sockaddr *)&address, (socklen_t)addrlen) != 0) {
throw("connect failed");
}
unsigned int lastReceived = 0;
while (true) {
toBytes(++lastReceived, send_buffer);
write(sock, send_buffer, 4);
valread = read(sock, recv_buffer, 4);
lastReceived = fromBytes(recv_buffer);
}
}
最佳答案
(不是一个完整的答案,但需要比评论更多的空间......)
这听起来确实像 Nagle's algorithm ,或其变体,控制何时实际发送 TCP 数据包。
对于第一次写入,当'pipe'中没有未确认的数据时,会立即发送,需要一点时间。对于之后不久的后续写入,管道中仍然会有未确认的数据,因此可以在发送缓冲区中排队少量数据,这样会更快。
传输中断后,当所有发送都有机会 catch 时,管道将准备好立即再次发送。
您可以使用 Wireshark 之类的工具查看实际的 TCP 数据包来确认这一点 - 这将显示 write()
请求是如何组合在一起的。
公平地说,我希望 TCP_NODELAY 标志能够绕过这个 - 正如您所说,导致时间分布更均匀。如果您可以检查 TCP 数据包,还值得查看它们是否显示 PSH 标志集,以强制立即发送。
关于c - 为什么交错工作时 TCP 写入延迟更糟?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/52153265/
我是一名优秀的程序员,十分优秀!