The basic essence of a timing attack is to send a server different data samples and see if different inputs produce different code paths by looking at how much time was taken to process the input. The best defense against timing attacks is to keep the code on the same execution path regardless of the input.
This is far easier said than done. A simple function like
memcmp() does not guarantee the same code path because it exits after the first byte mismatch; different inputs will cause it to exit from different points. A natural response is to write a custom
memcmp()-esque function, but doing so is not straight forward either.
The biggest issue is how errors and validation are handled. Regardless of preprocessing/validation/sanity-check errors, the same code should be executed even if you realize the output will be thrown away later. When you look at practical timing attacks, an example that pops up frequently is varying time for MAC validations. The timing of raw cryptographic primitives aren't really a concern; the bit-mangling operations of something like AES or SHA2 will take the same amount of time regardless of what input strings they get. The main focus should be on how errors, special cases, and data comparisons are handled.
A fixed amount of wall time for an operation isn't necessarily the best defense; the attacker may be able to bypass it by crafting the input to make the operation time right at the threshold of your constant wall time increments and then see which operations push the operation over the threshold. The ideal approach in most situations is to execute the exact same code regardless of the input.
However, we don't know your exact situation and the exact information you are trying to keep confidential, so the above is generic. For example, the approach of keeping code execution the same will leak information about the quantity of data being processed and we don't know if that is a concern for you. In many cases the attacker already knows the data's size (because they supplied it), but we don't know if that's a problem here.