[erlang-questions] Improve performance of IO bounded server written in Erlang via having pollset for each scheduler and bind port to scheduler together with process

[Hynek Vychodil]

On Wed, Jul 11, 2012 at 10:35 PM, Ronny Meeus <ronny.meeus@REDACTED> wrote:
>
> On Wed, Jul 11, 2012 at 9:12 PM, Zabrane Mickael <zabrane3@REDACTED>
> wrote:
> > Hi Wei,
> >
> > On Jul 11, 2012, at 2:35 PM, Wei Cao wrote:
> >
> > sure, the steps is correct
> >
> >
> > I re-installed everything from scratch with your second patch and tested
> > your ehttpd web server example.
> >
> > before: ~55K rps
> > after: ~70K rps
> >
> > but was unable to reach the 100K rps.
> >
> > Anyone courageous enough to help us reach the 100K rps?
> >
> > Regards,
> > Zabrane
> >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
>
> I think the feature that certain processes can be bound to a certain
> CPU at application level would also be useful.
> The solution implemented here only works (if I understand it well)
> when a process is using socket communication.
>
> There are scenarios where tasks are using just a little load (for
> example short processing of a message) where the overhead introduced
> by the scheduler is large so that nothing is gained by switching to a
> multi-core processor (in fact single core runs much faster).
> If certain the processes can be grouped on application level and bound
> to specific cores, the application scales a lot better.
> The other solution would be to run a separate VM instance per core but
> I have the feeling that this is more complex to manage and that there
> is also more overhead if messages need to be sent between the
> applications running on different VMs.
>

You can bind process to specific core in Erlang. First you have to
bind schedulers to cores using +sbt emulator option (I'm using default
binding +sbt db) and than you can bind process to specific scheduler
using spawn option {scheduler, N} when N is id of scheduler starting
from 1 (0 binds to same scheduler may be - it is not documented what I
could be able find). You can also get current scheduler id using
erlang:system_info(scheduler_id).

[spawn_opt(fun() -> io:format("~p -> Scheduler: ~p~n", [X,
erlang:system_info(scheduler_id)]) end, [{scheduler, X}])
|| X <- lists:seq(1,erlang:system_info(schedulers))].

> This is a "taskset" like primitive that we know it from the Linux thread
> world.
> For example in thread "Strange observation running in an SMP
> environment." in this mailing list this would certainly be beneficial.
>
> Best regards,
> Ronny
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions