As an environment manager supporting your firm’s Relativity instance, it’s your job to ensure users are able to access the system efficiently and work effectively. Let’s say that, today, your litigation support specialists are experiencing poor viewer performance, and you want to get to the bottom of it. You decide to run the Relativity bandwidth tester from the viewer window on their workstation to test latency, download, and upload speeds. Now what?
If after performing all three tests you’re unsure how these results compare with other users’ results or whether they would be consistent throughout the day or week, there are additional tools available to help you learn more about viewer performance.
The first is the web client performance table ([EDDS].[eddsdbo].[WebClientPerformance]). This table includes performance data that the Relativity viewer automatically logs at regular intervals. It can help you identify which users are experiencing issues with the Relativity viewer, and it looks like this:
In this table, DownloadBytes is the total bytes downloaded during the StartTime and EndTime interval, and DownloadMilliseconds is how long the downloads took. Latency is the amount of time that the WebAPI takes to respond to an HTTP request; in other words, it’s the length of time from when the request is made until the response is received by the viewer. This is a point-in-time sampling with no relationship to the prior columns. Every 15 minutes that a user is in the viewer, it checks the latency at that time; it is not an average.To find averages and totals for this data, try the below script. It uses the web client performance table to gather average latency and bytes per millisecond for each user since a specified time—in this case, November 1, 2014.
--AverageLatency (lower average total latency is better)
SELECT UserArtifactID, AVG(CAST(Latency AS BIGINT)) as AverageTotalLatency
FROM [EDDS].[eddsdbo].[WebClientPerformance](NOLOCK)
WHERE StartTime >= ‘2014-11-01 00:00:00.000'
GROUP BY UserArtifactID
ORDER BY AverageTotalLatency DESC
--BytesPerMillisecond (higher bytes per millisecond is better)
SELECT UserArtifactID,
SUM(CAST(DownloadBytes AS BIGINT)) as TotalDownloadBytes,
SUM(CAST(DownloadMilliseconds AS BIGINT)) as TotalDownloadMilliseconds,
SUM(CAST(DownloadBytes AS BIGINT)) / SUM(CAST(DownloadMilliseconds AS BIGINT)) as BytesPerMillisecond
FROM [EDDS].[eddsdbo].[WebClientPerformance](NOLOCK)
WHERE StartTime >= ‘2014-11-01 00:00:00.000'
GROUP BY UserArtifactID
ORDER BY BytesPerMillisecond ASC
After running the script, you’ll get something like the following:
We can see in the above example output that the tables match up well for users with the best viewer performance. The two tables include one for average total latency for each user artifact ID (sorted by average total latency), and one for total download bytes, total download milliseconds, and bytes per millisecond for each user artifact ID (sorted by bytes per millisecond). Highlighted are users with the lowest average latency and fastest viewer download speeds. With this information, you may begin to see performance trends among certain groups, such as remote users accessing Relativity from different cities or users connected via terminal services.
The below scripts can be updated to join on the user table ([EDDS].[eddsdbo].[User]) to map user names or email addresses to the user artifact IDs:
--AverageLatency (lower average total latency is better)
SELECT UserArtifactID, EmailAddress, AVG(CAST(Latency AS BIGINT)) as AverageTotalLatency
FROM [EDDS].[eddsdbo].[WebClientPerformance] (NOLOCK)
INNER JOIN [EDDS].[eddsdbo].[User] (NOLOCK)
ON [EDDS].[eddsdbo].[User].[ArtifactID] = [EDDS].[eddsdbo].[WebClientPerformance].[UserArtifactID]
WHERE StartTime >= ‘2014-11-01 00:00:00.000'
GROUP BY UserArtifactID, EmailAddress
ORDER BY AverageTotalLatency DESC
--BytesPerMillisecond (higher bytes per millisecond is better)
SELECT UserArtifactID, EmailAddress,
SUM(CAST(DownloadBytes AS BIGINT)) as TotalDownloadBytes,
SUM(CAST(DownloadMilliseconds AS BIGINT)) as TotalDownloadMilliseconds,
SUM(CAST(DownloadBytes AS BIGINT)) / SUM(CAST(DownloadMilliseconds AS BIGINT)) as BytesPerMillisecond
FROM [EDDS].[eddsdbo].[WebClientPerformance] (NOLOCK)
INNER JOIN [EDDS].[eddsdbo].[User] (NOLOCK)
ON [EDDS].[eddsdbo].[User].[ArtifactID] = [EDDS].[eddsdbo].[WebClientPerformance].[UserArtifactID]
WHERE StartTime >= ‘2014-11-01 00:00:00.000'
GROUP BY UserArtifactID, EmailAddress
ORDER BY BytesPerMillisecond ASC
After running this script, you’ll get something like the following:
We can see in the above example output that the users email addresses are now included.
It’s worth noting that the new HTML 5 viewer in Relativity 9 does not currently write to this table. However, the Active X viewer is still available in Relativity 9 and can be enabled per environment or per user. The ActiveX control’s behavior with respect to writing to the web client performance table is the same as it was in Relativity 8.2 and prior. See the Relativity Administrator Manual in the Customer Portal for more information regarding this setting.
Relativity 9 introduced a zero-footprint viewer, meaning there are no downloads, plug-ins, or installations required to get to work in Relativity. The files are now converted on the server side instead of the client. This allows us to support the latest versions of Internet Explorer, Safari, and Chrome. Since files are now converted server-side, we introduced a new logging mechanism and store the data in a new table called the ConvertedCacheFile table.Included in this new table is an XML column called Details that currently tracks three things:
- The version of the third-party component used to do the conversion (for natives, Oracle WebExport; for images/productions, PDFNet SDK).
- The ID of the user who kicked off the conversion.
- The amount of time the third-party component(Oracle or PDFTron) spent converting, in milliseconds.
Using XML allows us to add more to this column in the future.
You can determine the size and type of files converted by joining back to the Document and File tables. This information can be useful in analyzing how long the system takes to convert and cache files for review. You can optionally filter on specific file types or other data points and trend these numbers over time to see how the system performs as you scale.
These tables help provide insight into viewer performance and the user experience. They can be useful in diagnosing issues and identifying problem areas.
As always, feel free to contact us if you have any questions.
