So we have recently uploaded a new enviornment for our product
We are using python 3.8
Elastic beanstalk is of application type
This is my Auto Scaling group configuration
These are myscaling triggers configuration
I can see there are few spikes from the monitoring but these things were happening before also, at then we were not facing this issue
Is there something that I am missing in my confiuration, beacuse we have used exactly same configuration before and it was working fine. We have just updgraded from python 3.6 to python 3.8
Any help would be appreciated.
2
Answers
The configuration you posted seems not really optimal. I would suggest always running two instances minimum in a production environment. Also because you are scaling based on the ‘UnHealthyHostCount’ I would expect that in some cases, the unhealthy instance may have already reached its capacity limit, which means that it’s struggling to handle the current workload. Scaling up your application may help, but it won’t fix the underlying issues with the unhealthy instance. Therefore I don’t find it weird that it is slow. If you run always two instances I would think this could be solved without changing your scaling triggers.
If this was already your policy before it could also be that you have some special configuration which stopped working on upgrading which was not included in your question.
I can only give you some pointers on what could have happened when upgrading:
I also see that you upgraded not only to Python 3.8 but also from OS. On the changelog of ElasticBeanstalk its python platform I see that
Python 3.6was running onAmazon Linuxand not onAmazon Linux 2.I am not familiar with the Python platform but when I upgraded my PHP ElasticBeanstalk to
Amazon Linux 2. I needed to change alot of my.ebextensions. I used an Amazon Doc to migrate to Amazon Linux 2. In this doc there are also some platform specific considerationsYou should not exclude the possibility that the underlying hardware became unhealthy, slowed down the application, and then the auto-scaling added another EC2 instance. In other words, the cause and effect you infer in the title of the question, are reversed.