Topic: Zitto zitto, Instagram è passato a python 3  (Letto 1154 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 3.154
  • Punti reputazione: 9
    • Mostra profilo
Zitto zitto, Instagram è passato a python 3
« il: Giugno 18, 2017, 14:34 »
Vi segnalo questa bella storia, per la prossima volta che vi lamentate che dovete migrare a py3 il vostro script... e anche per la prossima volta che qualcuno vi dice che python è lento e non scala...
https://thenewstack.io/instagram-makes-smooth-move-python-3/

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:Zitto zitto, Instagram è passato a python 3
« Risposta #1 il: Giugno 20, 2017, 18:11 »
Vi segnalo questa bella storia, per la prossima volta che vi lamentate che dovete migrare a py3 il vostro script... e anche per la prossima volta che qualcuno vi dice che python è lento e non scala...
https://thenewstack.io/instagram-makes-smooth-move-python-3/

Beh, Python *e'* lento. "Scalare" non e' una proprieta' del linguaggio.

Intanto loro hanno un problema che descrivono come puramente I/O bound. In questi casi, in generale cambiare linguaggio non aiuta (a meno che non dia accesso a strumenti che servono direttamente per migliorare l'I/O). Python diventa particolarmente doloroso se hai tratti del problema I/O bound e tratti che sono CPU bound. Siccome Python e' piuttosto primitivo come piattaforma, devi per forza risolvere a livello di architettura, spezzando le parti in componenti diversi. Sperando che questo non crei ulteriori problemi sull'I/O

Vedi il problema e' che se il tuo problema e' perfettamente parallelizzabile orizzontalmente (o lo e' principalmente), puoi risolvere semplicemente aggiungendo macchine. Il problema va via. Poi magari spendi 1M di euro al mese in hw e ne basterebbero 150K.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 3.154
  • Punti reputazione: 9
    • Mostra profilo
Re:Zitto zitto, Instagram è passato a python 3
« Risposta #2 il: Giugno 20, 2017, 19:51 »
Beh sì certo, se il tuo dominio applicativo ti porta dritto a schiantarti a trecento all'ora contro il gil, allora forse non è il caso di usare Python. Ma alla fine, devono solo mostrare foto di gattini e torte di compleanno in giro, che potrà mai essere un problema, se non l'IO?
Comunque quello che mi colpiva è l'incremento di prestazioni che hanno avuto a passare a py3 senza toccare nient'altro... Si possono fare benchmark e tutto, ma questa è sicuramente la madre di tutte le prove su strada.
Quello che invece *non* mi ha sorpreso è che abbiano provato a farlo in php con risultati deludenti. eh eh.

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:Zitto zitto, Instagram è passato a python 3
« Risposta #3 il: Giugno 22, 2017, 19:51 »
Beh sì certo, se il tuo dominio applicativo ti porta dritto a schiantarti a trecento all'ora contro il gil, allora forse non è il caso di usare Python.

Ma non e' nemmeno solo il GIL. E' un insieme di cose. Il GIL ti colpisce anche in modo inaspettato (e.g., vuoi gestire il costo del logging e delle metriche su un esecutore diverso per non rallentare il critical path).

E poi c'e' la questione CPU bound. E quando numpy (o chi per lui) basta ok. E ti devi ricordare che i db possono essere un problema CPU bound in Python. E  manipolare testi e' sempre potenzialmente costoso (dipende da quello che ci fai). Bene... quando scrivi qualcosa come for c in text, stai facendo una cosa *allucinantemente* costosa. Cioe', ognuno di quei C e' una stringa a sua volta.
E le strutture dati? La libreria standard te ne da, tutto sommato, poche (come in Go, differentemente da Java). E nemmeno tutte implementate in C. Quindi potrebbe essere che per fare le cose bene dal punto di vista algoritmico, te le scrivi tu. Ecco... a questo punto sono scritte in Python. Quindi non hai davvero accesso a basso livello alla memoria. Tante cose le puoi rendere efficienti solo fino ad un certo punto. E devi conoscere un botto di trick (e.g., come funziona __slots__, ma questo ti salva "solo" un po' di byte per oggetto... ma magari questi oggetti servono per il book-keeping della struttura, quindi scalano come gli elementi che passano per la struttura, non per il numero di strutture.

Il compilatore non fa *nulla*. Se il compilatore capiscce che x+x, x << 1 e x * 2 sono la stessa cosa e che x e' un'intero positivo, allora puo' semplicemente generare il codice per la roba piu' efficiente. Un JIT puo' arrivare alla stessa conclusione. In Python non puo' nemmeno sapere che sono la stessa cosa (e non puo' certamente sapere che e' un'intero positivo). In Python sono io che devo sapere che x+x e' piu' efficiente e usare quello (o per lo meno, lo era l'ultima volta che avevo controllato). Anche se l'istinto mi direbbe x*2 o addirittura x << 1 (se ho un background embedded/C e roba simile). No per dire. Ora quanto spesso questa cosa diventa rilevante? Se fai gestionali, probabilmente mai. Per tante altre applicazioni, pure mai (sara' similmente tutto dominato dai tempi di accesso al db). Pero' il fatto e' che e' tutto irrilevante fino a quando, improvvisamente, non lo diventa. E queste conoscenze che nessuno ha (perche' sono raramente rilevanti) non sono facili da trovare. E allora benvenuto quello che fa Python da 15 anni e per culo ha visto questo stesso problema in passato (e lo ha risolto o visto risolvere). Questo fintanto che una versione successiva rende l'ottimizzazione irrilevante. E se e' tanto irrilevante, perche' e' nel performance tips ufficiale? E quando una nuova feature molto dinamica rendera' impossibile questa cosa?

Ma insomma... si puo' andare avanti cosi' per molto. Il punto chiave e' che da un lato alla maggior parte delle persone non interessa andare forte. Davvero. E tipicamente sono queste che si preoccupano in modo irrilevante della performance. Io me ne preoccupo quando mi colpisce. Che e' un problema: in Python potrebbe non esistere una soluzione pulita (a meno che non lo abbia progettato in quel modo dall'inizio). Perche' Python ad alte prestazioni funziona che in pratica se il tuo caso rientra in un pattern sufficientemente comune da avere una soluzione (e.g., numpy -- "matrici e calcoli su", asyncio/gevent "applicazioni che fanno un botto di io concorrente", pandas "statistica/machine learning", ...), beh, allora tutto bene. Di solito va davvero bene. Ma se hai un problema ibrido sei fottuto e in generale tutto quello che si discosta dal pattern canonico diventa incredibilmente costoso (per ricondurlo al caso noto).

D'altra parte Python non si pone come obiettivo di andare forte. Il focus e' un altro. Quindi non posso fargliene una colpa. Stanno ottimizzando per altre variabili. Va bene cosi'. Solo trovo che semplicemente deve creare stupore quando si riescono ad ottenere performance eccellenti; ma trovo anche abbastanza inutile cercare di sostenere che Python non sia lento, oppure che le success story indichino che non e' cosi' lento come si credeva. E' lento. Resta lento. Semplicemente a molti non interessa e ci sono alcune soluzioni sorprendentemente buone che nel loro caso d'uso sono completamente eccellenti. Ma insomma... come dire... Perl e' lento parecchio pure lui. Pero' sulla pura manipolazione di testi va davvero a cannone (e le primitive sono estremamente giuste ed efficienti). Perche' sono 20 anni che quella parte la curano perche' e' importantissima. Eh. Bene.

Citazione
Ma alla fine, devono solo mostrare foto di gattini e torte di compleanno in giro, che potrà mai essere un problema, se non l'IO?

Mi sembra un punto di vista un po' ingenuo. Salvo che io non uso nemmeno Instagram (nessun motivo particolare, solo contesto), la loro infrastruttura potrebbe non essere cosi' semplice. Per esempio, non so se non hanno sotto algoritmi di classificazione o di recommendation e roba simile. Tipo qualunque cosa parte con "machine learning" su una base di un gazzilione di foto sarebbe ben diverso.

Citazione
Comunque quello che mi colpiva è l'incremento di prestazioni che hanno avuto a passare a py3 senza toccare nient'altro... Si possono fare benchmark e tutto, ma questa è sicuramente la madre di tutte le prove su strada.

Citazione
Quello che invece *non* mi ha sorpreso è che abbiano provato a farlo in php con risultati deludenti. eh eh.

A me invece stupisce abbastanza.  Cioe'... sono sempre Facebook. Dove hanno sviluppato (svariati) environment PHP ad alte prestazioni. Quindi volendo avrebbero il know how per usare quella roba. Mi chiedo se hanno voluto non doverlo fare, se il loro problema e' sufficientemente diverso da quello di Facebook.

Ma comunque e' chiaro che non stanno raccontando tutta la storia.

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 3.154
  • Punti reputazione: 9
    • Mostra profilo
Re:Zitto zitto, Instagram è passato a python 3
« Risposta #4 il: Giugno 23, 2017, 12:14 »
Mah, non saprei proprio.
Certo che Python è "più lento", chi lo mette in dubbio. Ma più lento di "cosa", esattamente? Al contrario di te, io credo che le success stories contano, e anche molto. Quando uno vede che oggi, di fatto, uno degli oggetti più grossi di internet gira su python, non può non farsi delle domande su che cosa è davvero la velocità. Voglio dire, è chiaro che avranno le loro ottimizzazioni e i loro pezzi mission-critical scritti in... Go o va a sapere. Ma anche se fosse, resta il fatto che queste sono aggiunte successive montate su un'architettura in python. No, non in python - in Django, nientemeno! Con buona pace della magia nera dinamica di django che rallenta le cose.

A me invece la lezione sembra questa: oggi la legge di Moore è ancora un fattore sufficiente a spostare il peso della partita dalla parte di Pyhton. E' vero che se Instagram fosse scritto in Go (diamine, anche se fosse scritto in node.js!) loro risparmierebbero in costi di server. Ma è anche vero che aggiungere server oggi è ancora più economico che pagare qualcuno che reinventa Django in Go, o qualcosa del genere.
E non dico che questo mi piace, eh. Soprattutto quando penso al consumo energetico e all'impronta ambientale di un baraccone internet che mostra foto di gattini. E non sostengo nemmeno che possa durare in eterno. Ma tant'è. Scommetto che Instagram morirà di morte naturale (passerà la moda, etc.) prima di avere la reale necessità di cambiare l'architettura.
E questo vuol dire parecchio, bada bene. Vuol dire che tutto il ciclo di vita di uno degli oggetti più grossi di internet, da garage software a 600 milioni di utenti, può essere sostenuto con successo da Pyhton. Mica male.

Avere un linguaggio e un ecosistema ricco di librerie di ottima qualità, con decenni di esperienza, affidabile e solido, oggi costituisce ancora un valore economico superiore al ventiduesimo capannone di server che ti devi affittare da Amazon. E' questa la vera unità di misura per la lentezza di Python. E non è una misura che scopri coi benchmark, ma solo con le success story.

(che se vuoi, è anche il motivo per cui sono un po' sospettoso di cose come Flask. Se devi lavorare in Python, lavora in Django. Altrimenti, tanto vale farselo in Rust).

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re:Zitto zitto, Instagram è passato a python 3
« Risposta #5 il: Luglio 19, 2017, 10:07 »
A me invece la lezione sembra questa: oggi la legge di Moore è ancora un fattore sufficiente a spostare il peso della partita dalla parte di Pyhton.

Se sei piccolo, si. E il problema e' che in questo caso non e' facile rendersi conto di quanto si e' piccoli. Quando devi reggere una certa scala potresti trovarti facilmente a spendere qualche centinaio di milioni di euro all'anno, ma anche in un mese. E nei casi piu' grandi, potrebbe essere la spesa di un team. Quello e' il fatturato *annuale* di medie e medio grosse imprese italiane. Se limi l'infrastruttura del 1%, paghi lo stipendio a 5-10 ingegneri per un anno.

Semplicemente contesto che "la legge di Moore sia un fattore determinante" (salvo che la legge di Moore e' proprio la cosa sbagliata da tirare in ballo, visto e considerato di come sta andando l'hw ora e che Python non riesce davvero ad usare al pieno come funziona l'hw moderno -- GIL! --).

Sfortunatamente, in determinati contesti la faccenda e' ben diversa. Vale per tutti? No. Certo che no. Se stai facendo un gestionale (web) per un'azienda di 10-20 persone hai un set di problemi tutti diversi, e le performance di Python non sono fra questi. Anche perche' molto probabilmente il gestionale scala con il numero di utenti e ci va tempo prima di fare salire di un ordine di grandezza le persone. :)

Perche' non stanno facendo tutti cosi'? Almeno fra quelli di una certa dimensione?  La questione e' che le risorse (le persone) sono limitate e ci sono cose piu' urgenti da fare.

Al contrario di te, io credo che le success stories contano, e anche molto.

Vedi, il problema e' che le success stories (specie le versioni pubbliche) sono grosso modo aneddotiche. Io non faccio engineering basandomi sulle voci di corridoio.

Non parliamo poi del confirmation bias. Trovi success stories per qualunque tecnologia. Guarda caso poi quando uno le assorbe tipicamente legge quello che gli piace come un successo e attiva lo spirito critico per quello che non gli piace. Che vuole dire tipicamente trovare il contorno, capire il problema, etc etc etc. Quello che io consiglio di fare in ogni caso.

Quando uno vede che oggi, di fatto, uno degli oggetti più grossi di internet gira su python, non può non farsi delle domande su che cosa è davvero la velocità.

Mah, si, e anche sul meglio della vita e sul segreto dell'acciaio. Oppure uno puo' farsi domandi piu' precise con il fine di stabilire un robusto processo ingegneristico. E avrebbe sorprese sia sul concetto di "grosso"

Ma anche se fosse, resta il fatto che queste sono aggiunte successive montate su un'architettura in python. No, non in python - in Django, nientemeno!
Con buona pace della magia nera dinamica di django che rallenta le cose.
Sempre a proposito di limiti... quale e' la parte "lenta" di Django? Quale e' la parte di Django che loro probabilmente non usano (pensa al loro problema... e vedi che queste success stories non sono dei 6 pager di engineering da cui imparare lezioni?)

Cioe', tutto bene... ma capisci quello che intendo con bisogna capire per bene tutto il contesto.

Tra l'altro, mi e' giusto venuto in mente di un post scritto da quelli di disquis su come usassero (anni e anni fa) Django per fare 45K richieste al secondo. Che all'epoca erano parecchio. https://blog.disqus.com/scaling-django-to-8-billion-page-views

TL;DR: come fanno a fare 45K rps con Django? Non le fanno. Ci hanno messo davanti un varnish che ne assorbe 30K e devono farne solo 15K.

E' vero che se Instagram fosse scritto in Go (diamine, anche se fosse scritto in node.js!) loro risparmierebbero in costi di server.

Salvo che se fosse scritto in Node non sarei cosi' sicuro che eviti server... ma al di la di questo....

1. pensare che "Instagram e' scritto in x" e' in generale una visione ingenua. Sarebbe come dire che "Microsoft" e' scritta in C (ovviamente e' un assurdo). Instagram e' un insieme di servizi distinti che da fuori non sappiamo nemmeno che esistono che vediamo come un'applicazione unitaria. Potrebbe essere che il 100% e' scritto in Python con Django, ma poi ... e i db, e questo e quello. Insomma... E vuoi che nessuno abbia messo nessun layer di caching?

2. Una volta che abbiamo capito che Instagram non e' un grosso gestionale Python monolitico, servito da un gigantesco webserver hostato all'ombra dell'Yggdrasill, salta anche fuori che le varie componenti sono scritte indipendentemente (ovvero in generale non e' che per scalare aggiungi "un server", ma devi scalare delle flotte). Una volta che abbiamo capito anche vagamente la scala del problema, ci rendiamo conto che non "aggiungi un server". Ma scali la flotta del +20%. Come nota a margine, probabilmente non "aggiungi" server, avranno qualcosa di simile a quello che noi chiamiamo auto-scaling groups. Ecco, ora considera che una macchina media ti costera' qualche centinaio di dollari al mese (tipo 300$?). Trenta
 macchine pagano lo stipendio di una persona

Ma è anche vero che aggiungere server oggi è ancora più economico che pagare qualcuno che reinventa Django in Go, o qualcosa del genere.

Ovviamente questo assume che quelli di Go, poverini, non abbiano niente e stiano a scrivere manualmente il codice che legge e scrive da socket raw.

Inoltre, vorrei fare notare che tutta sta roba gira ad API (specie internamente). Quindi per il 90% dei servizi non hai bisogno di "Django", perche' non hai "il Database" (nota la maiuscola) e non stai facendo "pagine web". E se stai facendo API generiche, di Django usi poco. Va benissimo usare Django, eh.

Detto questo in Go ci sono ovviamente sia cosi per fare API piuttosto rapidamente (hei, perfino quello che e' nella libreria standard e' piuttosto buono) e ci sono anche ovviamente cosi per fare web "visto dal browser". Per dire.

E questo vuol dire parecchio, bada bene. Vuol dire che tutto il ciclo di vita di uno degli oggetti più grossi di internet, da garage software a 600 milioni di utenti, può essere sostenuto con successo da Pyhton. Mica male.

E a me questo non stupisce punto. Insomma... a seconda di quali sono i pattern di un servizio, quanti soldi si possono investire in ferro, in persone, quanta infrastruttura "fatta" si ha, etc etc etc... ci possono essere cose ben sorprendenti.

Poi magari salta fuori che Django e' semplicemente la flotta che sostiene il portale web che non fa altro che chiamare API e servire utenti.

Ma voglio dire... e' un servizio che di fatto presenta immagini. Immagini che saranno da qualche parte (io le avrei messe su S3 per parlare terminologia familiare, con un po' di CloudFront davanti). Ora, se ho questa architettura, il pezzo che crea la paginetta o che ti torna l'URL da cui prendere l'immagine non fa quasi niente rispetto a S3/CF che effettivamente *serve* l'immagine. E potrei anche dire (diciamo che fossi una startup su AWS) che faccio tutto in Python. E' vero. Semplicemente ho fatto offload di un bel pezzo di roba su un servizio managed. E nota... e' la cosa giusta da fare.

Guarda caso... dropbox, anche loro Python... una volta facevano esattamente questa cosa. I metadati se li tenevano loro, ma il file veniva da S3 (fonti pubbliche). Poi hanno deciso di fare una versione del backend fatta su misura del loro use case (con tanto, credo, di hw custom). E il software? Go. A quel punto Python sarebbe franato. Credo abbiano tenuto in Python la parte che era in Python

Avere un linguaggio e un ecosistema ricco di librerie di ottima qualità, con decenni di esperienza, affidabile e solido, oggi costituisce ancora un valore economico superiore al ventiduesimo capannone di server che ti devi affittare da Amazon.

Specie se non hai idea di quanto costa "affittare un capannone di server" (hint, non funziona proprio cosi').
« Ultima modifica: Luglio 19, 2017, 10:09 da riko »

Offline RicPol

  • python sapiens sapiens
  • ******
  • Post: 3.154
  • Punti reputazione: 9
    • Mostra profilo
Re:Zitto zitto, Instagram è passato a python 3
« Risposta #6 il: Luglio 22, 2017, 17:20 »
Sì ma mi sembra ovvio, nel 2017, che *tutto*, se lo guardi abbastanza da vicino, diventa un'altra cosa. Tutto è "offload". Fai offload ogni volta che importi NumPy. E con questo? Vorresti dire che un programma che importa NumPy "non è più python"? Vorresti dire che il programmatore non è più un programmatore python? Oddio, sì, probabilmente tu diresti proprio così.
Ma certo che non le fai 45k richieste con Django, ma certo che ci metti Varnish davanti. Ma diresti che non è più un'architettura Django? Diresti che i programmatori smettono di pensare e progettare in Django? Poi ci saranno degli aggiustamenti, non dico di no. Se usi Cloudfront non sei più un progetto python? Ma poi non è che uno possa gestire una cosa come Instagram o Dropbox senza mai aver letto nient'altro che il tutorial di Django, mi pare ovvio. Magari nel team avranno anche uno o due tizi che ne capiscono di... Varnish o quel che è, da aggiungere nel mix. Ma se è per questo, credo che avranno anche qualcuno che ne capisce di database. Se è per questo, avranno qualcuno che lavora sui css. Diresti che l'architettura non è più python? Che non è più un team python, un progetto python?

Oh, che poi magari è tutto un complotto e ci stanno mentendo, eh? Magari tengono incatenati nello scantinato venti cinesi che programmano in Rust, e noi non lo sapremo mai. Va a sapere.

Quello che mi colpiva di questa storia, sono due cose. Primo, che hanno migrato tutta la baracca da python 2 a 3, e solo per questo ne hanno quadagnato un tot per cento in velocità, senza dover fare nient'altro. Ed è poi il motivo che mi ha spinto a scrivere il post, in primo luogo. Ora, tu ovviamente (ovviamente!) dirai che una success story conta meno di zero, ma invece a me sembra che una success story come questa conti più di un benchmark, per cominciare. Qui c'è una grossa bestia viva, complicata, che sta in produzione da qualche annetto, e che semplicemente passando a python 3 è diventata più veloce. A me sembra una roba notevole già di per sé, nel contesto di tutte le infinite polemiche sul fatto che Python 3 sia la cantonata del secolo, blablabla.
Seconda cosa, mi stupiva che python avesse accompagnato *tutta* l'evoluzione del progetto,  e che l'architettura e il team fossero rimaste essenzialmente python. Con aggiustamenti, offload, trucchi e magie quanti ne vuoi, si capisce. Ma mi fa abbastanza impressione che una roba del genere sia anche solo possibile... cioè, che un progetto che sta ovviamente molto bene sul mercato, non abbia bisogno di dover cambiare tecnologia e migrare via da Python, quando il gioco si fa duro. Poi domani riscrivono tutto in Perl 6 e a me casca la lingua per terra, va a sapere.
Ma oggi così è.