I've Links SQL running under mod_perl without problems, but i can not upgrade to Apache 2 because mod_perl2 is still unstable. Will a modification of my Lins SQL scripts to support fastCGI with Apache2 be a viable solution? performance wise that is, or it is not worth the effort? can sombody comment on this?

Thanks,

Unless you have a strong reason for upgrading to apache2 then stay as you are :)

Have you tried Speedy CGI? Works like a charm under Apache 2.

Regards,



Clint.
--------------------------
http://AffiliatesDirectory.com
The Affiliate Programs Directory

Well, I'm aware that speedy CGI will indeed work with apache2, but when comparing mod_perl, fastcgi and speedycgi fastcgi beats them hands down, or at least that's why I think, So the question would be if the performance boost i'll get using apache2+fastcgi (if I modify the ssripts) is significant and worth the effort over what I get today with apache1 and mod_perl1 or Apache2 + speedycgi. If you guys have tested it under load you know that apache2 can handle greater loads without impacting the CPU much.

Maybe Gossamer can comments on this?

mod_perl is faster than fastCGI in terms of using modules and loading them into memory. FastCGI will just keep processes down at a better level so I guess you need to evaluate which is more important, script speed or server performance.

However FastCGI is safer than mod_perl. I would also welcome FastCGI support into Links SQL.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

I'm curious why you want to upgrade to Apache2? Is there any compelling reason? As for FastCGI support, it's not built into the product. You can use SpeedyCGI which is a very similiar technology which we do support (I prefer this as it doesn't require wrapping your code in a while loop, no changes to the code are required).


Ouch, not this again. It's no safer if mod_perl is setup properly.

Cheers,

Alex
--
Gossamer Threads Inc.

Yes, Alex, we already talked about this in the mentioned thread.

Well, Perl professionals, who I trust, says mod_perl is broken. You say the opposite.
I don't judge anybody, since I don't know enough about mod_perl. But if some professional programmers are convinced that mod_perl is broken, I will ask myself, which one is better to choose?
The mod_perl which may have problems, or FastCGI which is recommended by everybody?

Performance of mod_perl and FastCGI is almost the same (FastCGI has only a bit faster performance).
Comparison of Portable Dynamic Web Content Technologies for the Apache Server:
http://www.dmst.aueb.gr/...nt/html/dyncont.html
(Well, except SpeedyCGI, which has about 30% performance difference)

A light comparison of SpeedyCGI vs mod_perl & FastCGI (pros & cons by developer of SpeedyCGI, Sam Horrocks, presented in 2001 at YAPC North America):
A light comparison of SpeedyCGI vs mod_perl & FastCGI

Some further comments:
- I'm on shared virtual webserver, where mod_perl is not likely will be installed.
- Alex, you said SpeedyCGI is not supported on Windows. However I do my developments under Windows. So I have no other choice than mod_perl. There is no alternative, no choice for me at the moment.
- FastCGI has Windows support (unlike SpeedyCGI)
- FastCGI must be wrapped into a loop. SpeedyCGI not. But SpeedyCGI doesn't have Windows support. So which is better for me??? IMHO, the one it's at least possible to use under Win, FastCGI
- Alex, thanks to your fine development technique, wrapping content of page.cgi and other cgi files should be a breeze. Yes, of course in the main code there FastCGI should be also supported, so maybe there may be need some changes, too (if there would be need any).

Ease of use:
- both mod_perl & FastCGI needs special setups. mod_perl is not likely that will be installed on shared virtual servers...
- SpeedyCGI is nice, but has no Windows support (shooting off).

Cross platform:
mod_perl: good
FastCGI: fair (I saw there are still bugs & problems under Windows, but there is at least support for Windows)
SpeedyCGI: no Windows support at all (planned for future...)

Safety:
I'm not convinced about mod_perl safety. And even if it's made safe doesn't mean performance decrease?
FastCGI is safe anyway as far as I know.

Speed:
While there is not very big performance difference, the top list is:
1) FastCGI (just a bit over mod_perl)
2) mod_perl (this is 100% reference for SpeedyCGI comparison)
3) SpeedyCGI (70% compared to mod_perl). That's 30% difference.

Comparison of speedycgi and mod_perl is here (directly from SpeedyCGI website):
http://daemoninc.com/SpeedyCGI/benchmarks/
PApp::CGI (using speedycgi): 21 hits/s
PApp::Apache (native mod_perl): 30 hits/s

Finally, Google results for keyword "fastcgi" 189,000 hits. For keyword "speedycgi" there are only 6,380 hits.
That seems 29 times more hits for FastCGI...

For which one I can get more support on the net, if I have problems? FastCGI or SpeedyCGI?
So please Alex, don't say me ouch... I hate this.

If there would be Win32 version of SpeedyCGI I would be satisfied with it. But until there is NO Win32 support, I will stand by supporting the FastCGI support for Links SQL.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Alex, Under heavy load Apache2 keeps CPU and memory utilization really low.

And, regarding the one who said mod_perl is broken. I've argued HUNDREDS of times about this with my peers, I work for a big internet company (one of the few lefts) and I've sucesfully handled loads in excess of 1M pageviews an hour with a farm of servers running custom apps in mod perl. PHP nor Coldfusion could handle what mod_perl handled in my enviroment, the experts who told you that maybe are experts programmers without practical internet ultra heavy load enviroments experience. Even our ENTIRE registration system for some several million users is written entirely in mod_perl. Is FASTCGI good? sure it is, but don't you ever say mod_perl is broken or not safe ;)

Hi,

You say it's broken, and not safe, but you list no reasons why except for what some people told you? What did they tell you? If you can install FastCGI on your virtual server, then you can probably install mod_perl on it as well (safely as a proxied apache).

I would not be concerned too much between the benchmarks between mod_perl, fastcgi or speedy as if you are on a virtual server you are not going to even come close to being limited by what the application server can do. However, for some other benchmark see:

http://www.chamas.com/bench/

My recommendation would be to use mod_perl on your site. If you have SSH access, then there should be no problem setting it up (as unless your ISP has special prebuilt fastcgi support, it will probably be about the same amount of work).

Cheers,

Alex
--
Gossamer Threads Inc.

Interesting, is this using a different mpm, or just using the "out of the box setup"? I haven't done too much testing with Apache2 yet, but haven't seen a convincing reason to upgrade really.

Cheers,

Alex
--
Gossamer Threads Inc.

By the way, I don't mean anything bad by this, don't take it the wrong way. =)

Cheers,

Alex
--
Gossamer Threads Inc.

The "mod_perl is broken", is a quoted opinion. I have not enough experience to say that.
But the question is not about mod_perl, but about FastCGI support.

So if FastCGI:
- is as fast as mod_perl,
- has no drawbacks (except wrapping into loop),
- much faster than SpeedyCGI (even http://www.chamas.com/bench/ benchmarks proves that)
- more often used than SpeedyCGI, so likely there is more support
- has Windows support

All these makes me FastCGI as preferred solution.
Not sure tough, how FastCGI compares to mod_perl from a viewpoint of a shared virtual server hosting provider.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

I quoted what they said, in your mentioned thread we discussed earlier.

I'm not an Apache guru, so I just support installing FastCGI is easier...

I was just reading http://www.chamas.com/bench/ results. Anyway, it proves that SpeedyCGI performance is worser than mod_perl or fastcgi.

I have SSH, but have no experience installing mod_perl in such way.

But what are your reasons, deciding not to support FastCGI?

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Yes, but you also said that you now see that their are good and safe ways to setup mod_perl, so when you say in this thread that mod_perl is not safe, I thought something had changed your mind back.

As for setup, if you are comfortable compiling programs, it's not very hard and the docs are very good:

http://perl.apache.org/..._Apache_Installation

FastCGI is going to require at least an equivalant amount of work. All of these technologies are going to put very similiar requirements on your virtual server. You need the ability to have some persistent running application so that when somebody comes to run your perl app, instead of forking and launching perl and have it compile your program, instead it will connect to theis persistent application.

How you connect to this application depends on your virtual host. If they just have a regular Apache, then your options are:

1. Connect to a fastcgi backend with cgi-fcgi
2. Connect to a SpeedyCGI backend with speedy program
3. Connect to a mod_perl backend with mod_rewrite/mod_proxy (or if they don't have those modules, then directly to a high port).


Again, on a virtual server the hit/s benchmarks are pretty meaningless as there is no way you will come close to that level of traffic. Also, once you get to a fair size perl application, then the technology has less and less to do with things, and the quality of the app is more important, so it doesn't "proove" anything (although mod_perl is 1.5x faster then fastcgi). =)


The main reasons are lack of demand and that I think SpeedyCGI is a better alternative (no requirements to change your code). But mainly lack of demand. Our programs are designed to be safe under persistent environments, so you could try just wrapping sub main() in each .cgi in a FastCGI accept loop, and that should be the bulk of the changes.

Cheers,

Alex
--
Gossamer Threads Inc.

Well, not changed my mind back, but I was looking for FastCGI docs & reviews, and my conclusion was, that FastCGI satisfies all the needs I have. Especially that it has Win32 support. That's strong point against SpeedyCGI. Against mod_perl there is not very much as you say, but I still would better prefer FastCGI, over mod_perl.

How you mean backend? Backend must be on a separate machine? Or not necessarily?

Unfortunately SpeedyCGI is not an alternative. Has no Win32 support, yet.

There was some demand for FastCGI. Ok, not too much, but there is. I saw several threads on the forum regarding FastCGI.
And all the time when users were interested in it, were redirected by you and other experts to use mod_perl or SpeedyCGI. And people accepts your opinion. Because Alex said.
Nobody had enough knowledge (or enough courage?) to ask: why do I need to stick to them if I have other needs? The people are always convinced, that what they wanted is wrong, or the 2 other choices are better.
As you might see on the forum, I'm a straight man, and I say out what I think. So please don't feel offended because of my words, ok?

Yeah, that was in my mind. Most of the features should work without problems, even under FastCGI.
If that would work, I would not afraid that GT officially supports FastCGI or not.
I would even do the needed FastCGI fixes, if you would include FCGI compatibility changes into next release.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

An advantage of using mod_perl is that it enforces strict, well written code, whereas speedycgi and fastcgi don't, they will just work off any code regardless of it's integrity (well speedycgi more so than FastCGI).

It also let's the programmer delve more into memory management issues (which is not always pleasant) ...and also provides access to Apache core features and hooks, so I'd say it's a more advanced solution that FastCGI (depending on your needs).

One adavantage of FastCGI is that it is not language specific - apps can be written in C++, Java and Python as well as Perl.

The thing that just puts me off FastCGI is the use of a while loop. I don't know why, I just don't like neverending loops