How to test multi-pollset?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

How to test multi-pollset?

pablo platt-3
Hi,

What is the expected effect of the multi-pollset PR [1] on a UDP socket on the sender/receiver side?
My use case is a media server with several broadcaster and many viewers.
Each stream use 1Mbps (aprox 100 * 1500 bytes packets per second).
Should I expect improvement when gen_udp is sending packets, receiving packets or both?

Is it reasonable to pick a point in master and use it on a production system after testing?

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: How to test multi-pollset?

Lukas Larsson-8
Hello,

On Mon, Jan 29, 2018 at 9:22 AM, pablo platt <[hidden email]> wrote:
Hi,

What is the expected effect of the multi-pollset PR [1] on a UDP socket on the sender/receiver side?
My use case is a media server with several broadcaster and many viewers.
Each stream use 1Mbps (aprox 100 * 1500 bytes packets per second).
Should I expect improvement when gen_udp is sending packets, receiving packets or both?

Yes, I believe that you will see an improvement. It depends on what type of HW that you are running on, typically the more logical cpu's you have the more gain you will get from the improvements in I/O polling[1]. Also the exact usage pattern matters.
 
Is it reasonable to pick a point in master and use it on a production system after testing?

I would take the latest tip of master and test that thoroughly for you application. The things that we merge into master have gone through all our testing before it is merged, so it is as stable as the maint branch. However we make a lot more changes in master than in maint, so because of that there will be a greater chance of some bug slipping through.

If you do decide to give the improved I/O polling implementation a go, please do come back with any negative or positive findings that you get!

Lukas

[1]: The largest change in the PR is not actually the ability to use multiple pollsets, but that the polling has been lifted out to be done by dedicated threads.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: How to test multi-pollset?

pablo platt-3
It's great to see all the hard work invested in performance in master.
Thanks.

On Mon, Jan 29, 2018 at 10:49 AM, Lukas Larsson <[hidden email]> wrote:
Hello,

On Mon, Jan 29, 2018 at 9:22 AM, pablo platt <[hidden email]> wrote:
Hi,

What is the expected effect of the multi-pollset PR [1] on a UDP socket on the sender/receiver side?
My use case is a media server with several broadcaster and many viewers.
Each stream use 1Mbps (aprox 100 * 1500 bytes packets per second).
Should I expect improvement when gen_udp is sending packets, receiving packets or both?

Yes, I believe that you will see an improvement. It depends on what type of HW that you are running on, typically the more logical cpu's you have the more gain you will get from the improvements in I/O polling[1]. Also the exact usage pattern matters.
 
Is it reasonable to pick a point in master and use it on a production system after testing?

I would take the latest tip of master and test that thoroughly for you application. The things that we merge into master have gone through all our testing before it is merged, so it is as stable as the maint branch. However we make a lot more changes in master than in maint, so because of that there will be a greater chance of some bug slipping through.

If you do decide to give the improved I/O polling implementation a go, please do come back with any negative or positive findings that you get!

Lukas

[1]: The largest change in the PR is not actually the ability to use multiple pollsets, but that the polling has been lifted out to be done by dedicated threads.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions