Olá, cidadãos de Habrovsk!
Retornamos de uma conferência para desenvolvedores do
DotNext .NET e compartilhamos honestamente nossas impressões sobre os relatórios mais memoráveis. Esperamos que nossa análise seja útil para quem assiste a vídeos de performances.
Parte das apresentações foi publicada no site da conferência, portanto, complementamos algumas das revisões com links para elas.
1º dia
Usando Tarantool em projetos .NET - Anatoly Popov ( apresentação )
O relatório começou com uma revisão da evolução dos bancos de dados SQL -> NoSQL -> NewSQL, seus prós e contras. Anatoly disse por que, de fato, a necessidade de NewSQL amadureceu - esta é uma tentativa de cruzar o desempenho NoSQL e a linguagem de consulta SQL, para a qual um bilhão de ferramentas úteis estão disponíveis.
O recurso a seguir foi mencionado sobre o Tarantool - os registros são armazenados como tuplas de comprimento arbitrário. Sob o capô, o Tarantool usa árvores LSM.
A parte principal do relatório, Anatoly, falou sobre a luta pelo desempenho na implementação do driver Tarantool para .NET. Novas abstrações do Readonly Span e do pool IMemoryOwner entraram em ação. O padrão é de 200k RPS, o que dá ao motorista Golang, e até agora conseguiu atingir 1/3 do resultado. O palestrante garantiu que ele melhoraria gradualmente os indicadores, mas os planos e as perspectivas futuras específicas permaneceriam na neblina.
Otimizações dentro do .NET Core - Egor Bogatov
Yegor cercou sua história sobre as entranhas do mono e do ryuJIT com humor apropriado, ao contrário da mesma unidade de Mutel, a quem era bastante sonolento ouvir.
Egor abordou o tópico de auto-vetorização de cálculos em mono, também falou sobre instruções SSE-AVX, agora disponíveis diretamente em C #.
Olhando para o futuro, ele nos disse que na compilação do .Net Core 3 nos espera, ou seja, um jit pesado separado aparecerá em tempo de execução como o servidor em Java. No ryuJIT, são esperadas novas otimizações para o desenrolar do loop e a análise de escape (a última é serrada por um aluno, deixe o github ajudá-lo).
Nosso comentário: Hoje, uma reserva impressionante permanece para um aumento ainda maior no desempenho da plataforma, pois muitas otimizações importantes do mundo Java e os compiladores estáticos clássicos ainda não são aplicados no .Net.
Desenvolvimento web moderno com SAFE-Stack - Steffen Forkmann
Stefan é um apologista ardente da linguagem F #. No relatório, ele compartilhou sua experiência em desenvolvimento web, totalmente construído em cânones funcionais. Aqui você tem o Functional MVC Web Framework (Saturn) e o Fable para traduzir F # em JS, e uma interface de usuário semelhante ao Elm, bastante experiente com frases muito boas e muito boas. O relatório como um todo não é ruim e confirma as habilidades sobrenaturais de religiões alternativas.
Criando aplicativos Xamarin à prova de modo de avião - Gerald Versluis ( apresentação )
De acordo com o método de apresentação, o relatório é muito semelhante ao relatório SAFE-Stack e se parece com um programa "Smack": primeiro colocamos o componente Essentials para detectar o acesso à Internet em uma placa com o aplicativo, depois passamos a API REST pelo Refit, esfriamos os dados no cache Akavache, espalhamos Polly por cima para manipulação inteligente de erros de solicitações de rede. Não foi sem a auto-ironia holandesa, porque o aplicativo falhou continuamente aleatoriamente no simulador.
Arquitetura multi-inquilino do ASP.NET Core: desafios e soluções - Halil İbrahim Kalkan ( apresentação )
O relatório descreve todos os principais recursos da arquitetura de aplicativos multilocatário.
A idéia principal é que, quando uma empresa desenvolve aplicativos SAAS, deseja usar a infraestrutura ao máximo. Portanto, ele possui vários clientes no mesmo servidor para que o servidor não fique ocioso. Isso causa um problema relacionado ao fato de que todos os dados de clientes diferentes são como se estivessem na mesma caldeira. O relatório concentra-se em soluções que permitem acesso confiável a esses dados.
Um excelente relatório em que tudo é colocado nas prateleiras. Exemplos simples e compreensíveis, sem detalhes desnecessários - eles são escritos com muita elegância, usando padrões e abordagens modernas. Eu assisti com prazer.
Design orientado a domínio: uma receita para um pragmático - Alexey Merson ( apresentação )
Um excelente relatório sobre os conceitos básicos de DDD. Qual livro ler primeiro: "azul" ou "vermelho"? Como a equipe inteira pode falar o mesmo idioma? É possível usar a nomeação cirílica em programas em C #? Como finalmente parar de ter medo da interface separada e tornar o código do domínio independente do restante do aplicativo? Todos esses pontos com exemplos são destacados neste relatório.
Alexey enfatiza a importância da linguagem (linguagem única) para a implementação de um contexto limitado. Ele disse como escolher o tamanho do contexto limitado e que tipos de subdomínios podem ser. O relatório também disse que um contexto limitado é igual a um microsserviço - isso se correlaciona bem com a nossa experiência na implementação de projetos.
Foi interessante ouvir sobre a essência da arquitetura bulbosa e os profissionais em comparação com a arquitetura de três e quatro camadas.
O relatório é ideal para quem é novo no DDD e deseja transferir seus monólitos para microsserviços e para quem começa a desenvolver soluções de microsserviço.
Dia 2
Teste de unidade pragmático - Vladimir Khorikov ( apresentação )
Um dos melhores relatórios e palestrantes em nossa opinião.
Vladimir classificou nas prateleiras qual é o verdadeiro objetivo dos testes para o projeto, quais métricas determinam a qualidade dos testes, como os vários tipos de testes correspondem a essas métricas. Não se pode discordar de todos os pensamentos, portanto deve-se ver.
Khorikov gravou muitos cursos na Pluralsight - procure-o lá. Ele também tem um bom
blog .
Instant Design - Maxim Arshinov ( apresentação )
Continuando o relatório de Merson sobre DDD, Maxim falou sobre a transição das camadas clássicas de código para a arquitetura de cebola, ao longo do relatório refatorando o método de atualização do email do usuário. O resultado foi um pipeline de decoradores (oi, yegor256) no estilo CQRS com a digitação de DTO mais rigorosa (oi, FSharpForFunAndProfit).
Como resultado, recebemos um guia pronto para a ação, que pode ser usado no projeto para obter o mesmo código elegante que o CPC
Em geral, o relatório é extremamente cheio de idéias úteis. A experiência de Maxim no ensino teve um impacto positivo em seu nível de habilidades como palestrante - ouvir a apresentação foi agradável.
Por trás do compilador burst, convertendo .NET IL para código nativo altamente otimizado usando LLVM - Alexandre Mutel
Aparentemente, o Unity mostrou seus dentes em jogos da classe A e, portanto, o igrodelov precisa de desempenho muito mais próximo do C ++. Mutel contou como eles obtêm bons resultados destacando um subconjunto da linguagem C # (HPC #), que possui estruturas prontas para um trabalho eficiente com memória sem GC e algumas construções familiares de linguagem.
A idéia é aplicar esse subconjunto apenas aos métodos mais caros, para que em outros lugares as mãos sejam desatadas como sempre (na medida do permitido no game dev). Um novo compilador de burst AOT / JIT está sendo desenvolvido para compilar o HPC #. O burst em comparação com o ryuJIT já dá 10x em alguns testes sintéticos.
Os exemplos mostrados do assembler gerado mostram o quão inteligente o compilador se saiu. E a solução sozinha e ninguém fica surpreso - o código IL é alimentado no LLVM. Os intrínsecos também são escritos para matemática usando uma biblioteca de alto desempenho de terceiros.
O relatório é difícil de entender, o orador é muito duro.
A vida dos atores em um cluster: por que, quando e como - Vagif Abilov ( apresentação )
O relatório revelou que metade da audiência está sentada em F #. Talvez seja a coisa mais agradável que estava neste relatório. A apresentação terminou com um canto ao vivo sobre o cérebro dividido em um cluster. É glorioso.
Como sobreviver sob carga: servidor tolerante a falhas, cliente inteligente - Igor Lukanin ( apresentação )
Igor falou sobre a cozinha pesada nos projetos Kontur. Fiquei surpreso que a empresa use um "balanceador" no cliente: a API envia informações sobre o carregamento dos nós e status do cluster 429, dependendo de qual cliente entende como distribuir solicitações. Ele também mostrou as métricas de utilização de recursos e como determinar se tudo está bom ou tudo está ruim. Ele explicou como cotar solicitações por tempo limite e por cliente, e também por que é melhor processar a fila na ordem LIFO.
O microfone era de um orador experiente, ouvindo Igor era confortável.
Arquitetura de desempenho do Dodo IS - Georgy Polevoy ( apresentação )
A princípio, o relatório parecia bastante tedioso: o ritmo incerto da narrativa, slides chatos com listas de tecnologias, definições bem conhecidas. Em algum momento, surgiu uma suspeita: em breve o orador dirá que tudo o que é necessário é uma fila na entrada. Mas não foi tão simples.
Descrevendo brevemente o relatório, podemos dizer que ele foi dedicado aos recursos da biblioteca
Polly , como Política de Nova Tentativa, Isolamento de Antepara, Fallback, e é temperado com excelentes exemplos da vida da Pizza Dodo.
A tendência dos últimos anos é usar assincronia em todos os lugares. Mas essa tendência tem um efeito não óbvio - isso leva ao fato de que os recursos do servidor estão "entupidos". Anteriormente, tudo era limitado a um pool de threads. O servidor da Web tinha um conjunto fixo de encadeamentos que processavam solicitações de entrada executando operações síncronas. Isso limitou a carga no servidor. Cada encadeamento foi liberado e recebeu outra solicitação de processamento quando todo o trabalho foi realmente concluído.
Hoje, os desenvolvedores costumam escrever código assíncrono sem pensar nas consequências. Como resultado, os fluxos do servidor da Web, iniciando a próxima tarefa assíncrona, são liberados e passam a processar cada vez mais solicitações. Com o tempo, o número de operações assíncronas competitivas está aumentando e o servidor da Web continua aceitando cada vez mais solicitações.
O autor em seu relatório apenas diz o que é simultaneidade e por que deve ser limitada. A propósito, esta e outras tarefas de gerenciamento de carga e tolerância a falhas são auxiliadas pela biblioteca Polly.
Em geral, mesmo se você não estiver desenvolvendo serviços altamente carregados, verifique este relatório de qualquer maneira.
Construindo aplicativos responsivos e escaláveis - Jeffrey Richter ( apresentação )
Este é um relatório bastante antigo de Jeffrey Richter. Pode ser encontrado na Internet por pelo menos um ano, e o tópico não tem pretensão de novidade. Mas diabos, é Jeffrey Richter! Não podíamos deixar de ouvir o autor do livro, que é considerado a Bíblia de qualquer desenvolvedor de C #. O velho Jeffrey era uma pessoa legal e um bom orador. Nós apenas nos divertimos.