Quanto sono lenti i socket TCP rispetto alle pipe denominate su Windows per localhost IPC?

Question

Sto sviluppando un proxy TCP da mettere di fronte a un servizio TCP che dovrebbe gestire tra 500 e 1000 connessioni attive da Internet selvaggio.

Il proxy è in esecuzione sulla stessa macchina del servizio, ed è per lo più trasparente. Il servizio è per la maggior parte inconsapevole del proxy, con l'unica eccezione della notifica del vero indirizzo IP remoto dei client.

Ciò significa che, per ogni socket TCP in ingresso aperto, ci sono altri due socket sul server: il secondo della coppia nel Proxy e quello sul servizio reale dietro al proxy.

Le dimensioni della finestra di invio e di ricezione sui due socket proxy sono impostate su 1024 byte.

Quali sono le implicazioni sulle prestazioni su questo? Quanto è lenta questa configurazione? Dovrei fare qualche sforzo per cambiare il servizio per usare Named Pipes (o un altro meccanismo IPC), o un socket TCP localhost è per la maggior parte un IPC efficiente?

La fusione delle due applicazioni non è un'opzione. In questo momento siamo bloccati con la configurazione dei due processi.

EDIT: La ragione per avere due processo separato sullo stesso hardware è 100% economia. Abbiamo solo un server e non stiamo pianificando di ottenere di più (senza soldi).

Il servizio TCP è un software legacy in Visual Basic 6, che è cresciuto oltre le nostre aspettative. Il proxy è C++. Non abbiamo tempo, denaro e risorse umane per riscrivere e migrare il codice VB6 in un moderno ambiente di programmazione.

Il proxy è il nostro tentativo di attenuare uno specifico problema di prestazioni sul servizio, uno DDoS attack che riceviamo di volta in volta.

Il proxy è open source, and here is the project source code.

Answer 1

http://msdn.microsoft.com/en-us/library/aa178138(v=sql.80).aspx

Fammi riassumere per voi. Se sei preoccupato per le prestazioni, usa TCP/IP. Ma se avete una rete veramente veloce e non siete preoccupati per le prestazioni, Named Pipes sarebbe "pulito" in quanto potrebbe farvi risparmiare un po 'di codice.

Per non parlare del fatto che se ci si attiene al TCP, si avrà qualcosa che può essere ridimensionato e persino bilanciato quando arriverà il momento.

Cheers,

Answer 2

Qual è il motivo di avere un proxy sulla macchina SAME, solo curioso?

Comunque:

Ci sono diversi metodi per IPC, TCP/IP, named pipe sono comparabili in termini di velocità e complessità. Se vuoi davvero qualcosa che si adatta bene e non ha quasi nessun sovraccarico: usa la memoria condivisa. Si utilizza in combinazione con un algoritmo lock free per far avanzare i puntatori (o utilizzare un buffer per ciascun lettore (il proxy/il servizio) e lo scrittore (il servizio/il proxy)).

Answer 3

Nello scenario descritto, è improbabile che le connessioni TCP locali siano un collo di bottiglia. Ovviamente introdurrà un sovraccarico, ma questo dovrebbe essere trascurabile a meno che la CPU non stia già scaldando.

Ad una ipotesi, se l'utilizzo della CPU del server è normalmente inferiore al 50% o giù di lì (con il proxy in posizione) non vale la pena preoccuparsi di ridurre al minimo l'overhead associato alle connessioni TCP locali.

Se l'utilizzo della CPU è regolarmente superiore all'80%, è probabile che si stia eseguendo un po 'di profilazione. Comincerei confrontando il carico della CPU (o, meglio ancora, le prestazioni, se è possibile misurarlo in modo significativo) quando il proxy è attivo quando non lo è. A meno che il proxy non stia elaborando in modo complicato, l'overhead associato alle connessioni TCP aggiuntive è probabilmente una frazione significativa del sovraccarico totale introdotto dal proxy, quindi dovrebbe fornire almeno una stima dell'ordine di grandezza di quanto tu sia " guadagno utilizzando una forma più efficiente di IPC.

Answer 4

Sarà lo stesso (o almeno non misurabilmente diverso). Winsock è abbastanza intelligente da sapere se sta parlando con un socket sullo stesso host e, in tal caso, manderà in corto circuito praticamente tutto sotto IP e copierà i dati direttamente da buffer a buffer. In termini di named pipe vs. socket, se è necessario essere potenzialmente in grado di comunicare con macchine diverse in futuro, scegliere socket. Se sai per certo che non avrai mai bisogno di farlo, scegli quello con cui i tuoi sviluppatori sono più familiari o più a tuo agio.

Answer 5

Per chi viene a leggerlo più tardi, desidero aggiungere alcuni risultati che rispondono alla domanda originale.

Per un'utilità che stiamo sviluppando abbiamo una classe di rete che può utilizzare named pipe o TCP con le stesse chiamate.

Ecco un tipico ciclo di nuovo il trasferimento di file sul nostro sistema di prova:

TCP/IP Tempo di trasferimento: 2.5 secondi
named pipe Tempo di trasferimento: 3,1 secondi

Ora, se si va al di fuori della macchina e connettersi a un computer remoto in rete le prestazioni per named pipe è molto peggio:

TCP/IP tempo di trasferimento: 12 secondi
named pipe tempo di trasferimento: 2,5 minuti (! Sì Minuti)

Mi rendo conto che questo è solo un sistema (Windows 7) Ma penso che sia un buon indicatore di quanto possano essere lente le pipe denominate ... e sembra che il TCP sia la strada da percorrere.