Panoramica di Google App Engine

0

Ho seguito molte esercitazioni di Google App Engine e sono diventato abbastanza familiare su come eseguire attività di base come l'implementazione di webapp2.RequestHandler e l'utilizzo di ndb.Models per gestire i dati.

Ora, ho raggiunto un muro con alcuni piccoli concetti che mancavano dalle risorse in cui sono andato, o semplicemente mi mancavano. Quindi, eccoli qui:

Che cosa succede alle variabili di classe?

Per quanto ho capito, una volta impostata la mia app su thread-safe, è in grado di gestire più richieste contemporaneamente, per non parlare eventualmente di macchine diverse. Significa che semplicemente non posso usare le variabili di classe (che possono essere modificate in qualsiasi momento)?

Come modellare una logica a livello di applicazione?

È molto semplice scrivere la logica associata alle richieste. Non devo preoccuparmi del blocco o di una di queste cose, dal momento che un nuovo RequestHandler viene istanziato per ogni richiesta. Che dire della logica a livello di applicazione? Ad esempio, se avessi un modulo python chiamato "Game", e dopo averlo importato, faccio qualcosa del tipo:

Game.matchmaking_queue.append(player)

Per quanto ne so, c'è solo un'istanza Game , e ha una variabile di istanza a cui si accede dalla logica RequestHandler . Andrà bene? Devo rendere il matchmaking_queue supportato su memcache e / o datastore in modo che tutte richiedano di vederlo? Devo fare qualsiasi magia thread-safe su Game ?

    
posta Mazyod 01.01.2014 - 12:08
fonte

2 risposte

1

Alcune pratiche che si sono rivelate utili per me.

  • Limita te stesso alle variabili locali e di istanza. (Gli oggetti immutabili di BTW hanno molti aspetti positivi, quindi potresti anche non aver bisogno di variabili di istanza.)
  • Non utilizzare variabili globali e di classe, tranne come costanti.
  • Per lo stato globale utilizzare un database appropriato. Datastore e Cloud SQL funzionano bene.
  • Usa memcache il più possibile. Cache tutto ciò che usi spesso. Memcache è economico e veloce. Controllare sempre prima il valore memorizzato nella cache, quindi recuperare dal DB se la cache è obsoleta è un po 'scoraggiante; fatelo fuori.
  • Il datastore ha un buon throughput, ma una significativa latenza e limitazione della scrittura e le scritture sono relativamente costose. Ricordati di questo, altrimenti esaurirai la tua quota gratuita troppo velocemente.
  • Datastore è NoSQL; scrivere blocchi di dati di grandi dimensioni in una sola operazione, se possibile.
  • Il datastore non ama gli aggiornamenti molto veloci dello stesso valore (ad esempio un contatore in rapido movimento). Diffondi le scritture se necessario.
  • Utilizza le code per i processi asincroni. Generalmente l'uso di thread non è una grande idea.

Se ti capita di conoscere Erlang (o forse Play framework per Java / Scala), prova a pensare come stai usando questi, in termini di messaggi e code, non di variabili. Quindi GAE diventa improvvisamente semplice e logico :)

    
risposta data 01.01.2014 - 14:25
fonte
2

GAE può utilizzare diversi processi per gestire richieste diverse. Questi diversi processi non hanno nemmeno bisogno di essere sulla stessa macchina o nello stesso datacenter. Poi di nuovo, le diverse richieste possono essere indirizzate allo stesso processo.

Ciò significa che qualsiasi stato "globale" (modulo globale, inclusi gli attributi direttamente sulle classi) verrà condiviso tra le richieste all'interno di un processo . Vedi Memorizzazione nella cache dell'app nella documentazione di GAE Python.

In altre parole, non puoi contare se esiste uno stato globale condiviso tra tutte le tue richieste, ma dovresti fare uso di uno stato globale condiviso tra alcuni delle tue richieste.

Se hai bisogno di condividere qualcosa tra le richieste tutte , devi usare l'archivio dati.

    
risposta data 01.01.2014 - 13:57
fonte