Ok, Ok, Ok, I am a little behind on the WE front. I just started playing with it in the last weak-ish.
Q: Do you deploy as stand-alone or as CGI? and why?
Q: on stand-alone, do you have anything special in your startup script other than “path/to/WE/WEapp &”
any particular gotchas do I need to be worried about when deploying WE apps? I am hosting this VPS at Linode.com (got some free credits from the Perl community to try them out).
thanks
sb
In my opinion CGI.
From my understanding, CGI is a way to “plug into” a web server such as Apache or IIS. Stand-alone works as the name implies… a stand-alone app without needing to configure a seperate web server.
CGI is better geared for a heavy user load than stand-alone, but requires a bit of knowledge on how to set it up on Apache and/or IIS.
Not sure about this one.
CGI is not the way for a heavy load. Every request is a “Run this program”. This means “Load, allocate memory, run, unallocate memory, die”. Imagine that for 5000 users at the same time. Many small servers will go unresponsive after 500 simultaneous requests.
For a heavy load the way should be FCGI, where it loads once, serves many, and just really dies after not being used anymore.
Not shure how good their stand alone version works. That should be the WebServer+Apps all in one solution.
Standalone does not require a web server as it essentially IS a web server.
It also, in my experience, has had better latency issues since it always running. The cgi way checks to see if the app is running, if not it spin up and then passes the information to it. Once the app timeout expires with no activity the app dies and then waits for the cgi to start it up again.
I believe that once they get the SSL version working it will only work in standalone. Don’t quote me on that one since I’m not entirely sure.
Actually, the performance issue with CGI is that requests get duplicated, not launch of the app. The app instance will run until requests are quiet for awhile, as defined by app.timeout. The more data you are moving (files, pictures, etc.), the more stand-alone will help you with perceived performance.
When starting up the stand-alone, you can specify a --port=XX parameter. This will let you run multiple instances of the app simultaneously on your server.
As Bob says, SSL would only work on stand-alone. If you want SSL with CGI, you need to provide the Apache setup for https.
Right now, the big gotcha with SSL (available in betas) is file downloading. There are some weird memory leaks that occur with large files. Greg has basically said that SSL stuff at the low level has issues that need to be addressed. But, it is possible to work around things if you’re willing to hand downloads off to Apache. Not the easiest approach, but workable.
-Brad
[quote=6331:@Bob Keeney]Standalone does not require a web server as it essentially IS a web server.
It also, in my experience, has had better latency issues since it always running. The cgi way checks to see if the app is running, if not it spin up and then passes the information to it. Once the app timeout expires with no activity the app dies and then waits for the cgi to start it up again.[/quote]
make sense. Do you have a preferences one way or the other?
hmm. no SSL might be an issue for me right now. dont want to ship data in an unsecure method. more for me to look into.
thanks
sb
[quote=6329:@Ricardo Araujo]For a heavy load the way should be FCGI, where it loads once, serves many, and just really dies after not being used anymore.
[/quote]
FCGI is the script loading once, not the app. The app will always load once in CGI/FCGI deployments. You can deploy FCGI by renaming the script to .fcgi. I haven’t noticed any perceivable difference on a low load VPS between CGI/FCGI deployments.
We use Nginx (which handles the SSL communication) in front of standalone instances as a reverse proxy, and it has worked pretty well…
knew you could change the ports in the settings tab but didnt know about the cli parameter. that is good to know.
I misunderstood bob. I thought SSL was broken all over.
[quote=6343:@Richard “Brad” Hutchings]Right now, the big gotcha with SSL (available in betas) is file downloading. There are some weird memory leaks that occur with large files. Greg has basically said that SSL stuff at the low level has issues that need to be addressed. But, it is possible to work around things if you’re willing to hand downloads off to Apache. Not the easiest approach, but workable.
-Brad[/quote]
I am not doing FileDownloads (yet) so that might not be an issue for me. Hopefully Greg can fix the SSL stuff before I get there.
thanks
sb
do you like Nginx better than Apache? I have heard of it but I dont know anyone that runs it.
thanks
sb
SSL is available in the betas, per Greg’s message to the beta list in the 2012r2 cycle. In my experience, it works great for small amounts of data, i.e. typical web app requests. It blows up on large requests, e.g. files and pictures.
IIRC, documentation on enabling SSL is in one of the new guides.
[quote=6350:@scott boss]do you like Nginx better than Apache? I have heard of it but I dont know anyone that runs it.
thanks
sb[/quote]
Here is a well known user: https://signup.netflix.com/openconnect/software
My infrastructure is currently running apache on 8 servers at my day job. We are looking at Nginx with our next generation release later this year. For WE I would definitely use Nginx as it is better suited for that type of setup.
Hmmm, not exactly, or I am not totally following you.
FastCGI is a protocol, a standand designed to be layered on top of web servers API. A FCGI app is (at least internally) designed differently than a CGI application.
A CGI app can be any console app, that will be loaded from disk (unless using some good memory cache scheme) but their output is redirected to the calling web client and at end it dies and is unloaded. Every call to the CGI does that.
The Basic CGI request processing proceeds as follows:
For each request, the server creates a new process and the process initializes itself.
The Web server passes the request information (such as remote host, username, HTTP headers, etc.) to the CGI program in environment variables.
The Web server sends any client input (such as user-entered field values from an HTML form) to the CGI program's standard input.
The CGI program writes any output to be returned to the client on standard output. Error information written to standard error is logged by the Web server.
When the CGI process exits, the request is complete.
FastCGI is conceptually very similar to CGI, with two major differences:
FastCGI processes are persistent: after finishing a request, they can wait for new requests instead of exiting.
Instead of using operating system environment variables and pipes, the FastCGI protocol multiplexes the environment information, standard input, output and error over a single full-duplex connection. This allows FastCGI programs to run on remote machines, using TCP connections between the Web server and the FastCGI application.
Request processing in a single-threaded FastCGI application proceeds as follows:
The Web server creates FastCGI application processes to handle requests. The processes may be created at startup, or created on demand. The webserver knows it's not an usual CGI, usually it's informed by some setting like the file extension being .fcgi
The FastCGI program initializes itself, and waits for a new connection from the Web server.
When a client request comes in, the Web server opens a connection to the FastCGI process. The server sends the CGI environment variable information and standard input over the connection.
The FastCGI process sends the standard output and error information back to the server over the same connection.
When the FastCGI process closes the connection, the request is complete. The FastCGI process then waits for another connection from the Web server.
FastCGI applications can run locally (on the same machine as the Web server) or remotely. For local applications, the server uses a full-duplex pipe to connect to the FastCGI application process. For remote applications, the server uses a TCP connection.
// A CGI example in C:
[code] #include <stdio.h>
#include <stdlib.h>
void main(void)
{
int count = 0;
printf("Content-type: text/html\\r\
"
"\r
"
“CGI Hello!”
“
[code]
#include “fcgi_stdio.h”
#include <stdlib.h>
void main(void)
{
int count = 0;
while(FCGI_Accept() >= 0)
printf("Content-type: text/html\\r\
"
"\r
"
“FastCGI Hello!”
“
cgi is easy to deploy, IMO. It’s self starting so no need to get the command line of the server.
thanks!
Ricardo, the CGI/FCGI script is a bridge to the WE app.
Ok. I will read more about the WE someday and see more details on how they handle this. Thanks.
Please do that before answering people’s deployment questions.
Well I am just trying to be polite. I know enough to not like that extra perl layer in between.