On Wed, 27 Jul 2005, Paul Smith wrote: >At 03:21 27/07/2005, Mrs. Brisby wrote: >>On Mon, 2005-07-25 at 09:48 -0500, Jay Sprenkle wrote: >> > The theory has been proposed that threads aren't better than separate >> > processes, or application implemented context switching. Does anyone >> > have an experiment that will prove the point either way? It will have >> > to be OS specific though, since I'm sure not all thread >> > implementations are equal. > >This page might be interesting.. http://john.redmood.com/osfastest.html
This whole article is pretty flawed. The performance of creating and deleting files between the different systems can be explained by the relative safety of the different systems. FreeBSD and Solaris both order metadata writes to minimize FS damage on OS or power failure. Ext2 under Linux is well known for foregoing these safe guards by default. Using a journalled filesystem (Solaris 7+ has journalled UFS, ext3 on Linux) or soft-updates on FreeBSD should probably level this playing field. Don't know about Windows, though. > >It shows (pretty conclusively), that 'one process per task' is not the way >to go if you want any sort of performance. One process per request, from the article. That's HTTP 1.0. Most systems don't handle one request then exit, especially database systems. Oracle, PostgreSQL and probably others have a process per session, using shared memory and IPC for synchronisation, and scale very nicely thank you. The other problem with the test is that the example is not very representitive of real work. Simply writing a "405 - too busy" to a request does not constitute actual work, and as soon as the single threaded, async implementation does any work in that thread, "throughput" will go down and latency will increase. On the other hand, the threaded implementation should maintain throughput even if requests result in blocking, or the machine has more than 1 CPU and the threads can operate concurrently. Of course, I'm advocating neither one method or another, it's all a bit grey, and can see both sides of the argument. It would be nice if SQLite played nicer with threads, but it doesn't at the moment. > >One thread per task is very good >One thread for many tasks is slightly better, with the benefit growing as >more threads are created (up to 300-500 tasks there's not a massive >difference, by the time you get to 1000 tasks there's a 35% benefit to >using one thread for many tasks. For real work, the drop off of scalability in the threaded instance would probably not be as great, as the given test represents about the worst case for threads (little concurrency, IO bound, context thrashing) > >Of course, this assumes a well designed architecture... The test was far from it... > >But, one process per task is very poor in comparison to the other ways (on >all the platforms they tested) handling only about 5% of load of the 'one >thread for many tasks' architecture. > As I said above, the test from the article is loaded against process per task architectures by the HTTP 1.0 nature of the task. The numbers will not be representitive of real situations. Perhaps a better test would be to use the different MPMs of Apache against each other: http://httpd.apache.org/docs/2.0/mpm.html There is no MPM for single thread, async IO, presumably because async IO is not an option once you start using third-party plugins. My 2c Christian -- /"\ \ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \
