Re: mod_perl vs. C for high performance Apache modules
On Fri, 14 Dec 2001, Jeff Yoak wrote: All, I wasn't sure what volume of response to expect when I originally wrote. Thank you all for the comments that you all are making. They are helping. Given that the response is fairly high, I'm waiting for stuff to roll in rather than replying to each of you. Don't think it is falling on unappreciating ears. :-) To respond to a few recurring comments / questions: Me? I've spent most of the last four years working on mod_perl-based stuff and most of the last eight working with Perl. Actually I've worked with folks who were involved with some of the projects you've mentioned, having been at idealab!, a parent of eToys and CitySearch. One of the original (THE original?) developer at CitySearch was probably the most helpful mentor / teacher I've ever worked with. I programmed in C a lot early in my career, but at this point I couldn't write anything substantial without brushing up, and frankly wouldn't care to. It just isn't as fun to work with C. But then, the argument, But if you used C, you wouldn't get to work with ME! may not convince some of these people with their values all screwed up... ;-) Actually that would be my argument. When you're getting investors in, the primary thing they should be looking to buy into is the quality of the people there, not necessarily the code, because only one out of those two can be fixed easily (even in our current times, totally replacing a programming team is a difficult thing to do). I write C. I write Perl. And I combine them both to good effect. But, I wouldn't even consider writing anything but time critical routines in C - I do as much as possible in Perl for the following reasons: - It's fast enough. - It's safer. - It has a built in test harness (Test::Harness). - It's more fun. - It's faster to develop in. - It's OO, and that saves me time and effort. - It has an infinitely better community than C. The last point is probably my favourite, though probably means bugger all to an investor. -- !-- Matt -- :-Get a smart net/:-
Re: modperl vs. C
[Crossposting modperl list, since Jeff Yoak sent his question to both lists, and I'd rather answer once :)] Ask Bjoern Hansen wrote: [EMAIL PROTECTED] (Jeff Yoak) writes: [C vs mod_perl for web applications] with something I've done, and a client's investor who is blowing a gasket because of the opinion that using mod_perl is a completely psychotic choice for a website that is going to experience high traffic. I'm in the process of defending my choices right now, and a little extra ammunition would be useful. You can probably find more stories like that on the mod_perl mailinglist. (Stas is reading this list, maybe he can think of more high volume examples). Think for a minute. mod_perl itself is mostly written in C. In fact it's a C Apache module. Tell it to your angry investor. You cannot beat C with another C, if you know Doug (who wrote mod_perl), he is the performance monster - I doubt many people can write more performant C than he does. Half of the problem solved. Now tackle the second half. You stand before the choice of developing the project in C or Perl (or another language). Unless you have a built-in C compiler in the head of every person on your team, each recompilation adds to the development overhead. But that's peanuts, once you come to testing/debugging/memory leaking stage, you cannot beat Perl here. But your investor claims that he is willing to make the project's development longer in C if the performance will be substantially better (oops forgot the maintanance part :). So accept his words, but... prototype and develop in Perl. Finish it fast, get things working, get lots of tests that pass. Now spend the rest of the time profiling the code and re-writing the slow parts in C/XS and you are done. You've two wins here 1. You deliver the first stage early and allow for last minute changes, and you can even start using the code in production. 2. Nothing stops you from eventually finish up with a system which is mostly written in C. But I doubt that this will happen. Because the market realities will not let you the time you will need. And because Perl doesn't perform bad at all compared to C, unless you handle a lot of bits of data, where C beats Perl by many times, and that's where you do XS/C for the data handling. Look at all Math modules on CPAN. Their cores are written in C and interface is in Perl. I guess that gives you an idea of what I mean. Choosing Perl doesn't bind your hands but does the opposite. If you throw in Inline::* modules, you can even use many other languages, including Assembly language :) Hmm, I should try to write some content handler in assembly language, gotta be very fast, though not portable :( In any case here are some resources that you can use to make your point: http://perl.apache.org/perl_myth.html http://perl.apache.org/stories/ http://perl.apache.org/sites.html There is one thing that will make all these arguments useless. If you've got a team of good C programmers which don't know Perl or know it very bad, you probably want to go with C and try to get them to learn Perl for the next project. But that's true for any other languages. It's just that I'm not wearing your hat, so I cannot see what you see. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_perl vs. C for high performance Apache modules
While this advocacy thread is hot, please remember my request to send me your success stories so we have more material others can use to prove their point to their investors, bosses, girlfriends, moms :) I've received only three new stories since my request (I didn't put them online yet, they will go into the new site). If you do send them to me (or list), please use a plain text and follow this format: URL: Title: Contact Person: Traffic: (hits/day/month/whatever) Success Story: and anything else you wish to tell. Check if your story is already online and send an update if there is something to change. See http://perl.apache.org/stories/ and http://perl.apache.org/sites.html. Thanks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Success story.
The URL is on an internal LAN for a company whose name I cannot use. The site gets up to a few hundred hits per second supporting a telephone call center database. My company was asked to develop a web front end onto a TB data warehouse. The existing system (carefully crafted in C) was so slow people couldn't get their work done (e.g., 45-minute query times). We re-did the back end and slapped an interface on it using mod_perl. The first time the users saw it they asked for a Stop button like the existing system had so they could abort long-running queries. Then we went over where to put it with me running queries. They gave up on the idea because the data was returned too fast for them to hit a button. Through 4+ weeks of User Acceptance Testing (UAT) they asked for a few dozen changes in the reports. Few of them took loger than 20 minutes to implement. In several cases they got annoyed that the company email took longer to deliver the fix notice than make the change. Using Perl we were also able to handle the database manglement software for tablespace and table creation, web site auth. and reporting code and most of the ETL process management code in one language. That also saved us quite a bit of work. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: mod_perl vs. C for high performance Apache modules
I know this sounds kind of simple minded but why not bench test the site, set everything up in the office get a good switch plug the site into 1 port and 5-10 client boxes with some load testing software and plug it in to the same switch and beat the crap out of it. After you do this for a while and find all the hot spots show it to the customer and go here it works. marc - Original Message - From: Matt Sergeant [EMAIL PROTECTED] To: Jeff Yoak [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 15, 2001 3:24 AM Subject: Re: mod_perl vs. C for high performance Apache modules On Fri, 14 Dec 2001, Jeff Yoak wrote: All, I wasn't sure what volume of response to expect when I originally wrote. Thank you all for the comments that you all are making. They are helping. Given that the response is fairly high, I'm waiting for stuff to roll in rather than replying to each of you. Don't think it is falling on unappreciating ears. :-) To respond to a few recurring comments / questions: Me? I've spent most of the last four years working on mod_perl-based stuff and most of the last eight working with Perl. Actually I've worked with folks who were involved with some of the projects you've mentioned, having been at idealab!, a parent of eToys and CitySearch. One of the original (THE original?) developer at CitySearch was probably the most helpful mentor / teacher I've ever worked with. I programmed in C a lot early in my career, but at this point I couldn't write anything substantial without brushing up, and frankly wouldn't care to. It just isn't as fun to work with C. But then, the argument, But if you used C, you wouldn't get to work with ME! may not convince some of these people with their values all screwed up... ;-) Actually that would be my argument. When you're getting investors in, the primary thing they should be looking to buy into is the quality of the people there, not necessarily the code, because only one out of those two can be fixed easily (even in our current times, totally replacing a programming team is a difficult thing to do). I write C. I write Perl. And I combine them both to good effect. But, I wouldn't even consider writing anything but time critical routines in C - I do as much as possible in Perl for the following reasons: - It's fast enough. - It's safer. - It has a built in test harness (Test::Harness). - It's more fun. - It's faster to develop in. - It's OO, and that saves me time and effort. - It has an infinitely better community than C. The last point is probably my favourite, though probably means bugger all to an investor. -- !-- Matt -- :-Get a smart net/:-
Re: load balancing on apache by IP CHAINING
I'm confused'IP chainging' as the name says is at the IP (or Network) layer, what does that have to do with Apache or any HTTP server at the application level. I think any such IP based load balancing technologies are inherently unaware of the total system issues and are simply making a jugdment based on the IP level or perhaps a specific protocol on top of IP to route the next packet (or next session). Having said that a Perl HTTP would/could benefit from it just as well... On Sat, 15 Dec 2001, Anand R wrote: IP chaining can be done in Java Webserver, How to do it in Apache Webserver. Please let the Ring know this, Thanks in advance, Regards, Anand - Original Message - From: Derek Jones To: Hemant Singh ; [EMAIL PROTECTED] Cc: Derek G Jones Sent: Friday, December 14, 2001 7:29 PM Subject: RE: load balancing on apache Hi all, You can do load balancing using ipchains as well. Can't remember the program name offhand, but if I have time I'll look it up and let the list know. Only works if your servers are Linux of course. Kind regards Derek. -- Derek Jones 1051, Bollinger Road, Tel:717 359 8817 Littlestown, Mobile: 717 977 4556PA, 17340, USA Email: [EMAIL PROTECTED] AIM: scunacc -- - Medi Montaseri [EMAIL PROTECTED] Unix Distributed Systems EngineerHTTP://www.CyberShell.com CyberShell Engineering -
Re: Comparison of different caching schemes
Rob Mueller (fastmail) wrote: And ++ on Paul's comments about Devel::DProf and other profilers. Ditto again. I've been using Apache::DProf recently and it's been great at tracking down exactly where time is spent in my program. One place that Rob and I still haven't found a good solution for profiling is trying to work out whether we should be focussing on optimising our mod_perl code, or our IMAP config, or our MySQL DB, or our SMTP setup, or our daemons' code, or... Can anyone suggest a way (under Linux 2.4, if it's OS dependent) to get a log of CPU (and also IO preferably) usage by process name over some period of time? Sorry to move slightly off-topic here, but in optimising our mod_perl app we have to work out which bit of the whole system to prioritise.
Re: Comparison of different caching schemes
One place that Rob and I still haven't found a good solution for profiling is trying to work out whether we should be focussing on optimising our mod_perl code, or our IMAP config, or our MySQL DB, or our SMTP setup, or our daemons' code, or... Assuming that the mod_perl app is the front-end for users and that you're trying to optimize for speed of responses, you should just use DProf to tell you which subroutines are using the most wall clock time. (I think it's dprofpp -t or something. Check the man page.) If the sub that uses IMAP is the slowest, then work on speeding up your IMAP server or the way you access it. CPU utilization may not be all that telling, since database stuff often takes the longest but doesn't burn much CPU. - Perrin
Re: Comparison of different caching schemes
On Sun, Dec 16, 2001 at 09:58:09AM +1100, Jeremy Howard wrote: Can anyone suggest a way (under Linux 2.4, if it's OS dependent) to get a log of CPU (and also IO preferably) usage by process name over some period of time? What about BSD Process Accounting (supported in most *nix systems) and sysstat (iostat + sar)? regards, Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: Comparison of different caching schemes
On Sat, Dec 15, 2001 at 08:57:30PM -0500, Perrin Harkins wrote: One place that Rob and I still haven't found a good solution for profiling is trying to work out whether we should be focussing on optimising our mod_perl code, or our IMAP config, or our MySQL DB, or our SMTP setup, or our daemons' code, or... Assuming that the mod_perl app is the front-end for users and that you're trying to optimize for speed of responses, you should just use DProf to tell you which subroutines are using the most wall clock time. (I think it's dprofpp -t or something. Check the man page.) If the sub that uses IMAP is the slowest, then work on speeding up your IMAP server or the way you access it. CPU utilization may not be all that telling, since database stuff often takes the longest but doesn't burn much CPU. I agree 100%, wall clock time is the best metric. Consider that most apps are not CPU bound, they are I/O or network bound. Wall clock time measures that exactly. Another useful tool is truss/strace. Start up your server single process (-X) and then attach to it with strace. The -c and -r flags to strace are quite handy.. For example here's the cumulative stats for 'ls' % time seconds usecs/call callserrors syscall -- --- --- - - 52.290.004508 751 6 read 19.480.001679 560 3 write 12.930.001115 5620 close 6.010.000518 2323 old_mmap 5.450.000470 2122 2 open 1.220.000105 21 5 munmap 0.930.80 40 2 getdents64 0.710.61 321 fstat64 0.290.25 4 7 brk 0.240.21 11 2 mprotect 0.190.16 8 2 ioctl 0.120.10 10 1 uname 0.090.08 3 3 2 rt_sigaction 0.060.05 5 1 fcntl64 -- --- --- - - 100.000.008621 118 4 total -- Paul Lindner [EMAIL PROTECTED]| | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
cvs commit: modperl-2.0/pod modperl_dev.pod
dougm 01/12/15 15:45:05
Modified:lib/ModPerl BuildOptions.pm
pod modperl_dev.pod
Log:
make MP_GENERATE_XS=1 the default
Revision ChangesPath
1.13 +1 -0 modperl-2.0/lib/ModPerl/BuildOptions.pm
Index: BuildOptions.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildOptions.pm,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- BuildOptions.pm 2001/11/21 02:13:00 1.12
+++ BuildOptions.pm 2001/12/15 23:45:05 1.13
@@ -25,6 +25,7 @@
}
$build-{MP_USE_DSO} = 1 unless $build-{MP_USE_STATIC};
+$build-{MP_GENERATE_XS} = 1 unless exists $build-{MP_GENERATE_XS};
}
sub parse {
1.46 +2 -2 modperl-2.0/pod/modperl_dev.pod
Index: modperl_dev.pod
===
RCS file: /home/cvs/modperl-2.0/pod/modperl_dev.pod,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- modperl_dev.pod 2001/12/13 18:09:41 1.45
+++ modperl_dev.pod 2001/12/15 23:45:05 1.46
@@ -64,8 +64,7 @@
=head2 Create the build environment
% cd modperl-2.0
- % perl Makefile.PL MP_GENERATE_XS=1 \
-MP_APXS=$apache_prefix/bin/apxs make
+ % perl Makefile.PL MP_APXS=$apache_prefix/bin/apxs make
Ioptions an optional list of (key,value) pairs.
@@ -80,6 +79,7 @@
=item MP_GENERATE_XS
Generate xs code from parsed source headers in Ixs/tables/$httpd_version.
+Default is 1, set to 0 to disable.
=item MP_USE_DSO
cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm
dougm 01/12/15 15:51:43
Modified:xs/tables/current/Apache ConstantsTable.pm FunctionTable.pm
StructureTable.pm
xs/tables/current/ModPerl FunctionTable.pm
Log:
sync
Revision ChangesPath
1.19 +2 -2 modperl-2.0/xs/tables/current/Apache/ConstantsTable.pm
Index: ConstantsTable.pm
===
RCS file: /home/cvs/modperl-2.0/xs/tables/current/Apache/ConstantsTable.pm,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- ConstantsTable.pm 2001/11/19 22:40:12 1.18
+++ ConstantsTable.pm 2001/12/15 23:51:43 1.19
@@ -2,7 +2,7 @@
# !!
# ! WARNING: generated by Apache::ParseSource/0.02
-# ! Mon Nov 19 14:57:24 2001
+# ! Sat Dec 15 15:39:22 2001
# ! do NOT edit, any changes will be lost !
# !!
@@ -291,6 +291,7 @@
'APR_APPEND',
'APR_TRUNCATE',
'APR_BINARY',
+ 'APR_EXCL',
'APR_BUFFERED',
'APR_DELONCLOSE'
],
@@ -346,7 +347,6 @@
'APR_ENETUNREACH',
'APR_EFTYPE',
'APR_EPIPE',
- 'APR_EXCL',
'APR_END'
],
'common' = [
1.28 +168 -61 modperl-2.0/xs/tables/current/Apache/FunctionTable.pm
Index: FunctionTable.pm
===
RCS file: /home/cvs/modperl-2.0/xs/tables/current/Apache/FunctionTable.pm,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- FunctionTable.pm 2001/11/19 22:40:12 1.27
+++ FunctionTable.pm 2001/12/15 23:51:43 1.28
@@ -2,7 +2,7 @@
# !!
# ! WARNING: generated by Apache::ParseSource/0.02
-# ! Mon Nov 19 14:57:32 2001
+# ! Sat Dec 15 15:39:32 2001
# ! do NOT edit, any changes will be lost !
# !!
@@ -1041,6 +1041,11 @@
]
},
{
+'return_type' = 'global_score *',
+'name' = 'ap_get_global_scoreboard',
+'args' = []
+ },
+ {
'return_type' = 'unsigned long',
'name' = 'ap_get_limit_req_body',
'args' = [
@@ -3718,6 +3723,28 @@
},
{
'return_type' = 'int',
+'name' = 'ap_rgetline',
+'args' = [
+ {
+'type' = 'char **',
+'name' = 's'
+ },
+ {
+'type' = 'int',
+'name' = 'n'
+ },
+ {
+'type' = 'request_rec *',
+'name' = 'r'
+ },
+ {
+'type' = 'int',
+'name' = 'fold'
+ }
+]
+ },
+ {
+'return_type' = 'int',
'name' = 'ap_rind',
'args' = [
{
@@ -3999,7 +4026,7 @@
]
},
{
-'return_type' = 'void',
+'return_type' = 'int',
'name' = 'ap_run_open_logs',
'args' = [
{
@@ -4026,7 +4053,7 @@
'args' = []
},
{
-'return_type' = 'void',
+'return_type' = 'int',
'name' = 'ap_run_post_config',
'args' = [
{
@@ -6258,6 +6285,32 @@
]
},
{
+'return_type' = 'void',
+'name' = 'apr_dbm_get_usednames_ex',
+'args' = [
+ {
+'type' = 'apr_pool_t *',
+'name' = 'pool'
+ },
+ {
+'type' = 'const char *',
+'name' = 'type'
+ },
+ {
+'type' = 'const char *',
+'name' = 'pathname'
+ },
+ {
+'type' = 'const char **',
+'name' = 'used1'
+ },
+ {
+'type' = 'const char **',
+'name' = 'used2'
+ }
+]
+ },
+ {
'return_type' = 'char *',
'name' = 'apr_dbm_geterror',
'args' = [
@@ -6321,6 +6374,36 @@
},
{
'return_type' = 'apr_status_t',
+'name' = 'apr_dbm_open_ex',
+'args' = [
+ {
+'type' = 'apr_dbm_t **',
+'name' = 'dbm'
+ },
+ {
+'type' = 'const char*',
+'name' = 'type'
+ },
+ {
+'type' = 'const char *',
+'name' = 'name'
+ },
+ {
+'type' = 'apr_int32_t',
+'name' = 'mode'
+ },
+ {
+'type' = 'apr_fileperms_t',
+'name' = 'perm'
+ },
+ {
+'type' = 'apr_pool_t *',
+'name' = 'cntxt'
+ }
+]
+ },
+ {
+'return_type' = 'apr_status_t',
'name' = 'apr_dbm_store',
'args' = [
{
@@ -7265,6 +7348,24 @@
},
{
'return_type' = 'apr_status_t',
+'name' = 'apr_get_groupid',
+'args' = [
+ {
+'type' = 'apr_gid_t *',
+'name' = 'groupid'
+ },
+
cvs commit: modperl-2.0/xs/maps apr_functions.map
dougm 01/12/15 15:51:13 Modified:xs/maps apr_functions.map Log: adjust to apr_pool_create() change Revision ChangesPath 1.26 +1 -1 modperl-2.0/xs/maps/apr_functions.map Index: apr_functions.map === RCS file: /home/cvs/modperl-2.0/xs/maps/apr_functions.map,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- apr_functions.map 2001/10/22 01:52:06 1.25 +++ apr_functions.map 2001/12/15 23:51:13 1.26 @@ -141,7 +141,7 @@ apr_pool_cleanup_for_exec apr_pool_clear apr_pool_destroy - apr_pool_t *:apr_pool_create | mpxs_ | SV *:obj | new + apr_pool_t *:DEFINE_new | mpxs_apr_pool_create | SV *:obj apr_pool_userdata_get apr_pool_userdata_set apr_pool_alloc_init
