Questa pagina illustra le misure necessarie per eseguire l'upgrade dell'applicazione Python a Python 2.7. runtime. Dopo aver seguito questa procedura dettagliata, l'applicazione può sfruttare Python 2.7 molte nuove funzionalità del runtime, tra cui il multithreading, il modello Jinja2 motore, accesso in byte e caricamento e diversi nuovi inclusi librerie di terze parti.
Prerequisiti e considerazioni
Per utilizzare Python 2.7, un'applicazione deve soddisfare i requisiti i seguenti requisiti:
- Se l'applicazione utilizza Django, deve utilizzare la versione 1.2 o successiva. Consulta la documentazione di Django per dettagli dell'upgrade.
- Se vuoi utilizzare richieste in parallelo, l'applicazione deve Utilizzare i gestori di script WSGI (Web Server Gateway Interface), come illustrato in Utilizzo di WSGI.
Oltre a soddisfare questi prerequisiti generali, devi usare versioni specifiche di alcune App funzionalità del motore e librerie di terze parti. Assicurati di aggiornare le versioni includere e importare nell'applicazione, nonché testarla a fondo dopo l'upgrade. Il seguente elenco identifica i principali problemi di compatibilità e rimanda a ulteriori risorse per risolverli:
- Prestazioni: le prestazioni dell'applicazione possono cambiare dopo l'upgrade a Python 2.7. Se registri un aumento della latenza di risposta, puoi aumentare la classe dell'istanza di frontend e abilita richieste in parallelo. Le richieste in parallelo consentono all'applicazione di funzionare più velocemente con un costo di istanza inferiore di istanze più grandi. Per saperne di più, consulta Gestione delle richieste nelle istanze.
- Django: Devi usare Django 1.2 o versioni successive con Python 2.7. Per informazioni su eseguire l'upgrade, consulta la sezione Django Note di rilascio.
- PyCrypto:
Crypto.Util.randpool
è stato ritirato a favore diCrypto.Random
. Per ulteriori informazioni, consulta la sezione Cosa da fare su RandomPool. webapp
: i modelli di app web sono deprecati in Python 2.7. Puoi invece utilizzare Django modelli direttamente, jinja2, o un altro motore di modelli a tua scelta.- WebOb: Python 2.7 supporta WebOb versione 1.1. Questa versione non è completa compatibile con le versioni precedenti (0.9). Se l'applicazione utilizza WebOb, devi testarlo a fondo per rilevare eventuali errori derivanti dall'upgrade.
- zipimport: Python 2.7 non supporta zipimport, ma Python 2.7 può nativamente importarli da file ZIP.
- simplejson: Python 2.7 non supporta simplejson, ma Python 2.7 include l'equivalente, e molto più velocemente, lo standard della libreria.
Richieste in parallelo e WSGI
La funzionalità Python 2.7 che influisce maggiormente sulla progettazione e sulle prestazioni della tua applicazione è il supporto di applicazioni multithread in grado di gestire richieste. La capacità di gestire le richieste in parallelo comporta un migliore utilizzo, che può migliorare significativamente le prestazioni della tua applicazione, in particolare per le applicazioni che utilizzano classi di istanze che sfruttano più core della CPU.
Per abilitare il multithreading, le applicazioni devono passare da un'interfaccia CGI (Common Gateway Interface) dei runtime Python precedenti a un gateway del server web Approccio basato su interfaccia (WSGI). Il motivo è che gli script CGI, che sono stati progettati per gestire le richieste in modo seriale, si basano su variabili di ambiente per l'accesso di input e output.
Mentre il modello WSGI per la gestione delle richieste fornisce alle applicazioni più l'accesso ai flussi di input e output (abilitazione di richieste in parallelo), la gestione di più richieste in parallelo può causare condizioni di gara quando la logica di un gestore di richieste si basa sui dati o interagisce con i dati in un ambito più ampio del locale, come lo stato dell'applicazione. Per questo motivo, è importante programmare in modo difensivo per affrontare le gare e garantire che L'applicazione WSGI è sicura per i thread.
Per maggiori dettagli, consulta Rendere l'applicazione Threadsafe.
Aggiornamento del file app.yaml
Python 2.7 richiede un'istruzione
Elemento di configurazione runtime
nell'intestazione di app.yaml
.
Tieni presente che l'elemento threadsafe: [ true | false ]
è obbligatorio per Python 2.7
diverse applicazioni. Se true
, App Engine invia richieste in contemporanea; se false
, App Engine li invia in modo seriale. Le seguenti
L'intestazione app.yaml
consente richieste in parallelo:
application: myapp version: 1 runtime: python27 api_version: 1 threadsafe: true ...
Utilizzo di WSGI
Il runtime Python 2.7 consente facoltativamente di eseguire direttamente un server web
all'applicazione Gateway Interface (WSGI), anziché utilizzare
run_wsgi_app
per eseguire il programma come script CGI.
Per farlo, sostituisci il gestore CGI (ad es. myapp.py
) in
app.yaml
con un WSGI
nome dell'applicazione (ad es. myapp.app
).
... handlers: - url: /.* script: myapp.app ...
Devi inoltre spostare l'oggetto dell'applicazione WSGI nell'ambiente ambito:
import webapp2 class MainPage(webapp2.RequestHandler): def get(self): self.response.headers['Content-Type'] = 'text/plain' self.response.out.write('Hello, WebApp World!') app = webapp2.WSGIApplication([('/', MainPage)]) """ Old code: def main(): run_wsgi_app(app) if __name__ == '__main__': main() """
Puoi comunque specificare gestori di script CGI in
app.yaml
; mentre le richieste gestite dagli script CGI vengono elaborate
in modo seriale, non contemporaneamente. Inoltre, non puoi avere
app.yaml
che combina script CGI e applicazioni WSGI e non puoi impostare threadsafe
su true
se definisci gestori CGI.
Alcune convenzioni dei runtime Python precedenti, come l'uso di
main()
e il controllo di
__name__ == 'main'
,
sono ora deprecati. Queste misure hanno aiutato gli script CGI del passato
rimangono nella cache, ma ora che esegui direttamente le applicazioni WSGI,
passaggi non sono più necessari.
Utilizzo della directory root dell'app
In Python 2.5, gli script CGI venivano eseguiti con la directory di lavoro corrente impostata sulla directory che conteneva lo script. Questo è cambiato in Python 2.7. Con WSGI, l'attuale directory di lavoro l'inizio della durata del gestore di richieste è la directory radice dell'applicazione.
Rivedi il codice dell'applicazione e assicurati che tutti i gestori siano scritti in modo che la directory di lavoro corrente sia la radice dell'applicazione.
Configurazione delle librerie
Il runtime di Python 2.7 include alcune moduli di terze parti. Alcuni di questi sono disponibili per impostazione predefinita; le altre sono disponibili solo se configurato. Puoi specificare la versione che vuoi utilizzare.
libraries: - name: PIL version: "1.1.7" - name: webob version: "1.1.1"
Puoi specificare che l'applicazione utilizzi la versione più recente del modulo. È utile se stai sviluppando un'applicazione che non ha ancora utenti: non occorre monitorare le nuove versioni. Ma se la tua applicazione viene usata attivamente, fai attenzione: potresti sorprenderti che la tua applicazione inizi a utilizzare una nuova della libreria. Per utilizzare l'ultima versione:
libraries: - name: PIL version: latest
Per un elenco delle librerie supportate, vedi Terze parti Biblioteche.
Rendere Threadsafe la tua applicazione
La gestione delle richieste in parallelo è semplice se ogni gestore interagisce solo con le variabili all'interno il suo ambito. Ma la situazione si fa rapidamente difficile se un gestore modifica le risorse mentre un altro le legge. per assicurarti che l'applicazione funzioni come previsto, anche anche se più richieste possono manipolare gli stessi dati che interferiscono tra loro, è noto come rendere l'applicazione "threadsafe."
Quando si progetta un'applicazione sicura per thread, la regola principale è limitare il più spesso possibile l'uso di risorse condivise (ad esempio, informazioni sullo stato o variabili globali). Tuttavia, in genere non è possibile escluderne del tutto l'utilizzo ed è qui che entrano in gioco i meccanismi di sincronizzazione come gli oggetti blocco.
In Python 2.7, hai accesso al threading libreria, che ti consente di dichiarare un blocco su un blocco di logica forza l'esecuzione in serie del codice al suo interno contemporaneamente. Considera il seguente codice:
class Configuration(ndb.Model): some_config_data = ndb.StringProperty() _config_cache = None _config_lock = threading.Lock() @classmethod def get_config(cls): with cls._config_lock: if not cls._config_cache: cls._config_cache = cls.get_by_id('config') return cls._config_cache
Questo codice mostra la creazione di una cache
alcune variabili di configurazione globali in una variabile denominata _config_cache
. In questo caso, l'uso di un oggetto blocco denominato _config_lock
garantisce che il controllo di un _config_cache
preesistente si comporti in modo affidabile. In caso contrario, questa variabile potrebbe perdere tempo
più corse in Datastore per impostare più viaggi per la stessa variabile
volte con gli stessi dati, perché tutte le richieste concorrenti hanno trovato
che _config_cache
era vuoto.
Non scegliere con leggerezza di utilizzare le serrature. Un blocco forza il blocco di qualsiasi altro thread che esegue questo metodo. Questo può rappresentare un collo di bottiglia per il rendimento.
Aggiornamento dell'applicazione a webapp2
Nota: se non usi webapp
come richiesta
puoi saltare questa sezione.
Il framework web incluso con il runtime Python 2.7 è stato
Upgrade eseguito da webapp
a webapp2. Tra le altre
cose, webapp2
aggiunge il routing URI migliorato e la gestione delle eccezioni,
un oggetto risposta completo e un sistema di gestione
meccanismo di attenzione.
webapp
modelli sono
sono ora deprecati. Al loro posto puoi usare Jinja2, Django,
o un sistema di modelli a tua scelta (purché sia scritto in puro stile
Python).
In App Engine, a webapp2
è stato assegnato un alias in webapp
e
webapp2
è compatibile con le versioni precedenti. Tuttavia, dopo l'upgrade, dovrai
testa la tua applicazione e acquisisci familiarità con il
nuova sintassi e funzionalità di webapp2
,
piuttosto che continuare a fare affidamento
sulla compatibilità con le versioni precedenti.
E il tuo upgrade è completo!
Una volta caricata l'applicazione, devi testarla a fondo per garantire la compatibilità con le versioni precedenti. Se riscontri problemi, consulta i forum.