Prestazioni IPC: named pipe vs socket

Question

Tutti sembrano dire che le pipe denominate sono più veloci dei socket IPC. Quanto sono più veloci? Preferirei usare le prese perché possono fare comunicazione bidirezionale e sono molto flessibili, ma sceglieranno la velocità rispetto alla flessibilità se è di notevole entità.

Answer 1

I tubi e le prese nominali non sono funzionalmente equivalenti; i socket forniscono più funzionalità (sono bidirezionali, per cominciare).

Non siamo in grado di dirti quali saranno le prestazioni migliori, ma sospetto fortemente che non abbia importanza.

I socket di dominio Unix faranno più o meno quello che saranno i socket tcp, ma solo sulla macchina locale e con (forse un po ') overhead inferiore.

Se un socket Unix non è abbastanza veloce e si stanno trasferendo molti dati, si consideri l'utilizzo della memoria condivisa tra client e server (che è molto più complicato da configurare).

Unix e NT hanno entrambi "named pipe" ma sono completamente diversi nel set di funzionalità.

Answer 2

Suggerirei di prendere prima il percorso facile, isolando attentamente il meccanismo ipc in modo che sia possibile passare da un socket all'altro, ma senza dubbio andrei prima con il socket. Dovresti essere sicuro che le prestazioni IPC sono un problema prima dell'ottimizzazione preventiva.

E se si verifica un problema a causa della velocità IPC, penso che si dovrebbe prendere in considerazione il passaggio alla memoria condivisa piuttosto che andare al pipe.

Se si desidera eseguire alcuni test di velocità di trasferimento, è necessario provare socat, che è un programma molto versatile che consente di creare quasi ogni tipo di tunnel.

Answer 3

Sono d'accordo con shodanex, sembra che tu stia prematuramente cercando di ottimizzare qualcosa che non è ancora problematico. A meno che tu non sappia che lo sa di socket, li userò semplicemente.

Un sacco di persone che giurano per pipe nominate trovano un piccolo risparmio (a seconda di quanto bene tutto il resto è scritto), ma finiscono con il codice che impiega più tempo a bloccare una risposta IPC che a fare un lavoro utile. Certo, gli schemi non bloccanti aiutano questo, ma quelli possono essere complicati. Trascorrere anni a portare il vecchio codice nell'età moderna, posso dire, l'accelerazione è quasi nulla nella maggior parte dei casi che ho visto.

Se pensi davvero che i socket ti rallentino, allora vai fuori dal gate usando la memoria condivisa prestando attenzione a come usi i lucchetti. Di nuovo, in tutta l'attualità, potresti trovare una piccola accelerazione, ma nota che stai sprecando una parte di essa in attesa di blocchi di esclusione reciproca. Non ho intenzione di sostenere un viaggio a futex hell (beh, non piuttosto inferno più nel 2015, a seconda della vostra esperienza).

Pound per libbra, i socket sono (quasi) sempre il modo migliore per passare allo spazio utente IPC con un kernel monolitico .. e (di solito) il più semplice da eseguire il debug e il mantenimento.

Answer 4

Se non hai bisogno di velocità, le prese sono la via più facile da percorrere!

Se quello che stai guardando è la velocità, la soluzione più veloce è la memoria condivisa, non le named pipe.

Answer 5

Per la comunicazione a due vie con named pipe:

• Se si dispone di alcuni processi, è possibile aprire due tubi per due direzioni (processA2ProcessB e processB2ProcessA)
• Se si dispone di molti processi, è possibile aprire in e fuori tubi per ogni processo (processAin, processAout, processBin, processBout, processCin, processCout ecc)
• Oppure si può andare ibrido come sempre :)

Nam le pipe ed sono abbastanza facili da implementare.

E.g. Ho implementato un progetto in C con named pipe, grazie alla comunicazione standard basata su input-output di file (fopen, fprintf, fscanf ...) è stato così facile e pulito (se anche questa è una considerazione).

ho addirittura codificato con java (ero serializzazione e l'invio di oggetti su di loro!)

named pipe ha uno svantaggio:

• che non sono scalabili su più computer, come le prese in quanto si basano su filesystem (supponendo che il filesystem condiviso non sia un'opzione)

Answer 6

Ricordare che socket non significa necessariamente IP (e TCP o UDP). È inoltre possibile utilizzare i socket UNIX (PF_UNIX), che offrono un notevole miglioramento delle prestazioni rispetto alla connessione a 127.0.0.1

Answer 7

Come spesso, i numeri dicono più di sentirsi, ecco alcuni dati: Pipe vs Unix Socket Performance (opendmx.net).

Questo benchmark mostra una differenza di velocità tra il 12 e il 15% più veloce per i tubi.

Answer 8

Un problema con i socket è che non hanno un modo per svuotare il buffer. Esiste qualcosa chiamato algoritmo Nagle che raccoglie tutti i dati e li scarica dopo 40 ms. Quindi se è la reattività e non la larghezza di banda, potresti stare meglio con una pipa.

È possibile disattivare Nagle con l'opzione socket TCP_NODELAY, ma la lettura non riceverà mai due messaggi brevi in ​​una singola chiamata di lettura.

Quindi testarlo, ho finito con niente di tutto questo e ho implementato le code basate sulla memoria mappata con pthread mutex e semaforo nella memoria condivisa, evitando molte chiamate al sistema del kernel (ma oggi non sono più molto lente).

Answer 9

È possibile utilizzare una soluzione leggera come ZeroMQ [zmq/0mq]. È molto facile da usare e molto più veloce delle prese.