Entenda o motivo que faz as atualizações do snap ficarem menores!
Um dos melhores recursos dos pacotes snap é que ele permite que os editores controlem quais dependências são enviadas com seu aplicativo: é infinitamente frustrante achar que seus usuários estão com software quebrado porque algumas bibliotecas com as quais você depende foram atualizadas sem o seu conhecimento. Os pacotes instantâneos resolvem isso, mas a um preço: são arquivos muito maiores para download. Esta é uma compensação aceitável para a instalação inicial, mas rapidamente se torna cansativa quando os clientes baixam atualizações para encaixes que já instalaram. Nesta publicação, descreverei o que fizemos para minimizar a quantidade de dados que deve ser baixado quando os clientes estão atualizando uma revisão de um encaixe para outro.
Atualmente, os sistemas com snaps instalados periodicamente consulta o snap store para qualquer atualização disponível. Para cada instantâneo, o cliente foi instalado, (o pacote do snap package) enviará as seguintes informações:
- O snap id do snap em questão.
- A arquitetura do cliente.
- O canal que o cliente está seguindo para este snap.
- A revisão que o cliente atualmente instalou.
- A loja segue um processo razoavelmente simples, verifica:
O editor lançou uma revisão mais recente para o canal e arquitetura sobre o qual o cliente perguntou?
O cliente tem permissão para acessar este snap? Se o snap for privado ou não gratuito, algumas verificações de autorização adicionais são realizadas.
Finalmente, a loja responde com uma carga útil que inclui um URL no qual a nova revisão instantânea pode ser baixada. O cliente agora pode baixar e instalar a revisão mais recente.
Nos últimos meses, lançamos um recurso chamado "Download Deltas". Como o nome sugere, isso envolve clientes podendo baixar um delta binário entre a revisão do snap que instalaram e a revisão em que estão atualizando. O resultado final é que as atualizações instantâneas precisam baixar menos dados e, portanto, devem ser mais rápidas.
Como os arquivos delta são gerados?
Nós implantamos um novo serviço privado (chamado 'snap-delta-service') que é responsável por criar deltas binários entre as duas revisões de um snap. Toda vez que um editor libera um encaixe em um canal, pedimos que o snap-delta-service gere um delta binário entre a revisão instantânea lançada anteriormente e a revisão instantânea recém-lançada. Por exemplo, considere o seguinte cenário:
Eu tenho um snap chamado what-snap (uma útil ferramenta de linha de comando para fazer a conversão de snap names para snap ids e voltar novamente simples) com as seguintes versões:
$ Snapcraft status what-snap
Track Arch Channel Version Revision
Mais recente amd64 stable 1.0 6
Candidato 1,0 ^
Beta 1.0 ^
Edge 1.0 8
Caso você não esteja familiarizado com a saída do status snapcraft , isso pode ser interpretado como: Para a arquitetura amd64 (eu omitido a listagem armhf para clareza), eu tenho a revisão 6 no canal estável e a revisão 8 no canal de borda. Testei a revisão 8 e quero liberá-la para o canal estável:
$ Snapcraft libera o que é 8 estável
Track Arch Channel Version Revision
Mais recente amd64 stable 1 8
Candidato 1 ^
Beta 1 ^
Borda 1 8
Isso colocará um delta binário da revisão 6 para a revisão 8 para esse snap. Uma vez que o delta tenha sido gerado, os clientes com um snapd suficientemente novo o suficiente baixarão o arquivo delta em vez da revisão completa em que estão atualizando. Isso pode ser visto nos registros snapd (eu omiti com algumas mensagens de log para melhorar a clareza desse exemplo):
Deltas habilitado. Adicionando o cabeçalho X-Ubuntu-Delta-Formats: xdelta3
Deltas disponíveis retornados pela loja: [{
6 8 xdelta3
Https: //store/14SRjukNTZYlZOH0EBZ4Uq3OLChy7RMI_6_8_xdelta3.delta
Https: //store/14SRjukNTZYlZOH0EBZ4Uq3OLChy7RMI_6_8_xdelta3.delta
1056245
77361810044ff3f552c582e8d ... ✄ ... bb2a01416079a2fd5c7f9887b58}]
Delta transferido com sucesso para "what-snap" no que-snap_8.snap.xdelta3-6-to-8.partial
Delta aplicado com sucesso para "what-snap" no que-snap_8.snap.xdelta3-6-to-8.partial, economizando 1114635 bytes.
Há alguns pontos interessantes deste log:
Na primeira linha, você pode ver que os clientes anunciam quais formatos delta eles entendem. Hoje, snapd entende o formato xdelta3 .
1. A segunda linha mostra-nos que a loja encontrou um delta adequado para esta atualização. Os dados que estão registrados são a revisão de origem, revisão de destino, formato delta, url de download anônimo, URL de download autenticado, delta filesize, delta sha3_384.
2. O resto do registro mostra que o arquivo delta foi baixado e aplicado com sucesso. Nós também registramos a quantidade de dados armazenados usando um arquivo delta. Neste caso particular, a poupança foi mínima, mas esta é uma pressão muito pequena.
3. É importante notar que, após este processo, snapd verifica se as afirmações sobre este pacote instantâneo ainda se aplicam (as "afirmações" no Ubuntu Core vernáculo são documentos criptograficamente assinados que indicam fatos sobre um snap). Isso significa que o resultado da aplicação de um delta deve ser bit-for-bit idêntico ao snap de destino completo.
Que economias de largura de banda posso esperar?
A quantidade exata de dados salvos depende de vários fatores, incluindo quanto mudou entre as revisões de origem e de destino e o idioma usado para criar o snap. A tabela abaixo mostra uma variedade de cenários de atualização diferentes em vários encaixes diferentes:
Um valor menor na coluna 'delta% ge' significa uma melhor economia de banda (por exemplo, '17%' significa que o cliente só precisa baixar 17% dos dados instantâneos completos). Como você pode ver, as economias reais variam um pouco. A melhor maneira de garantir que as atualizações sejam tão pequenas quanto possível é liberar o mais freqüentemente possível: as atualizações mais freqüentes se traduzem em deltas menores. Pelo mesmo motivo, os clientes no canal de ponta geralmente ganharão mais de deltas de download do que os clientes no canal estável .
Para onde vamos daqui?
O Download deltas foi ativado na produção por um tempo agora. Estamos confiantes de que eles estão nos salvando na largura de banda, mas há várias coisas que podemos fazer para melhorar.
O algoritmo xdelta3 que estamos usando nem sempre funciona particularmente bem - particularmente para idiomas que compilam um único grande binário (como ir). Existem outras ferramentas que podemos usar, o que resultaria em uma melhor compressão nesses casos, mas precisamos fazer mais pesquisas e engenharia antes que possamos implementá-las.
Atualmente, nós decidimos quais deltas gerar em tempo de liberação instantânea, e nós geramos apenas um delta do mais recente, mas o mais recente, para cada canal. No entanto, às vezes há clientes ainda em revisões mais antigos do snap que, portanto, não obterão um delta quando atualizassem para a última revisão lançada. Nesses casos, seria bom se pudéssemos reagir a essa situação e gerar deltas para esses clientes também. Outra possibilidade é que possamos enviar aos clientes uma cadeia de arquivos delta que os levará da revisão atual para a revisão mais recente, mas, na maioria dos casos, isso deixará de ser menos dispendioso do que simplesmente fazer o download da última revisão e também pode ser caro. calcular.
Finalmente, precisamos acompanhar a "taxa de sucesso / delta" - qual porcentagem de clientes com atualizações pendentes foram capazes de se atualizar usando um delta? Obviamente, queremos maximizar esse número, mas, à medida que as pessoas adotam o Ubuntu Core, talvez precisemos ajustar nosso algoritmo de geração delta para manter os padrões de uso do cliente. Vou acompanhar as métricas que coletamos e publicaremos uma análise uma vez que eu tenho algo interessante para falar.
Fonte
Até a próxima!!
Nenhum comentário:
Postar um comentário