There are two reasons that reports will run slower relative to each user id they are used against.
1: Because on one user is a admin, and the other is not:
The way we run a Full log detail report, from the admin account, is slightly different to non-admin Role based users. On the non-admin, Role Based, user the first action taken to search the database for the reporter data is to search for the groups he is linked to by the Role he is in. Each log line, that contains this group name, is then used to run the report. With the Admin user, no such group filtering is done, with the Full Log detail report manifesting in less time. In other words, the non-admin Role is forced to search twice for the same data.
Workaround: Bluecoat Recommends pruning a base report on the groups (as shown in the below screen shot) to find out which date each group has data in the database for. Before running base report, select report option and you have to summarize by group and add another level as day(trend->day). This will show you what date each group has data for. Then, based on these result, you can generate the full log detail report, but filter on these dates, which should significantly speed up report generation times.
2: The data collected for each unique non-admin user is different.
The time taken to generate a report is heavily dependent on the type of data in your database. For example, each user can have a slightly different view of the data in the database, dependent on when that user exists in the database and/or when it's group filter exists.
- Lets say we have user A and user B
- Lets say we have log set data from January through March
- Lets say the data has logs containing entries for user A only in January and entries for user B only in March.
- When user A runs the report, the report generates quickly, because Report find the first entry matching the filter for user A early. The moment Reporter finds enough number of matching rows [number of rows to display per page], it returns the partial result to the UI. User perceives that the report generation has completed, when in fact only the first set of results have been found. Reporter continues to generate rest of the report in the background.
- When user B runs the report, then it takes much longer because Reporter has the go through the logs of Jan, Feb and March before it finds the first entry matching the filter for user B. User B perceives that the report generation is slow, because the number of matching rows required to be sent to UI [number of rows to display per page] are found only when reporter processes the data for month of March
in Summary, although actual time taken for completely generating the report is same for both users, the experience is different. While both users have to troll the entire database dates, it is perceived that one user generates the report faster than the other