[Python] Parere su Go di un professore di informatica (delle superiori) nonche' uno dei fondatori di ERLUG

[Davide Muzzarelli]

Il 12/07/2015 19:26, enrico franchi ha scritto:
> Tipo... 90.000 connessioni aperte simultaneamente? Ma dai, diciamo
> proprio di no. Non e' che non *puoi* farlo. E' che e' proprio una
> cattiva idea farlo *a meno che non devi proprio farlo*. Tipicamente
> tutte le volte che assumi che qualcosa sia gratuito e illimitato, prima
> o poi qualcuno ti fara' scoprire che non e' cosi' (corollario: di solito
> questa cosa accade in un'altra time-zone, quando uno avrebbe preferito
> dormire invece di scoprire nuove cose).

Non c'è alcuna spiegazione su come deve funzionare il sistema di Carlos 
per cui sono stato molto generico. Ho giusto scritto cosa Go può 
raggiungere senza troppo sbattimento, chiaramente a scopo di paragone 
con Python.

Dipende da quale è il suo bisogno, ha parlato di alcune decine di 
migliaia di router da gestire. Se è un progetto serio avrà un budget e 
l'aiuto di colleghi, eventualmente un sistemista. Ovvio che si può fare 
distribuendo il carico su più server, che è probabilmente la soluzione 
migliore sotto diversi punti di vista, non c'è bisogno di correre di notte.

Questo tizio ha raggiunto 600.000 connessioni per processo con 16GB di 
RAM e il vecchio Go 1.0.3, che è molto più di 90.000 connessioni. Il GC 
da allora è migliorato sensibilmente:
https://groups.google.com/forum/#!searchin/golang-nuts/Garbage$20collecting/golang-nuts/S9goEGuoMRM/FZyd2M6uiVMJ

> In generale e'
> davvero molto piu' semplice usare logiche di pool rispetto che fare
> 90.000 goroutine.

Sono d'accordo. A Qihoo 360 hanno comunque raggiunto 1 milione di 
connessioni/server prima di passare ai pool, sempre con Go 1.0.3.

Dubito che Carlos debba creare un sistemone del genere, probabilmente 
gli basta molto ma molto meno.

> Tipicamente se uno fa ste cose a cuor leggero la prima
> cosa che scopre e' che ha un problema con il garbage collector, per dire.

Basta fare una spike solution per vedere quali numeri ottiene. Python mi 
pare meno adatto per queste cose, se lo deve fare con quello 
probabilmente si trova con limiti ancora maggiori.

>      > Puoi usare tutte le CPU a disposizione fin da subito senza
>     scrivere codice aggiuntivo.
>
> Ora... il codice aggiuntivo e' piccolo, ma di per se Go 1.4 se non gli
> dici altrimenti usa *una* CPU.

Hai ragione, è una riga di codice all'inizio del programma per dire 
quante CPU usare. Quello che intendo è che non deve modificare come 
funziona il proprio codice, tipo per usare il multiprocessing in Python.

Byez,
Davide Muzzarelli