Mailing List Archive

On 22.07.2016 11:00, yhpeng@orange.fr wrote:
> Hello,
>
> We have some handlers which were written by modperl for API endpoints.
> yes developing a apache handler with modperl is so easy and quick.
> but for better performance we also consider the C handler.
> (one of the APIs has got 1,500,000 accesses by unique clients)
> Do you think if it's valuable to change the handler from modperl to pure C? for C coding
> we have to take more time to develop, debug and maintain.
>

You have asked the question, and partially answered it yourself.
(Just ad the fact that to use mod_perl, means having a perl interpreter in each of your
Apache httpd children processes, which is a significant memory overhead).

Ask yourself also if you need perl in Apache for anything else than these "some" handlers.
If you do, then you have to keep perl anyway, and you would not gain anything (in terms of
memory) by moving your handlers to C.

As to the overall question, nobody can answer this but yourself.

My company runs a bunch (dozens, not hundreds) of websites for customers, under
Apache/mod_perl, since many years. The applications are customised and quite
sophisticated, but the individual traffic on each website is moderate (not millions per
day like you).

Over these many years, we have found mod_perl *invaluable* in terms of the flexibility and
rapid development that it provides to us, to accomodate a wide range of ever-changing
customer requirements in terms of data-entry, user authentication, input and output
filtering, etc. etc.
(and not least, the availability of CPAN modules, to achieve almost anything you can dream
of).
So we would not even dream of doing without mod_perl or something at least equivalent; and
there /is/ nothing else really equivalent under Apache httpd, when it comes to interacting
more deeply with the HTTP request/response cycle than just running some CGI scripts.

But if your applications are different (more standard and stable over time e.g.), then
maybe you can squeeze some additional performance by converting all or some of your
handlers to C. But again, you have to decide that for yourself.


I believe that it is maybe the "drama" of mod_perl : it is so powerful, and so flexible,
that you kind of get used to it and blasé. Using it, nothing to do with HTTP seems
impossible anymore, and nothing requires very large resources or a lot of time to do.
Consequently, a development team using mod_perl does not need to get very large, to
achieve quite complex things and keep them running. And consequently, such teams tend to
remain small and have small budgets, which does not give them (or mod_perl) a very high
profile.

To get back to your question, maybe there is an intellectual experiment that you can do :
Imagine that tomorrow, you get a new management directive, saying that within 6 months all
usage of perl and mod_perl on your websites needs to be stopped.
And try to figure out what this would cost, in terms of finding alternatives,
implementing them and maintaining them over time.

yes I totally agree with you, modperl is also perl, it has the big
advantage of using CPAN. for example, we have used these modules in the
project,

Data::Validate::Domain
Data::Validate::Email
Data::Validate::IP

I don't think they are easy to port into C language.
So perl is great, modperl is powerful.

regards.

On 2016/7/22 17:53, André Warnier (tomcat) wrote:
> On 22.07.2016 11:00, yhpeng@orange.fr wrote:
>> Hello,
>>
>> We have some handlers which were written by modperl for API endpoints.
>> yes developing a apache handler with modperl is so easy and quick.
>> but for better performance we also consider the C handler.
>> (one of the APIs has got 1,500,000 accesses by unique clients)
>> Do you think if it's valuable to change the handler from modperl to
>> pure C? for C coding
>> we have to take more time to develop, debug and maintain.
>>
>
> You have asked the question, and partially answered it yourself.
> (Just ad the fact that to use mod_perl, means having a perl interpreter
> in each of your Apache httpd children processes, which is a significant
> memory overhead).
>
> Ask yourself also if you need perl in Apache for anything else than
> these "some" handlers.
> If you do, then you have to keep perl anyway, and you would not gain
> anything (in terms of memory) by moving your handlers to C.
>
> As to the overall question, nobody can answer this but yourself.
>
> My company runs a bunch (dozens, not hundreds) of websites for
> customers, under Apache/mod_perl, since many years. The applications
> are customised and quite sophisticated, but the individual traffic on
> each website is moderate (not millions per day like you).
>
> Over these many years, we have found mod_perl *invaluable* in terms of
> the flexibility and rapid development that it provides to us, to
> accomodate a wide range of ever-changing customer requirements in terms
> of data-entry, user authentication, input and output filtering, etc. etc.
> (and not least, the availability of CPAN modules, to achieve almost
> anything you can dream of).
> So we would not even dream of doing without mod_perl or something at
> least equivalent; and there /is/ nothing else really equivalent under
> Apache httpd, when it comes to interacting more deeply with the HTTP
> request/response cycle than just running some CGI scripts.
>
> But if your applications are different (more standard and stable over
> time e.g.), then maybe you can squeeze some additional performance by
> converting all or some of your handlers to C. But again, you have to
> decide that for yourself.
>
>
> I believe that it is maybe the "drama" of mod_perl : it is so powerful,
> and so flexible, that you kind of get used to it and blasé. Using it,
> nothing to do with HTTP seems impossible anymore, and nothing requires
> very large resources or a lot of time to do.
> Consequently, a development team using mod_perl does not need to get
> very large, to achieve quite complex things and keep them running. And
> consequently, such teams tend to remain small and have small budgets,
> which does not give them (or mod_perl) a very high profile.
>
> To get back to your question, maybe there is an intellectual experiment
> that you can do : Imagine that tomorrow, you get a new management
> directive, saying that within 6 months all usage of perl and mod_perl on
> your websites needs to be stopped.
> And try to figure out what this would cost, in terms of finding
> alternatives, implementing them and maintaining them over time.
>
>
>

I think it really depends on what the handler is doing. If it is mainly
executing some db queries rewriting it in C won't make much of a
difference. If the handler is doing some expensive computation it might
be worth it. Before you rewrite the whole handler though you should look
at the option of just implementing the expensive parts and using
XS-bindings to load them into the perl handler. That is actually what we
did: implementing expensive parser logic that rarely changes in C and
calling it from perl while leaving the often-changing business logic in
perl. We also catch the most frequently used calls in the nginx reverse
proxy and use lua there to fast-track them.

In the end it is always a trade-off between performance and
maintainability so optimizations like that should only be done on a very
limited scope.

Hendrik


Am 22.07.2016 um 11:53 schrieb André Warnier (tomcat):
> On 22.07.2016 11:00, yhpeng@orange.fr wrote:
>> Hello,
>>
>> We have some handlers which were written by modperl for API endpoints.
>> yes developing a apache handler with modperl is so easy and quick.
>> but for better performance we also consider the C handler.
>> (one of the APIs has got 1,500,000 accesses by unique clients)
>> Do you think if it's valuable to change the handler from modperl to
>> pure C? for C coding
>> we have to take more time to develop, debug and maintain.
>>
>
> You have asked the question, and partially answered it yourself.
> (Just ad the fact that to use mod_perl, means having a perl
> interpreter in each of your Apache httpd children processes, which is
> a significant memory overhead).
>
> Ask yourself also if you need perl in Apache for anything else than
> these "some" handlers.
> If you do, then you have to keep perl anyway, and you would not gain
> anything (in terms of memory) by moving your handlers to C.
>
> As to the overall question, nobody can answer this but yourself.
>
> My company runs a bunch (dozens, not hundreds) of websites for
> customers, under Apache/mod_perl, since many years. The applications
> are customised and quite sophisticated, but the individual traffic on
> each website is moderate (not millions per day like you).
>
> Over these many years, we have found mod_perl *invaluable* in terms of
> the flexibility and rapid development that it provides to us, to
> accomodate a wide range of ever-changing customer requirements in
> terms of data-entry, user authentication, input and output filtering,
> etc. etc.
> (and not least, the availability of CPAN modules, to achieve almost
> anything you can dream of).
> So we would not even dream of doing without mod_perl or something at
> least equivalent; and there /is/ nothing else really equivalent under
> Apache httpd, when it comes to interacting more deeply with the HTTP
> request/response cycle than just running some CGI scripts.
>
> But if your applications are different (more standard and stable over
> time e.g.), then maybe you can squeeze some additional performance by
> converting all or some of your handlers to C. But again, you have to
> decide that for yourself.
>
>
> I believe that it is maybe the "drama" of mod_perl : it is so
> powerful, and so flexible, that you kind of get used to it and blasé.
> Using it, nothing to do with HTTP seems impossible anymore, and
> nothing requires very large resources or a lot of time to do.
> Consequently, a development team using mod_perl does not need to get
> very large, to achieve quite complex things and keep them running.
> And consequently, such teams tend to remain small and have small
> budgets, which does not give them (or mod_perl) a very high profile.
>
> To get back to your question, maybe there is an intellectual
> experiment that you can do : Imagine that tomorrow, you get a new
> management directive, saying that within 6 months all usage of perl
> and mod_perl on your websites needs to be stopped.
> And try to figure out what this would cost, in terms of finding
> alternatives, implementing them and maintaining them over time.
>
>
>