[PATCH] Proof-of-concept of a dual PHP–Python stack

Lukas Fleischer lfleischer at archlinux.org
Sun Mar 15 12:25:31 UTC 2020

On Fri, 13 Mar 2020 at 14:13:56, Frédéric Mangano-Tarumi wrote:
> Lukas Fleischer [2020-03-11 19:44:37 -0400]
> > Thanks! I like the approach. I wonder what the performance impact of
> > always querying the Python backend first would be, though, especially at
> > the beginning when most requests are expected to yield a 404.
> One way or the other, I don\u2019t think it\u2019s worth worrying about since most
> 404 consist of accessing a local socket and exchanging a few KB. Hardly
> any disk or database access is performed. Best way to be sure is to
> measure it under load though. Are the AUR servers often overloaded?

Being overloaded is a relative term. Yes, the AUR servers are often
under heavy load, with millions of requests every day.

> > Alternatively, would it make sense to use multiple location blocks and
> > use the right upstream based on matching the path against a predefined
> > set of patterns? It would add some additional maintenance work but since
> > the overall plan is to migrate everything to Python eventually, it would
> > exist only temporarily.
> I couldn\u2019t find a smart way to do it without turning it into a
> maintenance burden. Beside, I can\u2019t see any advantage over the fallback
> approach, except a performance speedup which I believe would be
> irrelevant.

Fair enough. We can always keep it in mind as an alternative solution in
case there are any issues with the fallback approach.

I also wonder whether we should ever use version with two backends in
production. It might make sense to only switch over once the port has
been completed.

> > For an actual first patch to be merged, I suggest porting the RPC
> > interface which is rather small and largely independent from other parts
> > of the code.
> Sure! But first, are there other approaches you would like to try out
> before we begin the serious work?

Your proposal makes the rewrite relatively easy, has low overhead and at
least one other person actively working on the rewrite (I briefly
discussed it with Filipe) likes it. Unless somebody else wants to
suggest an alternative approach here, I think we're good to go!

> Also, I\u2019d like to make a proposal about regression testing to limit the
> best we can potential bugs introduced by the rewrite.


More information about the aur-dev mailing list