Hello Dhruv,
There is no easy debugging solution for this behavior in Moodle. The reason is simple: the architecture of Moodle is based on cascading events.
When a user clicks in a module (follows a link - submits a post - adds a database record, ....), an event is fired. That's mostly the only thing that happens, so the user can continue working immediately. But in the background, during the first cron job, this event can generate some subtasks: if completion is enabled the activity has to be marked completed, if grading is used, the grades can be recalculated, .... But these subtasks work the same way: they do the task, but can fire other events and create sub-sub-tasks: if all activities are completed, the course has to be marked complete, a certificate can be generated and sent to the teacher/participant, a user can be enrolled into another course, .... But these tasks are only done during the second cron job, because they were not yet known during the first cron job. Every action by a Moodle user creates a cascade of events and tasks that are handled in the background, hence the delay.
All events have a priority when they arrive in the background todo queue. So technically it is possible to optimize these priorities for your specific Moodle installation. You could start lowering priorities for things that your site really doesn't use. But you can bet on it, in a week or two some teacher will start complaining that his course does "not work" any more.
R