```socket = new DatagramSocket(12345); byte[] buff...
# troubleshooting
u
Copy code
socket = new DatagramSocket(12345);
byte[] buffer = new byte[1024];
DatagramPacket packet = new DatagramPacket(buffer, buffer.length);
Hi, I am currently concerned about the throughput of flink. I use flink socket stream. The current limit throughput of a single machine is 500,000 per second. I observe the CPU and memory of my machine, and their load is not high, so how to In order to improve the throughput of socket stream, where can I get the answer, thank you
m
There is no Flink DatagramSocket, isn't that Java itself?
u
Yes, I wrap my custom java data stream
m
Since it's not directly a Flink implementation, I don't think we can help much with that
u
The same is if I use the socketTextStream that comes with flink
one task get udp packet, one task parse the packet, and the last task to do some windows function.
I tried many methods, such as increasing the degree of parallelism, etc., but the cpu seems to have not been running at full capacity, and the throughput does not know how to improve
m
Your source has a parallelism of 1
u
the source monitoring port 9999 obtains data, and the system prompts that this task cannot be parallelized
m
So there's the reason why you can't generate more data: it's a problem of your source
u
then for socketTextStream this will be a bottleneck ?
I have done a lot of experiments. If simply receive data without processing it, you can receive 1 million data packets using java, so I think receiving is not a bottleneck, and the subsequent processing should be improved.
m
It’s a comparison of apples vs oranges
You’re comparing a non-Flink source with a Java implementation
u
yes
m
But the feature set of both is completely different, so you can’t expect the same results.
u
Then wouldn't there be a better result?
m
Why?
u
for the Source task limited throughput
m
You’re running a flat map after a rebalance and a tumbling window after your source. The CPU and memory are not high. The metrics don’t show backpressure. From all indicators, your source isn’t generating enough data to produce more output.
u
this is the second task backpressure metric
this is the third task
this is the first task
m
Yep, the tumbling window is capturing its data according to your config. Most likely that means that it’s waiting for the window to close so it can work on the next set of data
u
is that mean waiting for the window to close cause a lot of data to be unprocessable?
m
Not unprocessable, but it’s basically waiting for the window to close before it can continue when a next window starts
u
then how to improve the job ?