Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: [tlug] Re: [RFC] Outline of the fast HTTP talk (PHP benchmark)
- Date: Thu, 6 Nov 2008 09:44:33 +0900
- From: Curt Sampson <cjs@example.com>
- Subject: Re: [tlug] Re: [RFC] Outline of the fast HTTP talk (PHP benchmark)
- References: <87fxm9tfx7.fsf-genuine-vii@john.fremlin.org> <200811050006.06239.fcartegnie@free.fr> <20081104235613.GB9096@pragmatic.cynic.net> <200811051743.18977.fcartegnie@free.fr>
- User-agent: Mutt/1.5.17 (2007-11-01)
On 2008-11-05 17:43 +0100 (Wed), Francois Cartegnie wrote: > There's the cpu affinity, which sets wich process runs on which cpu (the > dynamic you mention)... To be more precise, in the world of operating systems and multiprocessing outside of Linux "CPU affinity" refers to the scheduler preferring to schedule a process's next quantum to run on the same CPU as the previous one, in order to take advantage of any residual cached information in that CPU from the previous quantum. To use it otherwise is a confusing misuse of the term. [Insert rant about Linux folks changing common terminology here.] > ...but he uses the affinity tool function that changes the process > scheduler SCHED_FIFO (realtime) for the lighttpd process. Such > a process runs until it releases the cpu by itself, and is only > interruptible by a process of a higher priority. Right. That's no longer affinity, and would probably best be called "changing how the process is scheduled." (Note that the "run until it blocks" behaviour has nothing to do with affinity, and can just as well be done on a single-processor system.) > So I think lighty is just doing sequencial processing of requests (as their > process are with same prio, so all exclusive) and no more paralellism in > processing is possible. Actually, one can gain more parallelism in two ways: 1. Have multiple lighttpd worker threads (or is it processes? I can't remember off-hand) that can run in parallel. 2. Distribute some of the request processing to other processes (running on the same or different hosts) via FastCGI. cjs -- Curt Sampson <cjs@example.com> +81 90 7737 2974 Mobile sites and software consulting: http://www.starling-software.com
- Follow-Ups:
- Re: [tlug] Re: [RFC] Outline of the fast HTTP talk (PHP benchmark)
- From: Stephen J. Turnbull
- References:
- [tlug] [RFC] Outline of the fast HTTP talk
- From: John Fremlin
- Re: [tlug] Re: [RFC] Outline of the fast HTTP talk (PHP benchmark)
- From: Francois Cartegnie
- Re: [tlug] Re: [RFC] Outline of the fast HTTP talk (PHP benchmark)
- From: Curt Sampson
- Re: [tlug] Re: [RFC] Outline of the fast HTTP talk (PHP benchmark)
- From: Francois Cartegnie
Home | Main Index | Thread Index
- Prev by Date: Re: [tlug] Re: [RFC] Outline of the fast HTTP talk (PHP benchmark)
- Next by Date: Re: [tlug] Fast HTTP Talk, Httperf and Libevent, Pre-talk Hacking Session
- Previous by thread: Re: [tlug] Re: [RFC] Outline of the fast HTTP talk (PHP benchmark)
- Next by thread: Re: [tlug] Re: [RFC] Outline of the fast HTTP talk (PHP benchmark)
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links