XFileSharing Pro - increase Perfomance your XfileSharing pro cgi scripts

[sherayusuf3]

This tutorial shows how to install and use SpeedyCGI (also known as PersistentPerl) on a Debian Etch system. SpeedyCGI is a way to run Perl scripts persistently, which can make them run much more quickly. It keeps the Perl interpreter running, and during subsequent runs, this interpreter is used to handle new executions instead of starting a new Perl interpreter each time.

This document comes without warranty of any kind! I do not issue any guarantee that this will work for you!

1 Preliminary Note

I have tested this on a Debian Etch system (with Apache2 installed) with a virtual host www.example.com (document root: /var/www/web1/web) which is configured to run Perl scripts in the /var/www/web1/cgi-bin directory. The paths used here might differ from your setup, so adjust them where appropriate.

In the following I will show you three different ways of using SpeedyCGI for your Perl scripts.


2 Installing SpeedyCGI

To install SpeedyCGI together with the SpeedyCGI Apache2 module, we simply run:

Code: Select all

apt-get install libapache2-mod-speedycgi speedy-cgi-perl

and restart Apache afterwards:

Code: Select all

/etc/init.d/apache2 force-reload

3 Using SpeedyCGI

First we create a normal "Hello World!" Perl script to see if Perl is working. At the end of the script, we use some special code that is executed only if SpeedyCGI is used. This helps us to determine when we are in "SpeedyCGI mode" and when in normal "Perl mode". I create the script in my cgi-bin directory, /var/www/web1/cgi-bin:

vi /var/www/web1/cgi-bin/speedy-test.cgi

Code: Select all

#!/usr/bin/perl

### Your Script Here.  For example:
print "Content-type: text/html\n\n<h1>Hello World!</h1>\n";

##
## Optionally, use the CGI::SpeedyCGI module for various things
##

# See if we are running under SpeedyCGI or not.
if (eval {require CGI::SpeedyCGI} && CGI::SpeedyCGI->i_am_speedy) {
  print "<br>Running under speedy=", CGI::SpeedyCGI->i_am_speedy ? 'yes' : 'no', "\n";
}

We must make the script executable:

chmod 755 /var/www/web1/cgi-bin/speedy-test.cgi

(If you are using suExec, you will also have to change the owner and group of the script to match the suExec user and group of this vhost.)

Now we can call that script in a browser (http://www.example.com/cgi-bin/speedy-test.cgi). You should see Hello World!, nothing else:

3.1 Telling Apache To Execute All Perl Scripts Through SpeedyCGI

The first method is to tell Apache that it should execute all Perl scripts through SpeedyCGI if the Perl scripts are in a certain location. We will create an alias /speedy/ that points to our cgi-bin directory, and when we use the /speedy/ address in our browser, the Perl script gets executed by SpeedyCGI, whereas when we use /cgi-bin/, the script is run without SpeedyCGI.
Click here to find out more!

Open the file where your Apache vhost location for www.example.com is located, and add the following lines to it (if you are using ISPConfig, you can simply paste the following lines into the Apache Directives field of the respective vhost):

Code: Select all

Alias /speedy/ /var/www/web1/cgi-bin/
<Location /speedy>
  SetHandler speedycgi-script
  Options ExecCGI
  allow from all
</Location>

Restart Apache afterwards (you don't have to do this if you're using ISPConfig):

/etc/init.d/apache2 restart

Then go to http://www.example.com/speedy/speedy-test.cgi, and you should see that the script is now being executed through SpeedyCGI:

[PowerChaos]

can you give us a bit more explanation why this is better then the normal cgi ??

if i readed it right , then it shal decrease a bit less cpu usage because it use only 1 instance of perl instead XX instances (every request)

but is it stable to ? and does it do something about download speed

basicly i like to know , what good stuff do i have when using this instead the basic ??

what more stuff you have ?? what change to a better side then we have now

Thank you
Greets From PowerChaos

[sherayusuf3]

SpeedyCGI is a way to run perl scripts persistently, which can make them run much more quickly. A script can be made to to run persistently by changing the interpreter line at the top of the script from:

#!/usr/bin/perl

to

#!/usr/bin/speedy

After the script is initially run, instead of exiting, the perl interpreter is kept running. During subsequent runs, this interpreter is used to handle new executions instead of starting a new perl interpreter each time. A very fast frontend program, written in C, is executed for each request. This fast frontend then contacts the persistent Perl process, which is usually already running, to do the work and return the results.

By default each perl script runs in its own Unix process, so one perl script can't interfere with another. Command line options can also be used to deal with programs that have memory leaks or other problems that might keep them from otherwise running persistently.

SpeedyCGI can be used to speed up perl CGI scripts. It conforms to the CGI specification, and does not run perl code inside the web server. Since the perl interpreter runs outside the web server, it can't cause problems for the web server itself.

SpeedyCGI also provides an Apache module so that under the Apache web server, scripts can be run without the overhead of doing a fork/exec for each request. With this module a small amount of frontend code is run within the web server - the perl interpreters still run outside the server.

SpeedyCGI and PersistentPerl are currently both names for the same code. SpeedyCGI was the original name, but because people weren't sure what it did, the name PersistentPerl was picked as an alias. At some point SpeedyCGI will be replaced by PersistentPerl, or become a sub-class of PersistentPerl to avoid always having two distributions.

another info about my tweak follow this link
http://www.sibsoft.net/forum/alternativ ... ight=nginx

[komi]

Did you try this with XFS?

[PilgrimX182]

Just tried it on XFS and it works pretty buggy. Loosing login session somehow.
And it's latest version is from 2003

[komi]

Thanks for letting us know.