Performance, limites et pagination décalée

Authentication Error Limits

Après 40 tentatives d'authentification échouées à partir de la même adresse IP en moins de 2 minutes, l'adresse IP du demandeur sera bloquée pendant 2 heures. Toutes les demandes d'authentification seront bloquées.

Le soutien client et DevOps de TrackTik peut être contacté pour que l'interdiction d'IP soit levée plus tôt que la fenêtre de 2 heures.

Default Number of Items Returned

Par défaut, si aucun nombre d'éléments de résultat n'est demandé avec un paramètre de filtre, 100 éléments seront renvoyés.

Maximum Number of Returned Items

The maximum number of returned items is 1000, and you can request up to it using the limit filter:

[GET] /zone-clients?limit=1000

"meta": {
       "count": 3357,
       "request": [
           "zone-clients"
       ],
       "itemCount": 1000,
       "security": {
           "granted": true,
           "requested": "admin:zone-clients:view",
           "grantedBy": "admin:*",
           "scope": null
       },
       "debug": null,
       "resource": "zone-clients",
       "limit": 1000,
       "offset": 0
   }

Remarquez qu'il y a 3357 éléments possibles à renvoyer (valeur de comptage), mais qu'avec la limite=1000, et en regardant la valeur itemCount, seuls 1000 des 3357 éléments sont renvoyés.

Trier les éléments d'une réponse

When you make a basic GET call to one of TrackTik's API endpoints, it will in general return a list of records sorted by their main index (id) numbers. This means that the oldest information is returned first.

That might not be useful in all situations especially when a person is looking for the new data, or needs to sort by name alphabetically, and so on.

Pour trier les éléments d'une réponse à un appel API, vous devez utiliser le paramètre "sort". Il trie par défaut dans l'ordre CROISSANT, et vous pouvez préfixer la valeur du paramètre par un "-" pour l'inverser en ordre DÉCROISSANT.

Par exemple,

Supposons que vous souhaitiez consulter la dernière liste des nouveaux employés. Vous auriez un tri DESCENDANT sur les valeurs de l'index id telles qu'elles apparaissent dans la base de données :

[GET] /rest/v1/employees?sort=-id

Remarquez le "-" avant le "id" pour passer de l'ordre de tri croissant à décroissant.

Vous pouvez également le faire pour les noms des employés, par exemple. Ainsi, pour une liste d'employés par ordre alphabétique, vous demanderez :

[GET] /rest/v1/employees?sort=name

The sorting feature does not currently support multiple dimensions. 

Paginating Items Returned (offset)

If you want to see a different subset of the possible items that can be returned, you can use the offset filter to request “the next interval of items as defined by the limit value in the API request”.

Supposons que vous révisiez une liste d'employés triés par groupes de 5 (pour la performance, ou un outil doté d'une interface graphique). Vous pouvez demander les 5 premiers avec :

[GET] /employees?limit=5&fields=id,name,courriel&sort=id

{
           "id": 1000,
           "name": "TrackTIk Support (HQ)",
           "email": "E@E.com"
       },
       {
           "id": 1001,
           "name": "TrackTik Support (NE)",
           "email": ""
       },
       {
           "id": 1002,
           "name": "TrackTik Support (NW)",
           "email": ""
       },
       {
           "id": 1003,
           "name": "TrackTik Support (SE)",
           "email": ""
       },
       {
           "id": 1004,
           "name": "TrackTik Support (SW)",
           "email": ""
       }

Ajoutons maintenant un décalage pour obtenir les 5 éléments suivants, sans compter les éléments précédents déjà renvoyés :

{
    "id": 1005,
    "name": "Joan Slater",
    "email": ""
},
{
    "id": 1006,
    "name": "John Mills",
    "email": "BMills@prioritysecurity.com"
},
{
    "id": 1007,
    "name": "Jake Bond",
    "email": "JBond@prioritysecurity.com"
},
{
    "id": 1008,
    "name": "Molly Sutherland",
    "email": "MSutherland@prioritysecurity.com"
},
{
    "id": 1009,
    "name": "Mike Brown",
    "email": "mbrown@prioritysecurity.com"
}

Résumé rapide

You already know about limits:

[GET] /employees?limit=5&fields=id,name,email&sort=id 

A request like that will get the first 5 records stored in the database (because of the primary key sorting of sort=id parameter)

Mais pour obtenir les 5 suivants, vous pouvez utiliser une valeur de décalage. La valeur de décalage est le nombre de lignes à sauter avant de commencer le décompte jusqu'à la limite. Ainsi, si l'appel précédent a retourné les 5 premiers, pour obtenir les 5 suivants, il faillirait :

[GET] /employees?limit=5&fields=id,name,email&sort=id&offset=5

And for the next 5 after the first 10:

[GET] /employees?limit=5&fields=id,name,email&sort=id&offset=10

Lorsque vous développez une boucle d'appel pour paginer de la sorte, vous devez fixer la variable limite à 5 et le décalage de la variable limite multiplié par le nombre de pages à sauter.

First (no pages) 5: limit 5, offset 0 (offset = 5 x 0)
Second 5 (page 1): limit 5, offset 5 (offset = 5 x 1)
Third 5 (page 2): limit 5, offset 10 (offset = 5 x 2)

Performance is More Often About Record Counts in the Database

Dans les intégrations quotidiennes avec les clients, nous avons remarqué que même si vous filtrez et compensez, lorsqu'il y a un point de terminaison qui nécessite au moins un filtre de recherche, comme la valeur reportDateTime des rapports accessibles au moyen de /reports, le processus de récupération des données en arrière-plan doit toujours parcourir l'ensemble du jeu d'enregistrements pour trouver des correspondances avec le filtre requis.

Cela signifie que si une base de données client a 17 millions de rapports, la moindre petite requête à /reports dans ce jeu de données prendra plusieurs minutes. Cela peut être amélioré en cherchant des plages de clés primaires plutôt que des champs indexés, mais cela prendra quand même un certain temps.

Lorsque l'on travaille avec de grands ensembles de données, il est important de gérer les attentes. Les filtres ne peuvent pas tout faire.

API Gateway Limits

An API call must not exceed 30 seconds before a response is generated or it will timeout with a 504 Gateway Timeout HTTP Status Code. Limits and offsets are not as effective at improve large API call response times compared to filters on ranges of dates and indexes, so strategize accordingly.

API limits (requests per second) are not currently tiered, but they will be in the future and we're planning on offering a dashboard to monitor your own activity as part of the implementation. For now the Firewall is enforcing limits more generally for everyone.

API Limits at the Firewall

TrackTik's Web Application Firewall blocks source IP addresses that generate more than ~4000 requests per 5 minutes. Once the limit is exceed, the IP address is blocked. The requests that continue to be made will receive a response of: 403 Forbidden

Après avoir été bloquées, les demandes sont toujours remarquées et comptées pour voir si le taux est réduit de 4k/5min.

Once the rate is reduced in the next 5 minute interval, the IP address is unblocked.