Ciao

Lato "chiamante" (quindi il tuo loop), il fatto di mettere tutto in parallelo incide poco sulle risorse: l'ambiente che chiama non fa operazioni pesanti, sfrutta la rete ed eventualmente la RAM. Però, a meno che il tuo web-service non risponda con centinaia di MB, direi che sono alquanto trascurabili come problemi.


La cosa si fa più interessante lato "chiamato" (web-service). E' lui infatti a dover fare la parte pesante del lavoro: intercettare la chiamata, accedere ad un DB/FileSystem, ..., rispondere al chiamante.

Qui però dipende molto dalle operazioni fatte dal servizio e dalle prestazioni della macchina su cui gira. Per esempio, se fa una query pesantissima lato DB, eseguirne 10 o 100 in parallelo potrebbe inchiodare il tutto. Purtroppo è difficile prevedere prima il comportamento, a meno che tu non abbia altre informazioni da condividere

Ciao,
La domanda è perché interrogare continuamente un'anagrafica? I dati cambiano così di continuo? Nel caso conviene comunque prevedere un servizio di cache dei dati, in modo da essere tranquilli se i dati lievitano e limitare le richieste al server o perlomeno i dati in transito finché questi non cambiano.
Puoi eseguire poi dei task asincroni in modo da non bloccare l'app in attesa della risposta, e anche, invece di un pool continuo di richiesta dati notificare il client dal server quando questi cambiano (es. SignalR) , molto più funzionale