Hey Richard,
2009/1/5 Richard Dale <[email protected]>:
>> Do you suspect Wt::Ruby will not scale very well with FastCGI because
>> of the Wt::Ruby layer or rather because of Wt itself (i.e. memory
>> usage) ?
>
> Each process with Ruby uses 3-4 Mb of non-shared memory. I don't think that
> will be a problem in practice which is why I say 'might not' in the comment
> above. But the other guys who I work with see it as a possible problem and
> they think the Rails style 'shared nothing' approach is better. Until we've
> tried Wt::Ruby with actual applications it is difficult to say.
I understand that you do not consider the deployment case where you
have multiple sessions in a single process. Initially, we rejected
this deployment case too since obviously there is a Damocles Sword
hanging above any C++ program. And that is why you should be
developing using Java, or in .NET, or use Python or Ruby.
So they say and I believed it initially too.
But, after all those years dabbling around in Wt, I have become
confident that memory issues are nothing you should worry about THAT
much. In fact, we haven't seen any of the online examples go down over
the last year, except for managed outage, and all of them are deployed
using only a single process, and some of them (the homepage) get hit
by bigger news sites (reddit, ajaxian, ...). Granted, none of these
applications are terribly complex, but at least it proves that the
library (and built-in web server) can deal with the multiple threads.
The good thing about Wt is that the deployment choice is something you
can gradually change. During alpha testing and beta testing, and as
long as you have a small userbase, you can deploy with a single
process - single session approach. As your bug tracker reduces the bug
count and you wish to scale better in terms of memory use, you can
gradually change this deployment to some optimal number of processes.
But, obviously, it cannot be denied that a single pointer bug will
take down the entire process.
And that is why I actually see a big benefit of Ruby or Python
bindings to Wt: leave the C++ development to the part where it matters
most (the low-level widgets and their controller/rendering logic), and
use Ruby and Python for application development with an interpreter
watching over your shoulder for memory management. In this way, we
should be able to get the best of both worlds?
> I did some tests on the mill used by Wt with Ruby bindings and it is pretty
> low. A Wt::Ruby based web application running on a slow machine like the
> Nokia N810 internet tablet, uses neglibable mill. So I don't think there is
> much overhead in mill terms for Ruby, only in the larger size of the Wt
> processes.
And that confirms our profiling results: most of the cpu cycles in a
Wt application are spent inside the library itself (figuring what to
render, and how to render) -- and not in the construction of the
widgets are the manipulation of the widget hierarchy.
> I use Kubuntu. From the Wt docs:
>
> "Treat the example as a mod_fastcgi application, by adding a line to
> 20_mod_fastcgi.conf in your Apache configuration modules.d/ directory, e.g.:
>
> FastCgiServer /var/www/localhost/htdocs/wt-examples/composer/composer.wt
> "
>
> I have these fastcgi config files:
>
> /etc/apache2/mods-enabled/fastcgi.conf
> /etc/apache2/mods-enabled/fastcgi.load
> //etc/apache2/mods-available/fastcgi.conf
> /etc/apache2/mods-available/fastcgi.load
>
> I tried adding a line like that for hello.wt to mods-enabled/fastcgi.conf,
> and entered a url of wt-examples/hello/hello.wt but it didn't work.
This is how my fastcgi.conf file looks like: it simply treates any
application that ends with .wt as a FastCGI application:
$ cat fastcgi.conf
<IfModule mod_fastcgi.c>
AddHandler fastcgi-script .wt
# FastCgiWrapper /usr/lib/apache2/suexec2
FastCgiIpcDir /var/lib/apache2/fastcgi
# FastCgiConfig -maxClassProcesses 1
</IfModule>
And in /etc/apache2/sites-available, add for example (great for
testing on a local machine, probably foolish for producton), assuming
/var/www is DocumentRoot:
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews ExecCGI
AllowOverride None
Order allow,deny
allow from all
# This directive allows us to have apache2's default start page
# in /apache2-default/, but still have / go to the right place
#RedirectMatch ^/$ /apache2-default/
</Directory>
Regards,
koen
------------------------------------------------------------------------------
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
