Ciao Giuseppe,
il Keep-Alive è un'intestazione HTTP inviata dal client che invita il server a tenere aperta una connessione TCP persistente, in modo che il client possa riusarla per inviare ulteriori richieste HTTP. La specifica elenca vari vantaggi di questa tecnica, tra cui:


giuseppe500 ha scritto:

Ha un timeout il keep alive?

Questo dipende dalla particolare implementazione del server. La specifica dice semplicemente questo:


Penso che RestSharp utilizzi il keep alive per default, come indicato dalla documentazione di HttpWebRequest (che lui usa) ma se vuoi essere esplicito puoi aggiungere l'intestazione keep-alive alle tue richieste.
RestSharp ne terrà conto, come si evince dal suo codice sorgente.

giuseppe500 ha scritto:

Questo velocizzerebbe molto il mio lavoro.

Di sicuro il keep alive aiuta ma non aspettarti miglioramenti eccessivi.
L'ideale sarebbe se il webservice in questione accettasse una collezione di elementi anziché un solo elemento alla volta, oppure se supportasse il batching.
Inoltre, dovresti provare a comprimere il corpo della richiesta impostando l'intestazione "Content-Encoding" su "gzip" (sempre che il server la supporti).

Parla di queste cose con chi ha sviluppato il webservice.
Quello che puoi fare tu è inviare le richieste in background, per non far attendere inutilmente l'utente mentre avviene l'invio.

ciao,
Moreno

---

Modificato da BrightSoul il 09 ottobre 2016 23.41 -

Ciao Giuseppe,
non ho capito se hai scritto tu il webservice e se hai il controllo del server.

se il collo di bottiglia sta nella banda in upload della mia connessione

Puoi usare la visualizzazione timeline di Fiddler per capire quanto dura ciascuna richiesta.
http://docs.telerik.com/fiddler/KnowledgeBase/Timeline
Comunque, già solo il fatto che invii dei dati via rete rallenta certamente l'esecuzione, specie se invii tanti oggetti in richieste singole. A prescindere che la tua connessione sia un collo di bottiglia o no, dovresti inviare risultati in batch per ottimizzare il trasferimento.

debba perdere tempo a instanziare il client

Istanziare il client è un'operazione molto rapida, non credo che ci siano possibilità di ottimizzazione considerevoli da quel punto di vista.
Non ho ben chiaro cosa intendi con "autenticarti": per ogni oggetto che invii al servizio effettui una precedente richiesta di autenticazione? Se è così, è un motivo in più per inviare gli oggetti in un batch.

si il server accetta collezioni di oggetti solo che ho provato e oltre un certo numero inizia a sbagliare

Questo sembra un problema di implementazione più che di banda. Infatti, se il problema fossero eventuali pacchetti arrivati corrotti al server, il protocollo TCP/IP li individuerebbe e chiederebbe al client di reinviarli. Tutto questo è trasparente e non devi preoccupartene.
Se il servizio "inizia a sbagliare", direi che quasi sicuramente il problema è nell'implementazione dell'operazione del servizio.
Dovresti però chiarire cosa significa che "inizia a sbagliare". Se si tratta di un errore causato da una richiesta troppo grande, cioè che supera il limite di bytes preimpostato nella configurazione, allora dovresti ridurre il numero di oggetti inclusi nel batch. Inizia con l'inviare 50 o 100 oggetti alla volta, già dovrebbe velocizzarsi di parecchio.

Mi chiedevo inoltre come attivare la conpressione gzip supportata dal server e se da qualche risultato.

Questo servirà a ridurre il tempo di trasferimento. I risultati dipenderanno dalla qualità della tua connessione: più è lenta e più ne apprezzerai i benefici.

Non hai detto che tipo di webservice hai lato server. WCF? Web API? L'abilitazione dipende dalla tecnologia che stai usando. Ecco una possibile soluzione per far accettare ad ASP.NET Web API una richiesta gzip.
http://stackoverflow.com/questions/12345292/how-do-enable-a-net-web-api-to-accept-g-ziped-posts

In generale, se vuoi monitorare le prestazioni del webservice lato server, puoi sfruttare varie soluzioni:

• A mano, con la classe Stopwatch;
• Avvalendoti dei Performance counters;
• Usando Application insights

ciao,
Moreno