Get Unlimited Contributor Access to the all ExamTopics Exams!
Take advantage of PDF Files for 1000+ Exams along with community discussions and pass IT Certification Exams Easily.
Your solution is producing performance bugs in production that you did not see in staging and test environments. You want to adjust your test and deployment procedures to avoid this problem in the future. What should you do?
A.
Deploy fewer changes to production
B.
Deploy smaller changes to production
C.
Increase the load on your test and staging environments
D.
Deploy changes to a small subset of users before rolling out to production
Question Statement: You want to adjust your test and deployment procedures to avoid this problem in the future
So based on this, I think the option "C" is correct, since it is the only one talking about doing changes in the test environment.
C. Increase the load on your test and staging environments.
As you have pointed out in "Question Statement", I do not see C covering "deployment procedures". Test and Staging environment is more on testing, but not about deployment procedure to production.
So, the only option that cover test and deployment is D. (Yes, kind of unacceptable to have the users to do "testing", but we make it "ok" by calling it "canary deployment")
With canary deployment we expose the new version to a small portion of users. With this approach maybe we don't see performance bugs in the canary release, since we don't have the 100% of traffic on the canary. But when we migrate the 100% of traffic to the new release (previous canary) we can see performance bugs.
A wouldn't prevent the bugs, it would just avoid them. B would help with root-cause analysis because it'd be a smaller change to review. C would test the performance of the system at its peak processing rates, so this assumes the bugs in production only occur because of usage. D would allow you to test the new code against smaller user sets to see if it occurs then, and if it still does you know it is not because of more user responses. So it's a tossup between C and D, D would be the cheaper/quicker answer so I'd choose D first then C if it's because of usage.
According to the question, [Your solution is producing "performance" bugs in production], so I think it is about the load. Plus canary test will not reproduce the bugs related to high load, I vote for C
The question is about the performance of the existing Code that they did not detect in Test environments . This is not about new API release . In order to test the performance they should increase the load in test environment and hence answer C.
D. Deploy changes to a small subset of users before rolling out to production.
This approach, known as canary releasing or canary deployment, involves rolling out changes to a small group of users before deploying them to the entire user base. It is a very effective way to catch performance issues that might not have been apparent during testing.
C. Increase the load on your test and staging environments: This is definitely a good practice, as it can help simulate production-like conditions more closely. However, it may still not capture all real-world scenarios and user behaviors that can lead to performance issues.
Canary deployment is perfect to test new feature but to do stress testing, I do development for 25 years, when we want to resolve performance and scalability issues we do stress and load testing in pre prod environment, something you can't do by exposing the new feature to subset of users.
as for C: synthetic load may not cover all scenarios. For D obviously we need to have monitoring in place to see if e.g. system load or response times increased after canary deployment
I'm going for D. According to ChatGPT:
D. The best approach to avoid performance bugs in production that weren't detected in staging and test environments is to gradually roll out changes to a small subset of users before deploying them to production. This way, you can identify and address any issues that may arise in a controlled environment before affecting all users.
Why not C: Increasing the load on your test and staging environments, as suggested in option C, can be a valuable strategy for detecting certain types of performance issues related to scalability and load handling. However, it may not address all types of performance bugs or issues that are specific to the production environment.
A and B seem a bit obviously wrong. A is incorrect because it would be incompatible with CI/CD, and deploying fewer changes may still introduce bugs regardless of the low frequency. B would help root causing, but may also introduce new bugs that are exclusive to production.
From the question we don't know anything about reasons of performance problems in production environemnt. We also don't know anything about tests that were performed in test in staging environments. There is no reason to believe that load in test environment is not sufficient. It is always possible that some performance problems occurs only in production environment. It is also not economically reasonable to reproduce full production load in test environemnt. Taking all of this into account I am incling to answer D.
The question asks about test and deployment procedures and option D is the only option covering deployment as well. And deploying to small subset of user will cover the real time testing scenario as well. Seems Option D quite close.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
ghitesh
Highly Voted 4 years, 2 months agoUrban_Life
2 years, 3 months agoRegisFTM
2 years, 2 months agoVedaSW
3 years, 6 months agofrancescogugliottagm
5 months, 2 weeks agoEroc
Highly Voted 4 years, 5 months agonitinz
3 years agomichael_m
1 year, 7 months agomichael_m
1 year, 7 months agoSreekey
3 years, 7 months agoAzureDP900
1 year, 5 months agosantoshchauhan
Most Recent 2 weeks, 2 days agoPatrick2708
3 months, 2 weeks agoMahAli
3 months, 3 weeks agoMarekPL
3 months, 3 weeks agoPrakzz
5 months, 3 weeks agoyilexar
6 months agojrisl1991
6 months agoGregwaw
6 months agoduzapo
6 months, 3 weeks agoJohnny_K35
7 months agorescolar
7 months, 3 weeks agoDA95
9 months agoPKookNN
9 months, 1 week agooriori123123
9 months, 3 weeks agoAtanu
10 months ago