algoritim schedule from linux nptl

algoritim schedule from linux nptl

[Alexandre Riveira]

I thank all the initiatives proposed by Rainbows she is really 
extraordinary!

My company works with ERP (Enterprise Resource Planning) and this leads 
to generate large reports.

As a matter of contract a customer of ours can have only one worker / 
multi threaded server.

In such cases, when a large report is generated using 100% of processing 
other requests are waiting in cases of multiple simultaneous requests 
however small the simultaneity is normal

Got a decrease in time using a kernel with ck patch (https: / / 
wiki.archlinux.org/index.php/Kernel26-ck) in the order of 12 seconds 
down to 3 seconds but this is not ideal.

Does anyone know how the schedule works in linux and that you can adjust 
the schedule of linux?


Alexandre Riveira
Object Data
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: algoritim schedule from linux nptl

[Eric Wong]

Alexandre Riveira <alexandre-VwDbj2YsoUp0ZRtCdD4y8VAUjnlXr6A1@public.gmane.org> wrote:
> As a matter of contract a customer of ours can have only one worker
> / multi threaded server.

That sucks.  Rainbows! works best with multiple worker processes
for CPU/memory-bound concurrency (as long as you have enough
memory/cores).

> In such cases, when a large report is generated using 100% of
> processing other requests are waiting in cases of multiple
> simultaneous requests however small the simultaneity is normal
> 
> Got a decrease in time using a kernel with ck patch (https: / /
> wiki.archlinux.org/index.php/Kernel26-ck) in the order of 12 seconds
> down to 3 seconds but this is not ideal.

How fast is the large report generation if there's only one simultaneous
request?  That's the fastest it'll ever be unless you optimize
the report generation code itself (and not the scheduling/concurrency).

> Does anyone know how the schedule works in linux and that you can
> adjust the schedule of linux?

Matz Ruby 1.9 is entirely at the mercy of Linux scheduler (a good
thing IMHO).

Unless your report generator is written to release the GVL (in C), you
won't get any CPU-bound concurrency with Ruby 1.9 threads.  Fortunately
the API for releasing the GVL is pretty good (even if most of the
documentation means reading thread.c comments in the Ruby source.

-- 
Eric Wong
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

algoritim schedule from linux nptl

[Alexandre Riveira]

Hi Eric !
When  I  referred  to  has decreased  from 12 to 3  seconds there  was  the  report  itself,
but  the other  requests  made ​​at  the same  time the  report is  generated


Tanks Alexandre Riveira


In such cases, when a large report is generated using 100% of processing
other requests are waiting in cases of multiple simultaneous requests
however small the simultaneity is normal


Got a decrease in time using a kernel with ck patch (https: / /
wiki.archlinux.org/index.php/Kernel26-ck) in the order of 12 seconds
down to 3 seconds but this is not ideal.

----------------------------------------


How fast is the large report generation if there's only one simultaneous
request?  That's the fastest it'll ever be unless you optimize
the report generation code itself (and not the scheduling/concurrency).

_______________________________________________
Rainbows! mailing list - rainbows-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying