Performance tuning depends on which of these three is holding up the report:processing, Data retrieval, or rendering. You'll notice that the report will run those three tasks in that order, as well, and the report Time Out is based solely on the data retrieval portion. So, if it takes 2 minutes to process, 1 minute to retrieve, and your Time Out setting is set to 30 seconds, it'll spent 2 minutes to process first, then 30 seconds to begin and cancel retrieving.

You can check out statistics with the following query:

use ReportServer

select * from ExecutionLog2

The things to look at are TimeDataRetrieval, TimeProcessing, and TimeRendering relative to RowCount. For example, in my report I had 1 page group, 5 column groups, and 3 row groups, and detail level data. By far, the slowest performer was TimeProcessing, and it was an exponential grower (technically an order of 2 polynomial). I was able to go from 10 minutes total run time to 2 minutes by moving one of the column groups to a page group, so that it was: 2 page groups, 4 column groups, and 3 row groups. The report still displayed all of the data, but the performance increased significantly. I was able to pull 60K+ rows faster with this than I could pull 30K+ rows before (not that SSRS should be used to pull that much data).

If you're experiencing lag with TimeDataRetrieval, then tune your query, and eliminate things like order bys. If you're experiencing lag with TimeRendering, then go easy on the visuals.