Timeline for How would you identify slow queries before reaching production?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 18, 2024 at 15:44 | comment | added | Steve | @James_pic, my counsel in this OPs context (where there are already extensive tests covering the usual matters) is to plan to react, and plan for the need for reaction time. I don't think you've taken me seriously when I say many problems are practically impossible to test for, not just hard. | |
| Jan 18, 2024 at 11:56 | comment | added | James_pic | It's true that these problems are hard, but that's not a reason not to try. Developing a performance test suite and making continual improvements to it based on experience can at least mean you transition from always dealing with issues reactively to sometimes being able to be proactive. | |
| Jan 18, 2024 at 3:46 | comment | added | LoztInSpace | All true, but the most common performance problems I see post-go live are a) Missing indexes, b) bad queries "fixed" with DISTINCT, implicit conversions between varchar, nvarchar and numerics. All the queries work but with a realistic data set and monitoring you can catch them pre-production regardless of query plan. Their very nature means they will be crap. | |
| Jan 16, 2024 at 11:04 | comment | added | Steve | @PhilipKendall, I don't suggest any resolution to their issue in their terms, but rather that the OP accept that databases are incapable of being thoroughly covered by tests, and instead accept that they need both expert development who are capable of heuristically avoiding problems, and continued oversight to react to problems as they are discovered in use. | |
| Jan 16, 2024 at 10:35 | comment | added | Philip Kendall | This is a bunch of facts, but what would you actually suggest the OP does to resolve their issue? | |
| Jan 16, 2024 at 10:31 | history | answered | Steve | CC BY-SA 4.0 |