The task you need to do with comments is to tell future readers WHY you do things as you do. The HOW is told by the actual code, but there is a limit to what you can say.
For instance, good candidates to comments are WHY you chose to implement a specific sort routine instead of just using the one in the runtime library. You might know that the swap-element routine is very, very slow (perhaps because it works directly on storage media) so you have chosen an algoritm that reads all elements, figure out where they go, and swap each of them exactly once into their right location, perhaps even in the right order to minimize disk access. This is important information and future maintainers need to know. A comment - even a small one - will tell them that there is a good reason for it being like that.
This implies that the more telling your code can be - which is one of the benefits of refactoring - the less commenting you need to do. This again mean that the amount of commenting depends on the code, so absolute numbers cannot be given.
My rule of thumb is "What would I really like to know when looking at this code in a year or two?" and then put that in. Plus some more.