O Google App Engine executa o código do seu aplicativo Python usando um interpretador de Python pré-carregado em um ambiente seguro do "sandbox". O aplicativo recebe as solicitações da web, realiza o trabalho e envia as respostas ao interagir com esse ambiente.
O Google App Engine sabe que deve usar o ambiente de execução em Python para o código do seu aplicativo quando você usar a ferramenta chamada appcfg.py do SDK para Python com um arquivo de configuração chamado app.yaml. Para selecionar o ambiente de execução em Python, use os seguintes elementos de configuração:
runtime: python api_version: 1
O primeiro elemento, runtime, seleciona o ambiente de execução em Python. A partir dessa gravação, o Google App Engine suporta apenas um tipo de ambiente de execução, python.
O segundo elemento, api_version, seleciona qual versão do ambiente de execução em Python deve ser usada. A partir dessa gravação, o Google App Engine tem apenas uma versão do ambiente em Python, 1. Se precisar lançar alterações para o ambiente que não sejam compatíveis com o código existente, a equipe do Google App Engine lançará um identificador de nova versão. O seu aplicativo continuará a usar a versão selecionada até que você altere a configuração de api_version e envie o seu aplicativo.
Para obter mais informações sobre app.yaml e appcfg.py, consulte Configuração do aplicativo Python e Como enviar um aplicativo.
Quando o Google App Engine recebe uma solicitação da web para seu aplicativo, ele chama o script manipulador correspondente ao URL, conforme descrito no arquivo de configuração app.yaml do aplicativo. O Google App Engine utiliza o padrão CGI para comunicar os dados da solicitação ao manipulador e receber a resposta.
O Google App Engine utiliza diversos servidores da web para executar seu aplicativo e ajusta automaticamente o número de servidores sendo usados para manipular as solicitações de forma confiável. Uma determinada solicitação pode ser direcionada a qualquer servidor e este pode não ser o mesmo que manipulou uma solicitação anterior do mesmo usuário.
O servidor determina qual script de manipulador em Python deve ser executado ao comparar o URL da solicitação aos padrões de URL no arquivo de configuração do aplicativo. Em seguida, ele executa o manipulador em um ambiente CGI preenchido com os dados da solicitação. Conforme descrito no padrão CGI, o servidor coloca os dados da solicitação em variáveis de ambiente e no fluxo de entrada padrão. O script executa as ações apropriadas à solicitação e, em seguida, prepara uma resposta e a coloca no fluxo de saída padrão.
A maioria dos aplicativos utiliza uma biblioteca para analisar as solicitações CGI e retornar respostas CGI, como o módulo cgi da biblioteca Python padrão ou uma estrutura da web que conheça o protocolo CGI (como o webapp). Você pode consultar a documentação de CGI para obter mais detalhes sobre as variáveis de ambiente e o formato dos dados do fluxo de entrada.
O script manipulador do exemplo abaixo exibe uma mensagem no navegador do usuário. Ele imprime um cabeçalho HTTP que identifica o tipo e o conteúdo da mensagem para o fluxo de saída padrão.
print "Content-Type: text/plain" print "" print "Hello, world!"
O Google App Engine coleta todos os dados gravados pelo script do manipulador de solicitação no fluxo de saída padrão e aguarda a saída do script. Quando o script é encerrado, todos os dados de saída são enviados ao usuário.
O Google App Engine não suporta o envio de dados ao navegador do usuário antes de sair do manipulador. Alguns servidores da web usam essa técnica para "transmitir" dados para o navegador do usuário por um período de tempo em resposta a uma única solicitação. O Google App Engine não oferece suporte a essa técnica de transmissão.
Se o cliente envia cabeçalhos HTTP com a solicitação, indicando que o cliente pode aceitar conteúdo compactado (através de gzip), o Google App Engine compacta os dados de resposta automaticamente e anexa os cabeçalhos de resposta apropriados. Os cabeçalhos de solicitação Accept-Encoding e User-Agent são usados para determinar se o cliente pode receber respostas compactadas de forma confiável. Os clientes personalizados podem forçar a compactação do conteúdo, especificando os cabeçalhos Accept-Encoding e User-Agent com valor "gzip".
Um manipulador de solicitação tem um período de tempo limitado para gerar e retornar uma resposta para uma solicitação, normalmente em torno de 30 segundos. Assim que o prazo é atingido, o manipulador de solicitação é interrompido.
O ambiente de execução em Python interrompe o manipulador de solicitação ao emitir um DeadlineExceededError, do pacote google.appengine.runtime. Se o manipulador de solicitação não identificar essa exceção, assim como com todas as exceções não identificadas, o ambiente de execução retornará ao cliente um erro de servidor HTTP 500.
O manipulador de solicitação pode identificar esse erro e personalizar a resposta. O ambiente de execução dá um pouco mais de tempo (menos de um segundo) depois de emitir a exceção para que o manipulador de solicitação prepare uma resposta personalizada.
|
from google.appengine.runtime import DeadlineExceededError
class MainPage(webapp.RequestHandler):
def get(self):
try:
# Do stuff...
except DeadlineExceededError:
self.response.clear()
self.response.set_status(500)
self.response.out.write("This operation could not be completed in time...")
Se o manipulador não retornar uma resposta nem emitir uma exceção até o segundo prazo final, ele será encerrado e uma resposta de erro padrão será retornada.
Embora uma solicitação possa levar até 30 segundos para responder, o Google App Engine é otimizado para aplicativos com solicitações de vida curta, normalmente para as que levam algumas centenas de milissegundos. Um aplicativo eficiente responde rapidamente a maioria das solicitações. Um aplicativo que não o fizer não escalará bem com a infraestrutura do Google App Engine.
Para permitir que o Google App Engine distribua solicitações para aplicativos em diversos servidores da web e para impedir a interferência de um aplicativo em outro, o aplicativo executa em um ambiente "sandbox" restrito. Neste ambiente, o aplicativo pode executar código, armazenar e consultar dados no armazenamento de dados do Google App Engine, utilizar o e-mail do Google App Engine, obter URL e serviços de usuários e examinar a solicitação de web do usuário e preparar a resposta.
Um aplicativo do Google App Engine não pode:
O ambiente de execução em Python utiliza Python 2.5.2.
Todo código feito para o ambiente de execução deve ser Python puro, sem incluir qualquer extensão C ou outro código que necessite de compilação.
O ambiente inclui a biblioteca Python padrão. Alguns módulos foram desativados, pois suas funções essenciais não são suportadas pelo Google App Engine, como redes ou gravação no sistema de arquivos. Além disso, o módulo os está disponível, porém com os recursos não suportados desativados. Uma tentativa de importar um módulo ou utilizar um recurso não suportado emitirá uma exceção.
Alguns módulos da biblioteca padrão foram substituídos ou personalizados para funcionar com o Google App Engine. Por exemplo:
TemporaryFile, que é substituído por StringIO.Além da biblioteca padrão de Python e das bibliotecas do Google App Engine, o ambiente de execução inclui as seguintes bibliotecas de terceiros:
Você pode incluir outras bibliotecas de Python puro com seu aplicativo, colocando o código no diretório do aplicativo. Se você incluir um link simbólico para o diretório de um módulo no diretório do seu aplicativo, appcfg.py seguirá o link e incluirá o módulo em seu aplicativo.
O caminho de inclusão do módulo Python inclui o diretório raiz do seu aplicativo (o diretório contendo o arquivo app.yaml). Os módulos criados no diretório raiz do aplicativo estão disponíveis utilizando um caminho a partir da raiz. Não se esqueça de criar os arquivos __init__.py nos subdiretórios, para que o Python reconheça-os como pacotes.
O ambiente de execução do Python armazena em cache os módulos importados entre as solicitações em um único servidor da web, de modo semelhante ao usado por um aplicativo Python autônomo para carregar um módulo uma única vez, mesmo que o módulo seja importado por diversos arquivos. Se um script manipulador fornecer uma rotina main(), o ambiente de execução também armazena o script em cache. Caso contrário, o script manipulador é carregado para cada solicitação.
O armazenamento de aplicativos em cache proporciona um benefício significativo no tempo de resposta. Recomendamos que todos os aplicativos utilizem uma rotina main(), como descrito abaixo.
Por uma questão de eficiência, o servidor da web mantém os módulos importados na memória e não os recarrega ou reavalia nas solicitações subseqüentes do mesmo aplicativo no mesmo servidor. A maioria dos módulos não inicializa dados globais ou tem outros efeitos colaterais ao ser importada, portanto armazená-los em cache não altera o comportamento do aplicativo.
Se seu aplicativo importa um módulo que depende de avaliação para cada solicitação, o aplicativo deve acomodar este comportamento de armazenamento em cache.
O exemplo a seguir demonstra como um módulo importado é armazenado em cache. Como mymodule é importado somente uma vez para um único servidor da web, mymodule.counter global é inicializado apenas com 0 na primeira solicitação servida pelo servidor. As solicitações subseqüentes utilizam o valor da solicitação anterior.
### mymodule.py counter = 0 def increment(): global counter counter += 1 return counter ### myhandler.py import mymodule print "Content-Type: text/plain" print "" print "My number: " + str(mymodule.increment())
Isso resulta em My number: #, onde # é o número de vezes em que este manipulador foi chamado pelo servidor da web que manipulou a solicitação.
Você pode instruir o Google App Engine a armazenar em cache o próprio script manipulador, além dos módulos importados. Se o script manipulador definir uma função denominada main(), o script e seu ambiente global serão armazenados em cache da mesma maneira que um módulo importado. A primeira solicitação do script em um dado servidor da web avalia o script normalmente. Nas solicitações subseqüentes, o Google App Engine chama a função main() no ambiente armazenado em cache.
Para armazenar um script manipulador em cache, o Google App Engine deve poder chamar main() sem argumentos. Se o script manipulador não definir uma função main() ou se a função main() exigir argumentos (que não tiverem padrões), o Google App Engine carrega e avalia o script inteiro para cada solicitação.
Manter o código Python analisado na memória economiza tempo e permite respostas mais rápidas. O cache do ambiente global também tem outros usos em potencial:
O script do manipulador deve chamar main() quando for importado. Como o Google App Engine espera que a importação do script chame main(), o Google App Engine não o chama ao carregar o manipulador da solicitação pela primeira vez em um servidor.
O exemplo a seguir faz o mesmo que o exemplo anterior, utilizando armazenamento em cache do ambiente global do script manipulador:
### myhandler.py # A global variable, cached between requests on this web server. counter = 0 def main(): global counter counter += 1 print "Content-Type: text/plain" print "" print "My number: " + str(counter) if __name__ == "__main__": main()
Observação: Cuidado para não "deixar vazar" as informações específicas do usuário entre as solicitações. Evite variáveis globais a menos que o armazenamento em cache seja desejado e sempre inicialize dados específicos à solicitação dentro da rotina main().
O armazenamento em cache de aplicativos com main() fornece uma melhora significativa no tempo de resposta do aplicativo. Recomendamos isso para todos os aplicativos.
O servidor da web do Google App Engine captura tudo que o script manipulador grava no fluxo de saída padrão da resposta à solicitação da web. Ele também captura tudo o que o script manipulador grava no fluxo de erro padrão e armazena em forma de dados de registro. Você pode exibir e analisar os dados de registro de seu aplicativo utilizando o Console administrativo ou fazer o download utilizando appcfg.py request_logs.
O ambiente de execução do Python do Google App Engine inclui suporte especial ao módulo de registro da biblioteca padrão de Python, para compreender conceitos de registro como níveis de registro ("debug", "info", "warning", "error", "critical").
import logging
from google.appengine.api import users
from google.appengine.ext import db
user = users.get_current_user()
if user:
q = db.GqlQuery("SELECT * FROM UserPrefs WHERE user = :1", user)
results = q.fetch(2)
if len(results) > 1:
logging.error("more than one UserPrefs object for user %s", str(user))
if len(results) == 0:
logging.debug("creating UserPrefs object for user %s", str(user))
userprefs = UserPrefs(user=user)
userprefs.put()
else:
userprefs = results[0]
else:
logging.debug("creating dummy UserPrefs for anonymous user")
O ambiente de execução inclui diversas variáveis de ambiente úteis para o aplicativo. Algumas são especiais do Google App Engine, enquanto outras fazem parte do padrão CGI. O código Python pode acessar essas variáveis usando o dicionário os.environ.
As variáveis de ambiente abaixo são específicas ao Google App Engine:
APPLICATION_ID: O ID do aplicativo sendo executado no momento.CURRENT_VERSION_ID: As versões principal e secundária do aplicativo sendo executado no momento, como "X.Y". O número da versão principal ("X") é especificado no arquivo app.yaml do aplicativo. O número da versão secundária ("Y") é definido automaticamente quando cada versão do aplicativo é enviada ao Google App Engine. No servidor da web para desenvolvimento, a versão secundária é sempre "1". AUTH_DOMAIN: O domínio utilizado para autenticar os usuários com a API de usuários. Os aplicativos hospedados em appspot.com têm AUTH_DOMAIN gmail.com e aceitam qualquer conta do Google. Os aplicativos hospedados em um domínio personalizado utilizando o Google Apps têm AUTH_DOMAIN igual ao domínio personalizado.As variáveis de ambiente abaixo são parte do padrão CGI, com comportamento especial no Google App Engine:
SERVER_SOFTWARE: No servidor da web para desenvolvimento, este valor é "Development/X.Y", onde "X.Y" é a versão da execução. As variáveis de ambiente adicionais são definidas de acordo com o padrão CGI. Para obter mais informações sobre estas variáveis, consulte o padrão CGI.
Dica: O manipulador de solicitação do webapp a seguir exibe todas as variáveis de ambiente visíveis para o aplicativo no navegador:
from google.appengine.ext import webapp
import os
class PrintEnvironmentHandler(webapp.RequestHandler):
def get(self):
for name in os.environ.keys():
self.response.out.write("%s = %s<br />\n" % (name, os.environ[name]))
Cada solicitação recebida para o aplicativo é computada para a cota Solicitações.
Os dados recebidos como parte de uma solicitação são computados para a cota Largura de banda de entrada (faturável). Os dados enviados em resposta a uma solicitação são computados para a cota Largura de banda de saída (faturável).
As solicitações HTTP e HTTPS (segura) são computadas para as cotas Solicitações, Largura de banda de entrada (faturável) e Largura de banda de saída (faturável). A página "Quota Details" (Detalhes da cota) do Console de administração também informa Solicitações seguras, Largura de banda de entrada segura e Largura de banda de saída segura como valores separados para informação. Apenas solicitações HTTPS são computadas para esses valores.
O tempo de processamento da CPU gasto com a execução de um manipulador de solicitação é computado para a cota Tempo de CPU (faturável).
Para obter mais informações sobre cotas, consulte Quotas (Cotas) e a seção "Quota Details" (Quota Details) do Console de administração.
Além das cotas, os seguintes limites são aplicados aos manipuladores de solicitação:
| Limite | Quantidade |
|---|---|
| tamanho da solicitação | 10 megabytes |
| tamanho da resposta | 10 megabytes |
| duração da solicitação | 30 segundos |
| solicitações dinâmicas simultâneas | 30 |
| número máximo de arquivos de aplicativo | 1.000 |
| número máximo de arquivos estáticos | 1.000 |
| tamanho máximo de um arquivo de aplicativo | 10 megabytes |
| tamanho máximo de um arquivo estático | 10 megabytes |
| tamanho máximo total de todos os arquivos de aplicativo e arquivos estáticos | 150 megabytes |
* Um aplicativo pode processar cerca de 30 solicitações dinâmicas ativas simultaneamente. Isso significa que um aplicativo do qual a média de tempo de processamento de solicitação no servidor é de 75 milissegundos pode atender até (1000 ms/segundo / 75 ms/solicitação) * 30 = 400 solicitações/segundo sem sofrer nenhuma latência adicional. Os aplicativos que são muito limitados pela CPU podem sofrer de latência adicional em solicitações de longa duração de modo a liberar espaço para outros aplicativos que compartilham os mesmos servidores. As solicitações para arquivos estáticos não são afetadas por esse limite.