3 ms·
This (or some of it) seems like “shot in the dark” engineering where the author finds an error condition and instead of doing the work of finding root causes si
by mapgrep 6y ago
This (or some of it) seems like “shot in the dark” engineering where the author finds an error condition and instead of doing the work of finding root causes simply twiddles some values until things work.
For example, a 21MB upload with a 72MB INSERT statement (100k messages inserted) fails but a 5MB upload with 30MB INSERT statement (40k messages inserted) works so author just limits to the smaller values and calls it a day. But clearly the new limits are still near the edge of the performance envelope and without knowledge of root cause of the error how do they know the error won’t resurface under different conditions (more load on server, less ram allocated to db, congested network, fuller disk)? How do they know a config change from an upgrade or from a fix to another problem won’t lead to another failure?
It saddens me to know in my gut that a lot of what passes for engineering happens this way. This is not proper debugging.
- alexbanks 6y agoTraining and culture are probably the biggest failures here, I think. Most devs are only equipped to add many print statements to things in terms of debugging, and most companies/dev leads/managers are very comfortable allowing arbitrary half-checked solutions to bugs or performance issues instead of actually understanding the problem.
- slimsag 6y ago> and most companies/dev leads/managers are very comfortable allowing arbitrary half-checked solutions Not really true - they just don't have _any_ grasp on the problem aside from "Yeah I thought you were working on that last week, are you stuck on it? Why is it taking so long? - Oh so you do have a fix that works, cool so how soon can that be merged?" Almost all of these types of situations lead back to miscommunication or someone in the discussion just not caring.
- alexbanks 6y agoYeah I disagree with your statement a lot, but YMMV.