| | 17 | |
| | 18 | == Caveats == |
| | 19 | |
| | 20 | S3Report supports grouping and aggregation by virtual fields - however, using this without care can lead to severe scalability problems: |
| | 21 | |
| | 22 | With large numbers of records involved it can take a long time to compute all virtual field values - and especially where this involves additional database lookups it may quickly exhaust any available bandwidth. Example calculation: |
| | 23 | |
| | 24 | ||Records in the table||Number of virtual fields with DB lookups||Concurrent users||Total number of queries|| |
| | 25 | ||1,000||1||1||1,001|| |
| | 26 | ||1,000||5||1||5,001|| |
| | 27 | ||30,000||5||1||150,001|| |
| | 28 | ||30,000||5||5||750,005|| |
| | 29 | ||30,000||5||100||15,000,100|| |
| | 30 | |
| | 31 | Unless you're running on a super-computer, such a scenario would take your site beyond any reasonable response times - and users may end up waiting forever to get their report (make sure your site has a reasonable timeout for requests). |
| | 32 | |
| | 33 | Without virtual fields, you have a very different scenario: |
| | 34 | |
| | 35 | ||Records in the table||Number of virtual fields with DB lookups||Concurrent users||Total number of queries|| |
| | 36 | ||1.000||0||1||1|| |
| | 37 | ||30,000||0||100||100|| |
| | 38 | |
| | 39 | Therefore, it is strongly recommended to minimize the use of virtual fields which include additional DB lookup as rows, cols or fact parameter in reports wherever large numbers of records can be expected. |
