[You forgot to cc the list ]
On Sun, 20 Dec 2020 23:16:03 -0500
John Dunlap wrote:
> We run 20 customers on a single box and our database has approximately 500
> tables. We run hundreds or thousands of queries per second.
>
500 tables is a lot more than what I typically handle. I'm sure it c
[don't know why I'm seeing only parts of this thread, I did not get the
original messages for some reason]
> >> On Sun, Dec 20, 2020 at 2:28 PM John Dunlap wrote:
> >>
> >>> It's extremely inefficient by comparison. We host our application on
> >>> beefy servers with 32 cores and 64G of ram an
On Sun, 20 Dec 2020 14:03:35 -0600
Mithun Bhattacharya wrote:
>
> As for your Lets Encrypt certificate - autorenewal isnt a mod_perl thing
> rather you do have to place a script in some sort of scheduler.
I use Lets Encrypt on Debian, there is no need to place a script; certificates
are being a
Running individual functions in independent threads can't be a solution for
performance optimization - at least I have never heard such a thing, maybe
others can pitch in.
On Sun, Dec 20, 2020 at 4:15 PM John Dunlap wrote:
> I have no doubt that our application can be optimized. We do so wheneve
You would have to define poor system performance - are you doing anything
cpu intensive at all ? Maybe your RAM is being the bottleneck ?
On Sun, Dec 20, 2020 at 2:28 PM John Dunlap wrote:
> It's extremely inefficient by comparison. We host our application on beefy
> servers with 32 cores and 64
Your external facing apache instance would do the SSL part and use
mod_proxy to redirect the request to another instance of apache which
implements the actual functionality. Just remember the second instance
needs to run on a different port and that it doesnt have to talk to the
outside world.
Did
On Sun, Dec 20, 2020 at 11:29 Mithun Bhattacharya wrote:
> Just curious where exactly is the challenge in this setup ? It can't be in
> apache supporting real certificates - neither can it be in setting up
> reverse proxy internally...
>
The challenge to me is how exactly to code the reverse pro
Agreed prefork is recommended but what is the problem with that ?
On Sun, Dec 20, 2020 at 12:47 PM John Dunlap wrote:
> Our app segfaults at random of we use anything other than prefork.
>
> On Sun, Dec 20, 2020, 1:32 PM Mithun Bhattacharya
> wrote:
>
>> I am confused - you like threads so Perl
I am confused - you like threads so Perl is bad ? I am very happy forking
away and yes I work a lot with non thread safe DBI connections without any
issues.
On Sun, Dec 20, 2020 at 11:53 AM John Dunlap wrote:
> In my opinion, no one should build new projects in Perl. The world is
> increasingly
In my opinion, no one should build new projects in Perl. The world is
increasingly trending towards parallelism and higher numbers of cpu cores
and Perl is poorly positioned to leverage these advancements. Many of
Perl's dependencies are not thread safe and mod_perl forces you to use
mpm_prefork. M
Just curious where exactly is the challenge in this setup ? It can't be in
apache supporting real certificates - neither can it be in setting up
reverse proxy internally...
On Sun, Dec 20, 2020 at 11:19 AM Tom Browder wrote:
>
>
> On Sun, Dec 20, 2020 at 09:33 Steven Lembark wrote:
>
>> On Tue,
On Sun, Dec 20, 2020 at 09:33 Steven Lembark wrote:
> On Tue, 4 Aug 2020 18:05:28 -0700
> jbiskofski wrote:
>
> > I had a hard time accepting this was a good configuration because for
> > 20 years I had thought of webservers as big giant compiled systems
> > (apache), but apparently you can now
There are cases where Plack though isn't the solution and where mod_perl
written well is a far better (more stable) solution.
It is good when the backend servers are slow (simple not complex app); backend
requests are relatively fast, and don't use much memory.
But the warning
(1) If you have
On Tue, 4 Aug 2020 18:05:28 -0700
jbiskofski wrote:
> I had a hard time accepting this was a good configuration because for
> 20 years I had thought of webservers as big giant compiled systems
> (apache), but apparently you can now create something just as fast in
> Perl.
And a helluva lot easie
On Tue, 4 Aug 2020 19:59:01 -0500
Mithun Bhattacharya wrote:
> The question is move off to what ? I don't see alternatives being
> shared which blows an apache+mod_perl setup out of the water.
(Sorry for being late on this...)
There are a variety of servers using Plack which can handle heavy
l
15 matches
Mail list logo
