FastCGI

[GregTomkins]

Can someone fill me in on WebSpeed and FastCGI ... eg. whether it is common, possible, irrelevant, a mere configuration choice, etc.

Disclaimer: needless to say, I don't understand FastCGI very well, but I think I get the general idea.

 

[Stefan]

Sorry... I had a look at it a few years ago, got stuck, asked something on peg, got an 'its simple but I won't tell you how' answer (both lost in the crash), stopped.

 

[TomBascom]

I doubt that it matters much anymore. My (admittedly weak) understanding is that it was more helpful back in the bad old days when CPU was a likely bottleneck. Most systems today have far more CPU power than they know what to do with.

But perhaps if you said more about why you're thinking about FastCGI it might spur thoughts from others.

 

[Stefan]

On Windows I think it does matter, which is the reason I looked into it a few years back. When using cgiip.exe the overhead was 0.30 seconds for the cgiip.exe call only - without running any of your own code to do something useful at all. When using wsisa.dll - which is kept in memory - the overhead dropped to 0.01 seconds (or so). The 0.30 seconds was considered normal overhead (by tech support) due to a process needing to be forked.

On Linux cgiip is fine. On Windows wsisa is fine - but you may want to put some recyclers around it, once it has crashed (this used to be a real issue, but seems pretty ok on current releases) it has crashed permanently.

 

[GregTomkins]

But perhaps if you said more about why you're thinking about FastCGI it might spur thoughts from others.

Mostly I would just like to understand the whole picture. Some folks seem to think running a busy site with 'slow CGI' is crazy, but you're probably right about the abundance of CPU.

 

[Gabriel Hautclocq]

Whatever how powerful your CPU is, FastCGI is always better than simple CGI. FastCGI handles traffic peaks and DDOS attacks better because it doesn't fork a process for each request, so it uses less CPU power and less memory.
I know that Webspeed is pretty outdated, but still it would be great if it could be made available as a FastCGI module for Apache for example.

 

[TheMadDBA]

I wouldn't expect any major updates to Webspeed in the future. You can tell from the history of changes to Webspeed and recent acquisitions and the improvements for REST and Open Clients that Progress is essentially giving up on the client side and trying to make it easier for people to use other front ends to access the 4GL/DB side.

 

[TomBascom]

Actually they are cooking up something new in the webspeed space. Details are thin but there might be more said at PUG Challenge.

 

[TheMadDBA]

Telerik based? That would make the most sense... Nice controls and AJAX and Kendo

 

[TomBascom]

I think it has more to do with the middle and back end bits at least in the first cut. But adding Telerik would make a whole lot of sense too.

 

[Rob Fitzpatrick]

They have already announced that WebSpeed support is coming in the Pacific AppServer, but I don't know much more than that. We'll know more in a month's time.

 

[TheMadDBA]

https://community.progress.com/community_groups/mobile/f/17/t/17944.aspx

This doesn't bode well for Webspeed but is likely to be a huge improvement for Web/Mobile based apps.