Rainbows! Rack HTTP server user/dev discussion
 help / color / Atom feed
* algoritim schedule from linux nptl
@ 2011-06-09 14:42 Alexandre Riveira
  0 siblings, 0 replies; 3+ messages in thread
From: Alexandre Riveira @ 2011-06-09 14:42 UTC (permalink / raw)
  To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: algoritim schedule from linux nptl
       [not found] ` <4DF03E63.2030707-VwDbj2YsoUp0ZRtCdD4y8VAUjnlXr6A1@public.gmane.org>
@ 2011-06-09  6:52   ` Eric Wong
  0 siblings, 0 replies; 3+ messages in thread
From: Eric Wong @ 2011-06-09  6:52 UTC (permalink / raw)
  To: Rainbows! list

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* algoritim schedule from linux nptl
@ 2011-06-09  3:30 Alexandre Riveira
       [not found] ` <4DF03E63.2030707-VwDbj2YsoUp0ZRtCdD4y8VAUjnlXr6A1@public.gmane.org>
  0 siblings, 1 reply; 3+ messages in thread
From: Alexandre Riveira @ 2011-06-09  3:30 UTC (permalink / raw)
  To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-09 14:42 algoritim schedule from linux nptl Alexandre Riveira
  -- strict thread matches above, loose matches on Subject: below --
2011-06-09  3:30 Alexandre Riveira
     [not found] ` <4DF03E63.2030707-VwDbj2YsoUp0ZRtCdD4y8VAUjnlXr6A1@public.gmane.org>
2011-06-09  6:52   ` Eric Wong

Rainbows! Rack HTTP server user/dev discussion

Archives are clonable:
	git clone --mirror http://bogomips.org/rainbows-public
	git clone --mirror http://ou63pmih66umazou.onion/rainbows-public

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.lang.ruby.rainbows
	nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.rainbows

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git