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, yhp...@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.
