Re: write handlers with C or modperl?

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, [email protected] 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.
>
>
>