[PATCH] Proof-of-concept of a dual PHPâPython stack
lfleischer at archlinux.org
Sun Mar 15 16:16:38 UTC 2020
On Sun, 15 Mar 2020 at 09:16:52, Frédéric Mangano-Tarumi wrote:
> Lukas Fleischer [2020-03-15 08:25:31 -0400]
> > Being overloaded is a relative term. Yes, the AUR servers are often
> > under heavy load, with millions of requests every day.
> To get more concrete: are the AUR servers sometimes at 100% CPU
> capacity, or do they hardly ever reach the point of saturation? In other
> words, can we afford a 1% slowdown? What about 10%?
We are in the process of getting a new machine for the AUR and will be
scaling up whenever we are reaching resource limits. So, practically, we
will never reach full utilization unless we're running out of money.
However, it might be better to think of optimizations as tradeoffs
between total time invested and the optimization benefits (reduction in
running expenses, knowledge acquisition of the person implementing the
As I mentioned before, I am fine with trying your fallback approach
first and possibly optimizing later.
Your explanation of the performance hit being relatively small sounds
reasonable but a few simple experiments would be even better.
> > It might make sense to only switch over once the port has been
> > completed.
> I strongly recommend against that.
> First, not deploying the Python backend implies we keep developing the
> PHP stack too, which in turn means we either need to stop developing
> new features, or develop them twice.
It also depends on how long the port will take. We should certainly
prioritize the port and try to defer any feature additions for the time
> Second, deploying a wholly different codebase at once is dreadful for an
> actively used website. All the bugs introduced by the rewrite would pop
> up simultaneously. This is all the more risky if we decide to adjust
> features as we rewrite them. Debugging may also become harder if we
> can\u2019t narrow down the commits based on the date the bug appeared. By the
> way, I think we should for that reason accelerate the release cycle when
> we start porting code.
That's a good point. I agree that introducing the rewrite gradually is a
More information about the aur-dev