Prestazioni IPC: Named Pipe vs Socket

Tutti sembrano dire che le pipe con nome sono più veloci dei socket IPC. Quanto sono più veloci? Preferirei usare i socket perché possono fare comunicazioni bidirezionali e sono molto flessibili, ma sceglierò la velocità sulla flessibilità se è di importo considerevole.

Ti suggerirei di prendere prima il percorso facile, isolando attentamente il meccanismo IPC in modo da poter passare da socket a pipe, ma preferirei sicuramente prima il socket. Dovresti assicurarti che le prestazioni dell'IPC siano un problema prima di eseguire l'ottimizzazione preventiva.

E se ti trovi nei guai a causa della velocità IPC, penso che dovresti considerare il passaggio alla memoria condivisa piuttosto che andare in pipe.

Se vuoi fare qualche test sulla velocità di trasferimento, dovresti provare socat , che è un programma molto versatile che ti permette di creare quasi ogni tipo di tunnel.

I migliori risultati che otterrai con la soluzione di memoria condivisa .

I named pipe sono solo il 16% migliori dei socket TCP .

I risultati si ottengono con il benchmarking IPC :

• Sistema: Linux (Linux ubuntu 4.4.0 x86_64 i7-6700K 4.00GHz)
• Messaggio: 128 byte
• Conteggio messaggi: 1000000

Punto di riferimento del tubo:

Message size:       128
Message count:      1000000
Total duration:     27367.454 ms
Average duration:   27.319 us
Minimum duration:   5.888 us
Maximum duration:   15763.712 us
Standard deviation: 26.664 us
Message rate:       36539 msg/s

Benchmark FIFO (named pipe):

Message size:       128
Message count:      1000000
Total duration:     38100.093 ms
Average duration:   38.025 us
Minimum duration:   6.656 us
Maximum duration:   27415.040 us
Standard deviation: 91.614 us
Message rate:       26246 msg/s

Benchmark della coda dei messaggi:

Message size:       128
Message count:      1000000
Total duration:     14723.159 ms
Average duration:   14.675 us
Minimum duration:   3.840 us
Maximum duration:   17437.184 us
Standard deviation: 53.615 us
Message rate:       67920 msg/s

Benchmark memoria condivisa:

Message size:       128
Message count:      1000000
Total duration:     261.650 ms
Average duration:   0.238 us
Minimum duration:   0.000 us
Maximum duration:   10092.032 us
Standard deviation: 22.095 us
Message rate:       3821893 msg/s

Benchmark dei socket TCP:

Message size:       128
Message count:      1000000
Total duration:     44477.257 ms
Average duration:   44.391 us
Minimum duration:   11.520 us
Maximum duration:   15863.296 us
Standard deviation: 44.905 us
Message rate:       22483 msg/s

Benchmark dei socket di dominio Unix:

Message size:       128
Message count:      1000000
Total duration:     24579.846 ms
Average duration:   24.531 us
Minimum duration:   2.560 us
Maximum duration:   15932.928 us
Standard deviation: 37.854 us
Message rate:       40683 msg/s

Benchmark ZeroMQ:

Message size:       128
Message count:      1000000
Total duration:     64872.327 ms
Average duration:   64.808 us
Minimum duration:   23.552 us
Maximum duration:   16443.392 us
Standard deviation: 133.483 us
Message rate:       15414 msg/s

Sono d'accordo con shodanex, sembra che tu stia cercando prematuramente di ottimizzare qualcosa che non è ancora problematico. A meno che tu sappia socket saranno un collo di bottiglia, li userei.

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

Se pensi davvero che i socket ti rallenteranno, esci dal cancello usando la memoria condivisa con molta attenzione a come usi i lucchetti. Ancora una volta, in tutta la realtà, potresti trovare un piccolo aumento di velocità, ma nota che stai sprecando una parte di esso in attesa di blocchi di mutua esclusione. Non ho intenzione di sostenere un viaggio nell'inferno del futex (beh, non proprio più l'inferno nel 2015, a seconda della tua esperienza).

Libbra per libbra, i socket sono (quasi) sempre il modo migliore per utilizzare lo spazio utente IPC in un kernel monolitico .. e (di solito) il più facile da eseguire il debug e la manutenzione.

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

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

Questo benchmark mostra una differenza di circa il 12-15% più veloce per i tubi.

Se non hai bisogno di velocità, le prese sono il modo più semplice per andare!

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

Per la comunicazione bidirezionale con named pipe:

• Se hai pochi processi, puoi aprire due pipe per due direzioni (processA2ProcessB e processB2ProcessA)
• Se hai molti processi, puoi aprire e uscire pipe per ogni processo (processAin, processAout, processBin, processBout, processCin, processCout ecc.)
• Oppure puoi diventare ibrido come sempre :)

Le pipe con nome sono abbastanza facili da implementare.

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

Li ho persino codificati con java (stavo serializzando e inviando oggetti su di loro!)

Le pipe denominate presentano uno svantaggio:

• non scalano su più computer come i socket poiché si basano sul filesystem (assumendo che il filesystem condiviso non sia un'opzione)

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

Puoi disabilitare il Nagle con l'opzione socket TCP_NODELAY ma poi la fine della lettura non riceverà mai due brevi messaggi in una singola chiamata di lettura.

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

Tubi e prese con nome non sono funzionalmente equivalenti; i socket forniscono più funzionalità (sono bidirezionali, tanto per cominciare).

Non possiamo dirti quale funzionerà meglio, ma sospetto fortemente che non abbia importanza.

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

Se un socket Unix non è abbastanza veloce e stai trasferendo molti dati, considera l'utilizzo della memoria condivisa tra il tuo client e il server (che è MOLTO più complicato da configurare).

Sia Unix che NT hanno "pipe con nome" ma sono totalmente differenti nel set di funzionalità.

Puoi utilizzare una soluzione leggera come ZeroMQ [ zmq / 0mq ]. È molto facile da usare e notevolmente più veloce dei socket.