Operations will soon be upgrading our log server to SSDs (solid state drives), which are much faster than traditional hard disks and should improve our log server performance considerably.
Meanwhile, if someone else is already running their own Transaction Log query with a huge number of results, that can bog down the log server for everyone else until their query returns all of the results they requested. When this happens, it's just a matter of waiting for that query and all the ones waiting in line behind it to wrap up. Whenever you run any custom log queries (besides the default past-30-days list you get upon first opening your log), we recommend choosing your query criteria to be as narrow/specific as possible -- e.g., don't query the log for the maximum possible date range when you know you're really only interested in transactions from a narrower time frame.
Early in the year up to Tax Day, our log server tends to get hammered pretty hard by people running annual reports on their past year's sales for tax/accounting purposes, so it may help to try again later in the evening when demand is off peak. We'd also recommend relying on your payment processor logs (e.g. PayPal History) as your primary source for revenue figures, as all of the data in our Transaction Logs are "secondhand" and only as accurate and complete as what your payment processor(s) report to us -- refunds/reversals in particular can cause a discrepancy, as most of our supported payment services don't report those to us at all, and PayPal's refund/reversal reporting is inconsistent, often resulting in adjusted price figures with oddball remainder amounts for affected transactions at our end.
