The Queue screen lists the samples that are queued for a step, and provides a table from which samples are selected for placement into the Ice Bucket.
By default, samples listed in the Sample table are grouped by container. Groups are collapsed by default and can be expanded as required by selecting the arrows.
Lab scientists can also choose to group samples by project, submitted sample, or previous step.
In the past, some performance and usability issues were encountered when viewing large data sets in the Queue screen. Clarity LIMS now includes performance enhancements that speed up the Sample table loading time, allowing users to more quickly interact with the data.
Clarity LIMS development teams measured the performance for various samples that are queued for a step with the Time to Interactive (TTI) metric. This metric defines the time it takes for a page to become fully interactive and for functionality to start working (eg, selecting, scrolling, and so on). The metric numbers vary based on the following information:
Server specification.
Amount of data stored on the server database.
Client hardware specifications and the browser type used to access Clarity LIMS.
Network conditions between the server and client.
The following table shows the server and client specifications used for the performance test.
The different client types are used to demonstrate the different setups.
| Hardware | Specification | Additional Notes |
|---|---|---|
The following tables show the results of two performance tests conducted on a Clarity LIMS system on which performance enhancements had been implemented. In both tests, samples were grouped by container.
The tables show how the usability rating changes as the number of samples in the queue increases.
Test 1 Performance Results
Test 2 Performance Results
The demultiplexing API endpoint is an extension of the existing artifact endpoint. This endpoint demultiplexes artifacts recursively to all individual derived samples that they represent.
For more information, see the Clarity LIMS API documentation.
In the past, some may have experienced performance and usability issues when demultiplexing large data sets. Clarity LIMS now includes the demultiplexing API endpoint, resulting in performance enhancements that speed up demultiplexing and allow quicker interaction with the data.
While acknowledging that usability is subjective, the Clarity LIMS product and development teams have established usability ratings based on criteria that measure how lab scientists must wait before they can interact with a feature on the screen. These criteria also allow for the comparison of performance and usability across the various screens of Clarity LIMS.
In the following table:
Successful user interaction means that a feature can begin to be interacted with (ie, it can be selected, scrolled, moved, and so on).
Numbers are provided for guidance only, and differ depending on the RAM and CPU speed of the computer used to view the page.
| Usability Rating | Criteria |
|---|
The following table shows how the usability rating changes as the number of samples in the pool undergoing demultiplexing increases.
| Usability Rating | # Samples |
|---|
| Number of Samples | Response Time (seconds) - Client Type A Response Time (seconds) - Client Type B 1000 | Response Time (seconds) - Client Type B |
|---|---|---|
| Number of Samples | Response Time (seconds) - Client Type A Response Time (seconds) - Client Type B 1000 | Response Time (seconds) - Client Type B |
|---|---|---|
Server
3.1 GHz Intel Xeon Platinum processor (8-core)
32 GB RAM
Oracle Linux v8.8
PostgreSQL 15.2 database
The server database is loaded with the following information:
200,000 submitted sample records
2,000,000 derived sample records
500 projects
Client A
3.1 GHz Intel Xeon Platinum processor (8-core)
32 GB RAM
Access Clarity LIMS within the same network in the lab.
Client B
2.3 GHz Intel Core i9 (8-core)
32 GB RAM
Access Clarity LIMS on the cloud. The VPN access and different network region setup results in high network latency and demonstrates the worst case for performance.
1000
2.0
4.5
3000
2.5
5.0
7000
3.5
6.5
10,000
5.0
7.5
15,000
7.0
10.5
20,000
9.0
12.5
1000
2.0
4.5
3000
3.0
5.5
7000
5.0
7.5
10,000
7.0
9.5
15,000
9.5
12.5
20,000
12.5
15.0
Good | A successful user interaction (data load) in ~ 2 seconds |
Reasonable | A successful user interaction (data load) in ~ 6 seconds |
Acceptable | A successful user interaction (data load) in ~ 9 seconds |
Degraded | A successful user interaction (data load) in ~ 20 seconds |
Unusable | A subjective limit to usability |
Good | 2200 - 2400 |
Reasonable | 3400 - 3600 |
Acceptable | 4600 - 5800 |
Degraded | 7200 - 7400 |