Penso che probabilmente non sia un buon progetto.
modifica vedo in un commento che spieghi che si tratta di una API di geocodifica. Presumibilmente si inviano indirizzi e si riceve lat, long
In questo caso di geo-coding, il server è sotto lo stesso carico per indirizzo, quindi l'unica differenza tra una grande richiesta o molte piccole è il tempo di risposta di ciascuna richiesta.
Dato che il client può comunque richiedere lo stesso numero di risultati contemporaneamente, tramite molte richieste simultanee di piccole dimensioni, un design migliore è quello di accodare ciascun indirizzo separatamente per l'elaborazione e restituirli al termine. Idealmente potresti inviare i singoli risultati al cliente.
Potresti anche implementare una strategia di elaborazione round robin se vuoi distribuire equamente il tempo di elaborazione tra molti client.
Di solito un limite di velocità su una API limita il numero massimo di richieste per periodo piuttosto che la dimensione della richiesta.
- (la restituzione di più record in una singola risposta generalmente non causa alcun carico di CPU aggiuntivo e una singola risposta ampia utilizza meno larghezza di banda rispetto alle stesse informazioni trasmesse in molte piccole risposte)
Supponiamo che tu stia recuperando o caricando n record. Puoi farlo in una o più richieste. Di solito la singola (grande) richiesta metterà meno carico sul server.
- (Poiché ogni singola richiesta comporta un costo di gestione generale, che devi pagare una volta sola per la singola richiesta di grandi dimensioni vs molte volte per le richieste multiple multiple)
Dato che il client deve ancora elaborare tutte le sue richieste, la sua suddivisione sembrerebbe non offrire alcun valore di prestazione.
- (Se c'è anche un limite di velocità e il cliente ha bisogno dei dati ora, il client colpirà il limite e l'errore.Se il client non ha bisogno dei dati immediatamente, il server potrebbe inviare una risposta in seguito)
Anche se il client cambia dinamicamente la dimensione del suo batch sembra problematico. Devo fare la chiamata Get ogni volta? Posso memorizzare il valore nella cache? Cosa succede se c'è un ritardo tra l'acquisizione del valore e l'invio del batch?
- (ci sono tutti i problemi che dovresti risolvere senza limiti fissi)
Un design migliore sarebbe sicuramente avere il server che esegue la suddivisione sul numero richiesto, prima di passarlo internamente al livello successivo e poi riunire i risultati in un'unica risposta.
- (Supponendo che il costo per elaborare una richiesta di grandi dimensioni non sia lineare, diciamo che O (n ^ 2) il server potrebbe dividere la richiesta con la stessa facilità del client)
Suppongo che tu possa immaginare problemi di timeout con lotti di grandi dimensioni che sono un problema. Ma questo è meglio se si passa a una query di comando o modello asincrono piuttosto che a RPC
- (L'unica limitazione sulla divisione del server sul client è se ogni richiesta ha un timeout in attesa della risposta.Se si passa a un modello asincrono con una richiamata o un polling dal client, questo può essere negato)