Skip to main content.


This is the archive for April 2008

Wednesday, April 30, 2008

We're setting up a falcon-powered site, through a Falcon module for Apache.

From the chatlog of this night...


Ok, I write here what I have done, because it's better if we're in 2 or 3 to know that.
I have that cute hosting.
On a USA virtual hosting server (inmotion
They are cute, but I have a fairly old fedora core 6 with support for virtual machines compiled.
So, upgrading is a delicate matter, and you got to live with the software you have on.
The point is that... we have apache 1.3 there.
And I have developed our extension for apache 2. Docs for apache 1.3 are sparse and outdated, and developing a new module from scratch for it is madness; also the module plant is TOTALLY different, so there is no re-usable code that may be used...
long story short, we're not doing things on apache 1.3
But I have that cute server...
So, I compiled from source apr-1.2, apr-utils and apache-2.2
Apr-1 lives well with apr-0.9; they have all separated.
But on a redhat based distro, where apache is called httpd and all its paths are mangled, it's a bit of hell.
So, I have installed apache2 under /usr/apache2.
Then, I have apache 2 running on localhost:8080, and our front end apache 1.3 proxies /newsite to 8080.
Problem was that the official apache server for fedora doesn't come with the proxy module.
So I had to download the sources of apache 1.3, and compiled the proxy module in shared mode.
I have created a startup script called http2 in /etc/init.d that ensures that our apache2 is loaded at startup.
this is actually an advantage. falcon 0.8.9 (the experimental piuma) is... experimental. In this way, if we crash or messup the back-end server, the front-end with the old site is still active;
when all will be ready, we'll simply switch the proxy target from /newsite to / and we'll have everything up and running.
site home is in /home/falcon10/newsite, owned by falcon10
Index document have been redefined to index.ftd
the second apache2 process is completely dedicated to serving that area. Also, since we are running on 2 physical CPUs, we won't incour in particular performance hit due to the proxying.
I would recommend a complete backup of /etc/httpd/conf and /usr/apache2 to preserve this setting.
(we have auto-backups included in the hosting price, but one can never know).
Fine; now it's time to make it work. tomorrow, I will start to work on the site. A bit of basic content and user management are a must.
The boring thing is that I have to compile everything there; i.e. I have to recompile dbi, hoping that devel packages on site are compatible with ours.
And now, I get a bit of rest.

Friday, April 25, 2008

Yesterday I did a bit of speed tests.

I stacked up many things in the main VM loop, as i.e. preemption in functional context, end-frame callbacks, and even the generic vector as stack; and it was long since I did an empty loop speed test.

I run the following (pseudo) code:

a = 0
for num in [0:100000000]
a = a + 1

Here are the results, using "time", for several scripting engines:

C: 0m0.257s (gcc -O0)
LUA: 0m8.021s
Falcon: 0m9.776s
PHP5: 0m14.923s
Python: 0m22.576s
Perl: 0m27.068s
Ruby: 1m25.947s

Now; an empty loop test doesn't mean anything in terms of overall performance, but it's nice to see we have one of the fastest VM loops around... when it's still heavily under-optimized!