Comments on: Threads, Processes, Rails, TurboGears, and Scalability http://compoundthinking.com/blog/index.php/2008/05/14/threads-processes-rails-trubogears-and-scalability/ Thinking about programming in new ways Wed, 28 Jul 2010 19:00:53 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Recent Links Tagged With "stackless" - JabberTags http://compoundthinking.com/blog/index.php/2008/05/14/threads-processes-rails-trubogears-and-scalability/#comment-304424 Recent Links Tagged With "stackless" - JabberTags Tue, 06 Jan 2009 08:04:44 +0000 http://compoundthinking.com/blog/?p=306#comment-304424 [...] public links >> stackless Mark Ramm: Threads, Processes, Rails, TruboGears, and Scalability Saved by rationalpi on Tue 23-12-2008 What I’ve listened to this week, 29-Mar-2008 Saved by [...] [...] public links >> stackless Mark Ramm: Threads, Processes, Rails, TruboGears, and Scalability Saved by rationalpi on Tue 23-12-2008 What I’ve listened to this week, 29-Mar-2008 Saved by [...]

]]> By: Mark Ramm http://compoundthinking.com/blog/index.php/2008/05/14/threads-processes-rails-trubogears-and-scalability/#comment-253812 Mark Ramm Thu, 23 Oct 2008 16:23:55 +0000 http://compoundthinking.com/blog/?p=306#comment-253812 Roger, I'm very excited to hear that. Though I'm a bit skeptical that all of the thread-safety issues in Rails will be worked out in time for 2.2. That kind of thing is hard to bolt onto a framework after the fact. You need to have thought through the issues up-front and come up with a sane way to handle threads, or you end up in a nightmare scenario of mutexes, race conditions, and very hard to reproduce bugs. Roger,

I’m very excited to hear that. Though I’m a bit skeptical that all of the thread-safety issues in Rails will be worked out in time for 2.2. That kind of thing is hard to bolt onto a framework after the fact. You need to have thought through the issues up-front and come up with a sane way to handle threads, or you end up in a nightmare scenario of mutexes, race conditions, and very hard to reproduce bugs.

]]> By: roger http://compoundthinking.com/blog/index.php/2008/05/14/threads-processes-rails-trubogears-and-scalability/#comment-253222 roger Wed, 22 Oct 2008 17:42:15 +0000 http://compoundthinking.com/blog/?p=306#comment-253222 Note that rails 2.2 will be threadsafe, so the JRuby guys will be able to share memory across threads more easily and have concurrency across all available cores. http://blog.headius.com/2008/08/qa-what-thread-safe-rails-means.html -=R Note that rails 2.2 will be threadsafe, so the JRuby guys will be able to share memory across threads more easily and have concurrency across all available cores.
http://blog.headius.com/2008/08/qa-what-thread-safe-rails-means.html
-=R

]]> By: mormon http://compoundthinking.com/blog/index.php/2008/05/14/threads-processes-rails-trubogears-and-scalability/#comment-220675 mormon Thu, 07 Aug 2008 05:05:10 +0000 http://compoundthinking.com/blog/?p=306#comment-220675 Nice post. I'm with Lateef up there--wondering if asynchronousness would also help the throughput or not. I know there's been some work in the Ruby world to get asynchronous DB adapters going [http://oldmoe.blogspot.com/ lists some] which will hopefully help with the runtime speed. Maybe this will help. We can only hope. Nice post. I’m with Lateef up there–wondering if asynchronousness would also help the throughput or not. I know there’s been some work in the Ruby world to get asynchronous DB adapters going [http://oldmoe.blogspot.com/ lists some] which will hopefully help with the runtime speed. Maybe this will help. We can only hope.

]]> By: Humanist → Scalable Web Apps: Erlang + Python http://compoundthinking.com/blog/index.php/2008/05/14/threads-processes-rails-trubogears-and-scalability/#comment-214494 Humanist → Scalable Web Apps: Erlang + Python Tue, 29 Jul 2008 02:24:35 +0000 http://compoundthinking.com/blog/?p=306#comment-214494 [...] to Django, though I’ve never used it. In a web application setting, it’s easy to have too many Apache/Python processes which max out server memory or the CPU. For those tasks, I like Erlang. Erlang has parallelism and [...] [...] to Django, though I’ve never used it. In a web application setting, it’s easy to have too many Apache/Python processes which max out server memory or the CPU. For those tasks, I like Erlang. Erlang has parallelism and [...]

]]> By: Host TG on IIS at Compound Thinking http://compoundthinking.com/blog/index.php/2008/05/14/threads-processes-rails-trubogears-and-scalability/#comment-211520 Host TG on IIS at Compound Thinking Fri, 25 Jul 2008 04:20:21 +0000 http://compoundthinking.com/blog/?p=306#comment-211520 [...] is so good that they don’t need TurboGears. And TurboGears multi-threaded+multiprocess model works better on windows than many of the other “dynamic language web-frameworks which depend solely on the [...] [...] is so good that they don’t need TurboGears. And TurboGears multi-threaded+multiprocess model works better on windows than many of the other “dynamic language web-frameworks which depend solely on the [...]

]]> By: Mark Ramm http://compoundthinking.com/blog/index.php/2008/05/14/threads-processes-rails-trubogears-and-scalability/#comment-190991 Mark Ramm Sun, 15 Jun 2008 13:58:07 +0000 http://compoundthinking.com/blog/?p=306#comment-190991 Bill, I have moved a heavily multi-process python app from Linux to Window, and we did notice increased latency (due to longer process startup times) and increased memory use. We ended up needing to use a hybrid model, with several multi-threaded processes in order to get reasonable performance out of the windows solution. Some of this could have been ameliorated if we had not been so free with forking off a new process to do some relatively quick job. (We often had started several very short processes which lived 1-2 seconds, did some work and shut down.) The fact that windows does not have copy-on-write semantics for forking means that each of those processes made a full copy of our 150 meg or so environment. On linux we had at most a couple of meg memory increase for the life of the process. I don't think I've tested 2003 server, or anything later than that, so it could be that Microsoft has changed things and current tests would fare better. My intention was not to bash Microsoft, but to point out one limitation, and to mention that the TurboGears model works better in that environment than other frameworks that rely only on multi-processing for concurrency. Bill,

I have moved a heavily multi-process python app from Linux to Window, and we did notice increased latency (due to longer process startup times) and increased memory use. We ended up needing to use a hybrid model, with several multi-threaded processes in order to get reasonable performance out of the windows solution.

Some of this could have been ameliorated if we had not been so free with forking off a new process to do some relatively quick job. (We often had started several very short processes which lived 1-2 seconds, did some work and shut down.)

The fact that windows does not have copy-on-write semantics for forking means that each of those processes made a full copy of our 150 meg or so environment. On linux we had at most a couple of meg memory increase for the life of the process.

I don’t think I’ve tested 2003 server, or anything later than that, so it could be that Microsoft has changed things and current tests would fare better.

My intention was not to bash Microsoft, but to point out one limitation, and to mention that the TurboGears model works better in that environment than other frameworks that rely only on multi-processing for concurrency.

]]> By: Bill English http://compoundthinking.com/blog/index.php/2008/05/14/threads-processes-rails-trubogears-and-scalability/#comment-190834 Bill English Sun, 15 Jun 2008 07:25:22 +0000 http://compoundthinking.com/blog/?p=306#comment-190834 Do you actually have any evidence for your claims about your windows bashing? ... forking a process is more expensive in windows than in unix but is the cost of IPC/sync that far away from the linux model (shm/pipes/sockets) ? also ... when combined with the overhead of forking an whole interpreter is it really that much higher? Do you actually have any evidence for your claims about your windows bashing? … forking a process is more expensive in windows than in unix but is the cost of IPC/sync that far away from the linux model (shm/pipes/sockets) ? also … when combined with the overhead of forking an whole interpreter is it really that much higher?

]]> By: Lateef Jackson http://compoundthinking.com/blog/index.php/2008/05/14/threads-processes-rails-trubogears-and-scalability/#comment-176240 Lateef Jackson Tue, 20 May 2008 17:24:50 +0000 http://compoundthinking.com/blog/?p=306#comment-176240 Great post! I did some experiments with ASync and Pylons http://www.hackingthought.com/2007/05/wsgi-async-framework.html, I would love to see if it was possible to also get TurboGears running using an event based web server like I got Pylons to work. Great post! I did some experiments with ASync and Pylons http://www.hackingthought.com/2007/05/wsgi-async-framework.html, I would love to see if it was possible to also get TurboGears running using an event based web server like I got Pylons to work.

]]> By: Luke Hoersten http://compoundthinking.com/blog/index.php/2008/05/14/threads-processes-rails-trubogears-and-scalability/#comment-172916 Luke Hoersten Wed, 14 May 2008 20:51:34 +0000 http://compoundthinking.com/blog/?p=306#comment-172916 Great post, Mark! When I wrote about <a href="http://humani.st/scalable-web-apps-erlang-python/" rel="nofollow">computational parallelism to help scale web apps</a> written in Python, I assumed my readers would already understand all the concepts you've outlined above. When I realized most readers didn't understand, it seemed too much of a daunting tasks to write this post which you've so elegantly written. I wish this post existed when I first published my concurrency post. I'll be post-publish linking to this =) Great post, Mark! When I wrote about computational parallelism to help scale web apps written in Python, I assumed my readers would already understand all the concepts you’ve outlined above. When I realized most readers didn’t understand, it seemed too much of a daunting tasks to write this post which you’ve so elegantly written. I wish this post existed when I first published my concurrency post. I’ll be post-publish linking to this =)

]]> By: Michaek Foord http://compoundthinking.com/blog/index.php/2008/05/14/threads-processes-rails-trubogears-and-scalability/#comment-172754 Michaek Foord Wed, 14 May 2008 10:22:36 +0000 http://compoundthinking.com/blog/?p=306#comment-172754 Interestingly the .NET Dynamic Language Runtime (and hence IronPython and IronRuby) allows you to instantiate multiple language engines within the same process. This is really useful even within individual applications (Resolver One uses the IronPython API to create multiple engines - effectively execution environments - all from pure Python code). It is one advantage that IronPython has over CPython, that this is not only possible - but easy! Interestingly the .NET Dynamic Language Runtime (and hence IronPython and IronRuby) allows you to instantiate multiple language engines within the same process.

This is really useful even within individual applications (Resolver One uses the IronPython API to create multiple engines – effectively execution environments – all from pure Python code). It is one advantage that IronPython has over CPython, that this is not only possible – but easy!

]]>