Re: [Openinteract-dev] Using FastCGI as development plaftorm

[<an...@io...>]

Perrin Harkins wrote:
> But... they do the same thing.  I don't see how the FastCGI one can
> actually be ready more quickly, unless it's just the bug you referred to
> with reloading during startup.

Well there is the bug of initializing multiple times on startup.

Then there is the bug of causing an infinite loop when Apache is stopped 
probably because of undefined subroutine calls. This on the other hand 
causes a lot of swapping, setting swappiness doesn't cut it, and if I 
turn of the swap, it sometimes causes my Linux to crash ;)

Then there is the problem (which is probably caused by the previous one) 
that you can't start apache right after stopping it without producing a 
failure, probably because some of the processes are still busy trying to 
consume a lot of memory.

And then there is the thing I _tried_ to describe ;) At least with the 
above problems and the large codebase of OI2, stopping and starting 
Apache takes a long time. You just have to stare at the prompt until it 
gets done. When it is done you change the workspace and refresh the 
page. The time which elapses between server start and a refreshed page 
varies, but is usually more than nothing. With FastCGI there is no lag 
between these things caused by a lazy coder. Also apache restart never 
fails when using FastCGI so I can bind it to a key, press it and presume 
that apache is restarted.

The last ones are small things, but believe me, they relieve you of a 
lot of frustration when you go through the procedure of reloading for 
testing _many_ times a day ;)

And yes - I think that all of the above are bugs in OI2 but I have no 
clue how hard they are to fix, and since they don't affect productio use 
that much and can be circumvented in development by usin FastCGI, I have 
more urgent tasks to tackle (like spending the whole day writing to 
oi-dev ;-))

> I'm one of the maintainers of that page. :)

Thanks for the great pages :)

> A noticeable hit on the first request is more likely to be due to making
> a database connection or reopening log files than overhead from copying
> dirty pages.

This is what I thought of first, since copying dirty memory doesn't seem 
like such a huge deal, but looking at the timed logs of OI requests got 
me thinking otherwise, since the slowdowns seemed to occur throughout 
the execution.. But I'm seriously beginning to doubt myself here (it was 
quite late then and it's 5.15 AM now ;)) so I'll check this again later.

> Then you can get the same effect in mod_perl by setting the process
> controls in httpd.conf to run a single server, or by starting apache
> with the -X flag which tells it not to fork.

By using FastCGI I can use the same apache to serve all the static 
requests (which are usually plenty when reloading a normal page), so 
just reducing the amount of Apache processes does not give the same 
result as easily. But this discussion is not going anywhere ;)

> If it's just for dev though, the oi2_daemon server would probably work
> just as well.

That is true, but it also does initialization on startup (and forks, if 
it matters ;-)). It might have also been a good choice to overcome the 
problems, but FastCGI seems to be even slightly better because of the 
initialization on request.

- Antti