Hi folks.
Please answer this poll about requesting mod_perl support for XFS Pro.
mod_perl can run Perl programs several times faster than regular cgi-bin.
It would take Alex about 2 days for the code changes to support mod_perl well.
Thanks, mrperl.
XFileSharing Pro - XFS Pro mod_perl request poll
- PilgrimX182
- Posts: 2186
- Joined: Mar 22, 2006 1:39 pm
Re: XFS Pro mod_perl request poll
It would take about 2 days to cleanup the 1.7 source for ModPerl::Registry, as long as the encryption module isn't the source of segfaults. 3x faster than plain CGI. (The source would still work under plain CGI on any webserver.)
It would take about a month to convert to mod_perl handlers and test it. 10x faster than plain CGI, or more. (Source would only work under Apache/mod_perl.)
mrperl
It would take about a month to convert to mod_perl handlers and test it. 10x faster than plain CGI, or more. (Source would only work under Apache/mod_perl.)
mrperl
Re: XFS Pro mod_perl request poll
All fine, but we're still waiting for this. Are you part of the team? If not, could you do this for a fee?mrperl wrote:It would take about 2 days to cleanup the 1.7 source for ModPerl::Registry, as long as the encryption module isn't the source of segfaults. 3x faster than plain CGI. (The source would still work under plain CGI on any webserver.)
It would take about a month to convert to mod_perl handlers and test it. 10x faster than plain CGI, or more. (Source would only work under Apache/mod_perl.)
mrperl
script is a perl script, the apache is just the caller, the perl is the killer, it's because of calling perl as a program every time somebody accesses a page. the script is quite heavy and requires some modules to load .so the mod_perl in apache would save the day , however, there is even better possibility
with lighttpd and perl fastcgi process. because mod_perl is fast, but the original perl binary is (usually) faster. and if it is used as a fastcgi (not cgi), then it will always stay in memory and won't have to always load and unload all the data.
I am coding upload.cgi for mod_perl now and will test it against lighty , fast cgi .And nginx or lighty for downloads.
with lighttpd and perl fastcgi process. because mod_perl is fast, but the original perl binary is (usually) faster. and if it is used as a fastcgi (not cgi), then it will always stay in memory and won't have to always load and unload all the data.
I am coding upload.cgi for mod_perl now and will test it against lighty , fast cgi .And nginx or lighty for downloads.
Re: XFS Pro mod_perl request poll
The author modified the XFS Pro 1.8 files in FS-dist, so it is ModPerl-compatible.
It is working for me on a fileserver (fs) with this config:
However, note that using ModPerl on a fs is likely useless. The point of ModPerl is to precache perl object code at the expense of memory (around 26 MB per mod_perl apache process vs. 4 MB for a regular apache process) to make pages load faster, so it would be more useful on the frontend web site.
By using ModPerl on the fs you just waste a bunch of memory for some lingering upload process, and waste even more memory updating the XUpload status pages.
I have seen one bug with ModPerl::Registry enabled: after a few uploads XUpload says "Time Remaining: NaN Seconds" until restarting httpd on the fs. ModPerl::PerlRun works fine though - just less performance than Registry.
It is working for me on a fileserver (fs) with this config:
Code: Select all
Alias /app /var/www/perl
<Directory /var/www/perl>
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
</Directory>
By using ModPerl on the fs you just waste a bunch of memory for some lingering upload process, and waste even more memory updating the XUpload status pages.
I have seen one bug with ModPerl::Registry enabled: after a few uploads XUpload says "Time Remaining: NaN Seconds" until restarting httpd on the fs. ModPerl::PerlRun works fine though - just less performance than Registry.
Re: XFS Pro mod_perl request poll
I have been doing more testing using Modperl::PerlRun on the fileserver.
If you use multiple fs configurations on the same machine in different directories, then PerlRun confuses $c in XFSConfig.pm, so api.cgi fails on fs_key (ie. wrong configuration parameters are loaded even if in different subdirectories.)
So you cannot safely use multple fs configs and ModPerl under the same instance of httpd2 unless you provide a unique filename for each XFSConfig.pm.
mrperl
If you use multiple fs configurations on the same machine in different directories, then PerlRun confuses $c in XFSConfig.pm, so api.cgi fails on fs_key (ie. wrong configuration parameters are loaded even if in different subdirectories.)
Code: Select all
res = OK:0:ERROR: fs_key is wrong or not empty
mrperl
Last edited by mrperl on Mar 08, 2011 8:55 am, edited 2 times in total.