Sto scrivendo un servizio c10k e sto cercando di valutare le prestazioni di Clojure. Gli agenti Clojure possono gestire questa scala di concorrenza con i suoi agenti basati su thread? Altri sistemi ad alte prestazioni sembrano muoversi verso asincrono-IO / eventi / greenlet, sebbene con un costo apparentemente più elevato di complessità.
Supponiamo che ci siano 10.000 client connessi, che inviano messaggi che dovrebbero essere aggiunti a 1.000 file locali - il servizio Clojure sta provando a scrivere su più file in parallelo che può, mentre non consente a nessuna delle due richieste separate di manipolare lo stesso singolo file scrivendo allo stesso tempo.
Clojure agenti sono estremamente eleganti concettualmente: consentirebbero la scrittura separata di file separati in modo asincrono, mentre serializzazione (nel senso del database) richieste multiple per scrivere sullo stesso file.
La mia comprensione è che gli agenti lavorano avviando un thread per ogni operazione (supponiamo di essere legati all'IO e usando send-off ) - quindi in questo caso è corretto che inizierebbe 1000+ thread? I sistemi attuali possono gestire questo numero di thread in modo efficiente? La maggior parte di loro dovrebbe essere legata all'IO e dormire la maggior parte del tempo, ma presumo che ci sia ancora una penalità di commutazione del contesto che è teoricamente più alta dei sistemi asincroni-IO / eventi (es. Erlang, Go, node.js) .
Se la soluzione Clojure può gestire le prestazioni, sembra la cosa più elegante da codificare. Tuttavia, se non è in grado di gestire le prestazioni, potrebbe essere preferibile qualcosa come i processi leggeri di Erlang o di Go, dal momento che sono progettati per aver generato decine di migliaia di file contemporaneamente e sono solo moderatamente più complessi da implementare.
Qualcuno ha affrontato questo problema in Clojure o rispetto a queste altre piattaforme? (Grazie per i tuoi pensieri!)