2010-07-09 15 views
5

Sto sperimentando con GAE negli ultimi 2 mesi.Quanto è veloce Google App Engine?

Sto salvando i record sul bigtable caricando il file CSV.

La dimensione del file di prova è 300 KB.

Ecco quello che ho trovato

sistema locale

  • Carica prendere meno di 1 secondo
  • di processo 2500 record in 3 secondi

Su Google Sandbox

  • Il caricamento richiede 5-7 secondi.

  • Il file di elaborazione dà il timeout.

  • Salva solo 60-180 record.

Le mie domande sono

  1. perché ci vuole troppo tempo?
  2. C'è un modo per ridurre questo tempo?
  3. Google conta questa elaborazione per gli usi della CPU. Non rivelano h/w quindi quale CPU usano internamente? Voglio dire, ottengo una CPU equivalente o superiore a PIII?

cura per risposta @Drew Sears s'.

quello che sto facendo attualmente

  1. caricare il file da Gae
  2. vengono caricati byte di dati. Per flusso, contare le linee, salvarlo in bigtable.
  3. C'è un campo unico, id, mio ​​record.
  4. Ora, creo coda

int x = linesCount/50;

for(int i<0;i=x;i++) 
{ 
     x = i * 50; 
     Queue queue = QueueFactory.getQueue("test-queue"); 
     queue.add(TaskOptions.Builder.url("/TestQueue") 
       .param("id", id.toString()) 
       .param("startIdx",String.valueOf(x)) 
       .param("totRec",String.valueOf(50)) 
     ); 
    } 

int y = linesCount % 50; 
if(y > 0) 
{ 
    x = (linesCount/50) * 50; 
    Queue queue = QueueFactory.getQueue("test-queue"); 
    queue.add(TaskOptions.Builder.url("/TestQueue") 
      .param("id", id.toString()) 
      .param("startIdx",String.valueOf(x)) 
      .param("totRec",String.valueOf(y)) 
    );      
} 

L'elaborazione compito servlet file dalla memoria e l'utilizzo di totRec e startIdx processo il file e chiuderlo leggere ..

+0

È la volta che si verifica su google sandbox alla prima richiesta? Che dire delle richieste conseguenti? – naikus

+0

La latenza che si sta verificando non è causata dalla mancanza di alimentazione della CPU, ma dall'implementazione del datastore GAE (e della connessione di rete). GAE condivide le risorse con altre applicazioni sugli stessi server, ma hanno un sacco di cicli della CPU per andare in giro ... È il datastore che è in ritardo. –

+0

In prima richiesta salva solo 60 rceords. La prossima richiesta migliora la velocità e salva 120-150 record. ora il massimo va a 184 record – Manjoor

risposta

4

Questo non è davvero un ottimo modo per testare la scalabilità di App Engine.

  1. Se si sta prendendo 7 secondi per inviare 300 KB, il collo di bottiglia è quasi certamente la larghezza di banda a monte, non la larghezza di banda downstream di Google, o nulla a che fare con App Engine.Di solito ottengo velocità di caricamento molto più veloci.
  2. Se si desidera che le richieste vengano completate più rapidamente, ridurre al minimo le chiamate RPC. Ogni datastore get, put o query è un round trip su un server esterno. Se stai eseguendo il ciclo su centinaia di righe e fai un put all'interno di ogni iterazione del ciclo, stai incorrendo in una quantità enorme di costi aggiuntivi non necessari. Salva tutte le tue entità usando un datastore messo e otterrai risultati molto più veloci. Guido AppStats framework è un ottimo strumento per trovare opportunità di ottimizzazione RPC.
+1

+1 per menzionare i pericoli di eseguire una put() separata per ogni riga –

+0

Posso ridurre al minimo la richiesta RPC ma come posso ridurre la richiesta del datastore? Devo salvare i record 3k che richiedono la chiamata al database 3k put (o makePersistant() nella mia situazione). Esiste un metodo di salvataggio in serie? s – Manjoor

+0

Stessa cosa. Ogni richiesta del datastore è una chiamata RPC. Sì, il datastore consente di memorizzare più entità in un'unica chiamata. In Python questo è solo db.put() con una lista di entità; Non so quale sarebbe la sintassi in Java. –