I am new to FastCGI and looking to use this platform to speed up my existing vanilla CGI (perl) programs.
However in reading the FastCGI/Apache FAQ, it appears I can setup my scripts (once converted to use separate initialization/request sections) in the Apache config as one of the following:
1) dynamic
2) static "inside the scope of the SetHandler"
3) static "inside the scope of the AddHandler"
4) static "outside the scope of the Set/AddHandler" (or, I think, this can be called 'external')
I am confused about those 4 options, and am assuming the default of 'dynamic' is what I should go with, but could someone explain the pros/cons of these?
There isn't much to worry about Add/SetHandlers. They are just a way of defining which extensions are to be recognized as fcgi scripts.
What you might want to consider is dynamic, static or external.
Static is started as apache starts (possible this is the most common setup)
Dynamic is started whenever the first request is made (This is the default)
External requires the fcgi server to run separately from apache. (This is the most advanced configration)
I suggest you refer to the module documentation for more information (at least the summary):
FastCGI applications under mod_fastcgi are defined as one of three types: static, dynamic, or external. They're configured using the FastCgiServer, FastCgiConfig, and FastCgiExternalServer directives respectively. Any URI that Apache identifies as a FastCGI application and which hasn't been explicitly configured using a FastCgiServer or FastCgiExternalServer directive is handled as a dynamic application (see the FastCgiConfig directive for more information).
FastCGI static and dynamic applications are spawned and managed by the FastCGI Process Manager, fcgi-pm. The process manager is spawned by Apache at server initialization. External applications are presumed to be started and managed independently.
Of course if you are using Perl you can try mod_perl where you can start by using your CGI scripts first.
Related
Can someone explain the live cycle for a request in a Perl Dancer application starting from the server accepting the request. Does the application stay in memory like FCGI or does it have to be loaded for every request?
When using CGI, the application must be loaded with each request. FCGI, like you said, will keep the application running. Here's the lifecycle for CGI:
loads the perl runtime
loads necessary modules
configures the application
sets up all routes (not just the one needed)
finds the correct route and handles the request.
exits
When using FCGI steps 1-4 are done at load time. So if you are running with apache, when apache is started so is the perl runtime for your application. You are left with just step 5. Requests respond much faster when using FCGI.
Nowadays, many web shared webhosts support FastCGI, it's just a matter of configuring it correctly.
For the record I don't really know perl. I've deployed Rails apps on dotcloud. Here is what I am trying to do;
Currently I work for a SaaS. We run scripts (perl/python/php) on an external shared server to do what our software cannot. We need to move the script off of the shared server, and dotcloud seemed like a good option.
However I have nearly no experience running perl. It looks like I cannot just move the perl script, as dotcloud says that runs any perl using the psgi standard;
From dotcloud documentation: "The Perl service can host any Perl web application compatible with the PSGI standard."
I moved the script to my own hosting account and it worked but it appears to run too slow. It seems like a virtual host/server is the best option which was why I was excited about dotcloud, but since I'm not qualified to do modify perl myself (i.e. modify it to meet psgi standard) I need another option.
I question is 2 fold - how easy/difficult is it to make a simple perl script psgi standard OR are there any other virtual hosting options for perl with fewer restrictions?
If you just have a normal perl script that doesn't need to be served from a web server then you should use the perl-worker service. Using the perl worker service is meant for normal perl scripts so you don't need to worry about psgi because that is only for web stuff.
Here is a link to the perl worker page on dotcloud:
http://docs.dotcloud.com/0.9/services/perl-worker/
This will give you access to a normal perl environment, and you can run what ever you need, cron jobs, shell, etc.
I have a web app I'm writing in mod_perl 2. (It's a custom handler module, not registry or perlrun scripts.) There are several configuration options I'd like to have set at server initialization, preferably from a configuration file. The problem I'm having is that I haven't found a good place to pass a filename for my app's config file.
I first tried loading "./app.conf" but the current directory isn't the location of the modules, so it's unpredictable and error-prone. Or, I have to assume some path -- relative or absolute. This is inflexible and could be problematic if the host OS distribution is changed. I don't want to hard-code a path (though, something in /etc may be acceptable if there's just no better way).
I also tried PerlSetVar, but the value isn't available until request time. While this is workable, it means I'm potentially reading a config file from disk at least once per child (thread) init. I would rather load at server init and have an immutable static hash that is part of the spawned environment when a child is created.
I considered using a config.pl, but this means I either have a config.pl with one option to configure where to find the app.conf file, or I move the options themselves into config.pl and require end-users to respect Perl syntax when setting options. Future users will be internal admins, so that's not unreasonable, but it's more complicated than I'd like.
So what am I missing? Any good alternatives?
Usually a top priority is to avoid having configuration files amongst your executables. Otherwise a server misconfiguration could accidentally show your private configuration info to the world. I put everything the app needs under /srv/app0, with subdir cfg which is a sibling to the dirs containing executables. (More detail.)
If you're pre-loading modules via PerlPostConfigRequire startup.pl to access mod/startup.pl then that's the best place to put the configuration file location ../cfg/app.cnf and you have complete flexibility re how to store the configuration in memory. An alternative is to PerlModule your modules and load the configuration (with a relative path as above) in a BEGIN block within one of them.
Usually processing a configuration file doesn't take appreciable time, so a popular option is to lazy-load: if the code detects the configuration is missing it loads it before continuing. That's no use if the code needed to know the configuration earlier than that, but it avoids lots of problems, especially when migrating code to a non-modperl env.
I am not a developer so please keep that in mind when reading the following message:
I need to be able to use Windows PowerShell to connect to a JMX RMI agent on a host, is this even possible ?
The example string from the java client I have been given is as below:
JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:7979/jmxrmi");
The reason for this is that I am doing other work in my PowerShell script and would like to keep it all in one place.
Thanks !
This is an unusual mix of two technologies, but it is possible.
On the off-chance that you are attempting to connect to a JBoss server, the quickest way may be for you to call twiddle, a command tool that will dispatch JMX requests to the target JBoss server and return the results to standard out.
Another way is to implement the Jolokia agent on the target servers. This will allow you to issue JMX requests using REST. Responses will also be returned in REST format which you can process in PowerShell using one of these solutions.
Thirdly, you can also deploy the JMX-WS service on your target servers which will allow you to communicate with the JMX server using web-services. This document provides some VBScript examples of this.
None of the above actually uses the JMXServiceURL syntax you outlined, and I cannot think of a way you could actually cleanly integrate this RMI based protocol into PowerShell, but hopefully one of the above will work for you.
========== UPDATE ==========
There may be a way to use the RMI implementation. Take a look at IKVM. It is a Java Byte Code to .NET compiler. I have successfully compiled JMX/RMI java code into a .Net assembly and used it from C#. I think PowerShell will do the same thing.
Can I run my mod_perl aplication as an ordinary user similar to running a plain vanilla CGI application under suexec?
From the source:
Is it possible to run mod_perl enabled Apache as suExec?
The answer is No. The reason is that
you can't "suid" a part of a process.
mod_perl lives inside the Apache
process, so its UID and GID are the
same as the Apache process.
You have to use mod_cgi if you need
this functionality.
Another solution is to use a crontab
to call some script that will check
whether there is something to do and
will execute it. The mod_perl script
will be able to create and update this
todo list.
A more nuanced answer with some possible workarounds from "Practical mod_perl" book:
(I hope that's not a pirated content, if it is please edit it out)
mod_perl 2.0 improves the situation,
since it allows a pool of Perl
interpreters to be dedicated to a
single virtual host. It is possible to
set the UIDs and GIDs of these
interpreters to be those of the user
for which the virtual host is
configured, so users can operate
within their own protected spaces and
are unable to interfere with other
users.
Additional solutions from the sme book are in appendix C2
As mod_perl runs within the apache process, I would think the answer is generally no. You could, for example, run a separate apache process as this ordinary user and use the main apache process as a proxy for it.