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 change, ...) 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 being.
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 good idea.