Gossamer Forum
Home : General : Internet Technologies :

speedycgi - the pits!

Quote Reply
speedycgi - the pits!
From my tests, this module is dreadfully problematic.

For instance, when I ran a simple form-script and initiated the error page (as in not filling out fields) the script works as expected. Come back to script 10 minutes later and you still get is the same form error page with no way of returning to the start!

The same goes with another script that requires check boxes to output some code. Uncheck the boxes and you still get the output code regardless.

I was planning to use this module for links sql but now have doubts on it reliability.

Anyone else had these problems?

~ ERASER


Free JavaScripts @ Insight Eye
Quote Reply
Re: [Eraser] speedycgi - the pits! In reply to
That's not SpeedyCGI, but rather your form code I expect. Try it under Links SQL, simply change the path to perl from /usr/bin/perl to /usr/bin/speedy for any .cgi you want to test (you can start with just admin.cgi for testing).

SpeedyCGI works very well in my experience.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Eraser] speedycgi - the pits! In reply to
If in doubt, upload the problem script - someone may be able to spot something.

Last edited by:

Paul: Apr 10, 2003, 3:50 PM
Quote Reply
Re: [Alex] speedycgi - the pits! In reply to
I have isolated the problem down to using the 'mod_persistentperl.so' apache module that comes with speedycgi. Although this is not an experimental module, it should work but several scripts just get stuck at the last function initiated. Strange and very frustrating!

Yes I trust links sql will be fine. Trying this out tomorrow.

~ ERASER


Free JavaScripts @ Insight Eye
Quote Reply
Re: [Eraser] speedycgi - the pits! In reply to
Hi,

This is a symptom of a perl script that wasn't designed to run under a persistent environment.

For instance, if you have a global ($logged_in), and have code like:

if ($pass eq 'foo') {
$logged_in = 1;
}
...
if ($logged_in) {
...
}

then once $logged_in is set to 1, it will never get unset, and every subsequent request to the server will have $logged_in set. If a script doesn't work under `use strict`, that's probably a sign that it's not going to work.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Eraser] speedycgi - the pits! In reply to
If you are running under a persistant environment your code needs to be compatible. You need to initialize variables and globals and use strict coding.
Quote Reply
Re: [Paul] speedycgi - the pits! In reply to
The impression I got was using speedycgi insted of fastcgi is that little if no changes are needed for most scripts to work correctly. However, what you both have said and reading further this part of the faq http://daemoninc.com/...ntly_asked_questions suggests otherwise.

Looks like a careful evaluation will be needed before running just any script in this environment.

Thanks for the info.

~ ERASER


Free JavaScripts @ Insight Eye
Quote Reply
Re: [Eraser] speedycgi - the pits! In reply to
It is because you are using the persistant perl shared object. If you were just using speedycgi on its own then you would probably find it worked ok.

Last edited by:

Paul: Apr 10, 2003, 5:17 PM
Quote Reply
Re: [Paul] speedycgi - the pits! In reply to
Ok been playing around with the options and:

#!/usr/bin/perperl -- -r1

will disable persistence for incompatible scripts but still give the benefits of perperl pre-compiling the script.

All works good now. :)

~ ERASER


Free JavaScripts @ Insight Eye

Last edited by:

Eraser: Apr 11, 2003, 3:11 AM
Quote Reply
Re: [Alex] speedycgi - the pits! In reply to
Alex,

Do you have experience in running mod_fastcgi and mod_speedycgi together in the same binary (both as DSO). I'm wondering about any clash or indeed server performance hit with both these running. Both are need because advertpro will only work correctly with mod_fastcgi and not speedy unfortunately.

~ ERASER


Free JavaScripts @ Insight Eye
Quote Reply
Re: [Eraser] speedycgi - the pits! In reply to
Hi,

No, I'm afraid not.. Worse comes to worse, you can always drop mod_speedycgi. You still see a good performance boost if it's launched via mod_cgi using #!/usr/bin/speedy.

Cheers,

Alex
--
Gossamer Threads Inc.
Quote Reply
Re: [Paul] speedycgi - the pits! In reply to
Paul,

ADSQL, AdverPRO, Adcycle. Which will allow me to serve 50 MILLION ads a day? hardware is not an issue. can you answer that question? you look as if you know of ad serving programs so you can give me a hand.

Thanks,