OP here. Seeing as this question is getting asked
a lot, I'll edit something into the post, but I wanted to answer you here as well.
So, there are a few problems with this technique.
1. It ignores the local timing leak
An attacker who can get code running on the server (shared hosts for example), can carefully monitor the CPU usage to see when the process is actually doing work, vs when it sleeps. So really, its not hiding anything.
2. The resolution of the sleep call is WAY too high. We're talking about detecting differences down to 15 nanoseconds. Sleeping for blocks of microseconds or even milliseconds will be far to granular. It will introduce block-like patterns in the requests that should be pretty easy to detect with statistical means.
3. It's basically identical to a random delay. Considering it depends on the system clock, and the original request comes in at a random point, it's functionally identical to calling sleep(random(1, 100)). And over time (many requests), that will average out.
Now, what if we took a different approach. What if we made the operation fixed-time?
execstart = utime()
// whatever code
// clamp to always take 500 microseconds
sleep( 500 - utime() - execduration)
That
might work (assuming you have a high enough resolution sleep function). Again, it suffers the local attacker problem (which may or may not matter in your case).
However, there are two reasons I wouldn't recommend it: It requires guesswork and idle CPU.
You would either need to actively guess every single operation (and remember to clamp it) or clamp the overall application.
If you do it for every operation, that sleep time can become expensive (if you have a lot of them).
If you do it on the application level, and if you do too little, an attacker can use other expensive control (like larger input introducing memory allocation latency) to increase the runtime past the sleep clamp (hence allowing them to attack the vulnerability anyway). If you do too much, the attacker can leverage it to DOS your site (since even a sleeping process is non-trivially expensive).
There are two valid ways of protection IMHO:
1. Make sensitive operations actually constant time.
2. Implement strong IP based protections to prevent the large amount of requests that would be needed to collect enough data to analyze noisy environments. (I need to add this to the post now that I write it).
Personally, you should be doing #2 anyway. But since I also believe in defense-in-depth, I'd do #1 as well.