 Quem sou eu? Eu sou o Zé, Zé Maurício e o J ali é José, tá? Eu não vou falar todo o nome, porque aí é muito tenso. Mas vamos lá. Lightspeed é um web server que ele é um web server considerado novo, vamos dizer assim, né? Não tem muito tempo. E vamos falar um pouquinho sobre ele hoje e os recursos que ele implementa. Que gordê é esse? Tá? Coach, sou coach. O que é o Lightspeed? Lightspeed é um web server. Ele foi criado para substituir a paz. Detalhe com botãozinhos. Entendeu? Switch to Lightspeed, switch to a paz. Então ele tem a versão paga, licença, mensal ou vitalícia. Poder, se quiser, comprar uma licença vitalista, paga um pouquinho mais lá, até o proeste da vida. E tem o Open Lightspeed também, que o Open sofre. Vamos falar um pouquinho dele, que ele foi lançado em 2003. Em agosto de 2008, tornou-se 16 servidor web mais popular. Em 2016, cresceu de 39 para 3.9, de 10 para 4. Em 2017, estima-se que está executando 9.2% dos sites HTTP2. E em 2017, era usado por 97.5% dos sites que usam Quick. Quando você aqui já ouviu falar em Quick, quase isso aí. Vocês estão achando que não tem o Quick na minha apresentação, né? Então tá. Vamos falar um pouquinho dos lançamentos aqui. É só para encher linguiço e demorar um pouquinho mais a paresta. Foi fundado por um equímico de engenheiros liderado por George Vang. Em 2003 foi oficialmente lançado como um web server completo. Em 2007, aqui que está utiando o negócio, ele pegou e se tornou Enterprise e foi configurado para ser um substuto do Apache. Em 2007, ele também foi integrado aos principais painéis, que são para quem trabalha com painel, né? Como... Mar, cadê o Alessandro? Alessandro, te admiro, cara. Não, falando sério. Eu falei que eu tenho Windows ali, né? Eu falei que ia contar o segredo no Contei, né? Contei, não? Eu sou desenvolvedor da Tenet. Detalhe Open Source. Vocês sabiam disso? Ah, viu? Peguei vocês. Visual Studio, Community. Sabiam disso? Não, mas não é. Vamos voltar para o ar de perto. Eu admiro porque... Ah, eu admiro esse cara que mexe em leno, que faz o que ele fez aqui, ver de cabeça para baixo. Tudo lento e comando. Porque eu sou do tempo do DOS, onde a gente brincava no Atrib, para esconder os arquivos dos nossos professores na rede novela. Então... Vamos lá. Lançado em 2015, foi lançado o Lightspeed Cache. Esse é para vocês aí. Login de WordPress. Com... Eu vou falar em português. ESI. Na versão 5.010. Em 2007, 2017, o Lightspeed Web Service lançou suporte ao Quick. Beleza? Quantos aqui mesmo já ouviram falar no Quick? Um, dois, Alessandro. Beleza. Compatibilidade. Tá aí o Login para vocês verem mais rápido. Tá? Quem está cuidando do tempo aí? O que são essas siglas aí? Quem já ouviu falar no Speed. SPDY. Speed já tem mais gente aí, né? Lá em cima. E na HTTP2. Show. Vocês sabem o que isso aí mudar a vida de vocês? Todo mundo sabe? E o Quick. Tá ali o Quick. Não é aquele ali não, tá? Mas se fala Quick igual. O Speed foi um protocolo desenvolvido que... Vou falar rapidinho, tá? Eu tenho um link ali depois. Vocês podem baixar os slides. Ele foi um protocolo desenvolvido pelo Google, pelo engenheiro do Google, para agilizar. Porque o HTTP1 foi um logado em 97. Mudou alguma coisa de internet lá para cá, né? Alguém aqui... Não tinha nascido ainda em 97? Uma, ali, ó. Para tu ver. Olha só. O HTTP2, esse mês, está fazendo 3 anos. Para você ver a quanto tempo a gente ficou em cima do HTTP1. 3 anos de homologação. A HTTP2 foi derivada do protocolo Speed, desenvolvido pelo Google. Hoje, se você entrar na página de referência lá do Chromium... Sabe o Chromium? Que ele... Quase igual o Chromium, azuzim, lá. E tem a referência lá. Você vê que esse protocolo está... E o sucessor é o HTTP2. E o Quick, o que é? O crônome de Quick, o DP Internet Connections. Aí começa a brincadeira legal. Eu vou abordar um pouquinho mais ele. Sei que é sob dinamismo e tal. Mas é o que vai vir daqui para frente na nossa vida. O Google já está usando, ele é mais ou menos 5 anos. Se você não sabe. Vamos lá. É o novo protocolo desenvolvido pelo Google, altamente processo, padronização, grupo de trabalho Quick da IETF. Ativado desde agosto de 2003. Está vendo? No Chromium, ou seja. E é o protocolo de internet da próxima geração. Projetar para compensar a deficiência do HTTP2. Ou seja, o HTTP2 com 3 danos já tem deficiência que o Quick, a 5, já está matando elas. Construído com segurança em mente. Porque o Quick não roda se não for sobre a SSL. Projetado para reduzir a latência devido ao Handshake e perda de pacote. Handshake. Todo mundo sabe que é que ninguém perguntou. Handshake é quando o... Handshake. É o servidor e ele o browser. Entendeu? Handshake. É a comunicação, foi bem prático, né? Vocês acharam que era palhaçar, mas era não. É a comunicação entre o browser e o servidor. Então, para reduzir a latência devido ao Handshake entre os dois. Ou seja, essa comunicação entre o browser e o servidor é para reduzir essa latência que ele foi criada. Aqui nós temos, graficamente, o protocolo HTTP2, o Handshake dele e o Handshake do Quick. Vocês podem analisar aí. Aqui nós temos o RTT, Handshake Time, tempo de ir de volta. Aqui tem duas conexões repetidas e uma finalizando a primeira conexão com três RTTs e no Speed, nenhuma conexão repetida e a primeira conexão, uma RTT. Então, esse aí é o Quick, tá, galera? Isso em desempenho, em carregar... Cara, enfim... Tem uma pessoa aqui... Cadê ele? Descobriu que eu ia dar essa palestra e, antes da palestra, conseguiu meu contato. Nem sei como. Me ligou no meu celular. Eu falei assim, cara, aí eu liberei no meu server, um painel para ele trabalhar. Bota o seu site mais pesado aí e vê o que acontece. Depois vocês perguntam para ele o que aconteceu. Eu falei assim, cara, não me deixa mentir sozinho lá, me ajuda. Por que usar o Quick? Só para frasear aqui. O Quick está disponível em apenas dois web servers. Lightspeed, pago. E... Candida. O doce desse sim. Não convi falar no server server, mas é só nesses dois. Está disponível. Redução do... Por que o Quick é mais rápido, né? O Quick, eu sempre boto o Quick para vocês fixarem o Quick. Calma aí, vocês vão esquecer o Quick. Reduz o tempo de estabelecimento de conexão para um caminho de página mais rápido. Usa multiplexão para evitar o head of line blocking. Head of line blocking. Melhor o controle do congestionamento e a eficiência para usar... Aficiência da rede para uma melhor experiência do usuário. E efetivamente manipular a migração de conexão e o ambiente de rede altamente variável. Então assim, é só coisa boa. Ele é seguro. Ele é estável. Somente dois browsers, por enquanto, o suporto. Chrome ou Opera. Como ele é um... Ele está muito novo ainda. Sabe vocês terem ideia? Ele entrou no Lightspeed no final de 2017. Esse protocolo. Os browsers ainda estão no processo de implementação. O Chrome, como vocês viram, já o usa desde 2013. Quando você acessa uma página do próprio Google, ela já está implementada esse protocolo desde essa época. Porque agiliza muito. Imagina o Google, o que ele consome de banda. Imagina o Handshake que ele faz com o mundo inteiro. Imagina o que ele economiza de transação, de velocidade, de tudo. Então foi pensado nessa situação. Por que usar o Quick e por que ele é lesgal? Porque só o Google deve ter toda a diversão. Eu pergunto para vocês, por que não nós? Podemos ter o Quick nos nossos sites também e quem usa Chrome ou Opera acessar com um nível diferenciado. Quick é o futuro, seja parte disso. Todas as fontes aí estão nos slides. Aqui eu botei mais algumas coisinhas sobre qualidade de produção que está disponível para milhões de sites, possui lógica interna para se defender contra a taxa TDOAS de perfil de pacotes, arquitetura multiprocessada, suporta push de servidor, HTTP2 também, e é mais rápido. Pode ser usado como um prox. Vamos parar de falar do Quick. Quick é show, qualquer fera, ainda mais o de morango. Vamos agora falar um pouquinho dos benchmarks do Lightspeed WebServe com Wordpress. Aqui nós temos. Vou explicar para vocês como funciona o Lightspeed. Eu falei ali do LS cache. O Lightspeed cache é um plug-in para Wordpress. Quem tem acesso ao servidor Web com Lightspeed, ao CPNEL, ao WHM, a administração do servidor pode estar lá o plug-in sob demanda em todos os sites que tem ali. Esse, porque é muita coisa assim para mim, foi muito diferente botar esse WebServe na aplicação, porque ele tem um plug-in não só para, a gente está falando de Wordpress, mas não só para Wordpress, para Magento, para Drupal, para Dilma. Ele tem o plug-in para cada um desses. Aonde o plug-in conversa diretamente com o WebServe. E aí faz toda a diferença. Via plug-in você pode falar como o cache vai se comportar. A aplicação está conversando com o cache que está lá no servidor Web, um cache geral, porque existe o cache público, que é aquele cache geral, e existe o cache privado ainda, que é um cache como se fosse a sua sessão, quando você está logado. E mediante esse plug-in, até quando abriu um parêntese aqui, eu nunca tive a pretensão de vir palestrar nesse evento. Foi muito sem querer. Eu tive a pretensão, sim, de colaborar, de ajudar, de credenciamento, porque quando eu trabalho a tempo com o Wordpress, eu falei assim, até na hora de eu devolver alguma coisa para a galera. E eu vi a chamadinha ali, num painel, num site que eu estava, eu falei, vou me cadastrar. Me cadastrei 15 minutos depois do Donin e me retorno. E eu trabalhei com o Donin há muito tempo. Eu falei assim, Donin, estou a organização, eu nem sabia que ele era o organizador dele. Eu falei, ah, cara, ele falou, ah, Mauricim. Eu falei, Mauricim. Que legal, tá. Aí a gente marcou o café, se atualizamos, que está trabalhando o que? Eu é aqui, eu é lá. E acabou que eu mandei, conversei sobre o Lightspeed, ele me perguntou, fez algumas perguntas técnicas de... E esse negócio aí de cache, eu tive um problema sério. Eu falei assim, ah, nunca tive problema de cache. E aí, rapaz, com muito tempo eu vou. Pensei que ia ser mais rápido. E aí, eu cheguei e falei para ele, cara, por causa do plugin, conversando direto com o Web Service, com o Web Server, ele agiliza muito os negócios. Na hora que qualquer um faz um post dentro do Wordpress, ele automaticamente já identifica qual as páginas afetadas e já renova aquele cache para aquelas páginas. Inclusive, isso pode ser configurado dentro do plugin. Então, assim, você configurou uma vez o plugin, não te preocupa, sai postando lá que o cache vai se atualizar automático e ele vai dar miss no primeiro ali. Vocês sabem verificar o cache? No site? Quem não sabe verificar um cache no site? Vou levantar o mão aí, só para lutar a ideia. É muito simples, você vai ali no Chrome, dá um F12 e aí dá um Ctrl F5. Aí, quando ele carregar, aí você vai na aba Network. Se eu for muito técnico aqui, depois eu abro o meu computador ali ensino vocês, porque cada estrutura aqui não vai rolar. Eu estou com medo de mexer nisso aqui. Isso que é muita modernidade para mim. Eu vou falar e depois vocês me alugam ali, não tem problema. Aí ele vai listar todos os arquivos do site que ele baixou. Aí você vai lá no primeiro que é o HTML e dá uma olhada ali nos cabeçalha HTTP e nesse cabeçalha ele vai estar lá, uma tagzinha lá de cache e tal. E nessa tagzinha ele vai estar hit, é que ele veio do cache. Miss é que ele não veio do cache. Ele gerou aqui em tempo de requisição. Então, depois que isso aí, depois que ele gera o hit lá, é só alegria. Aqui tem algumas benchmarks do próprio site da Lightspeed com plug-in de cache, ali o W3TC mais a paixa e só a paixa, ali com outro plug-in de cache. Aqui nós temos um benchmark com alguns, essas três da direita, 10 users e 100 users ali, essas três da direita, azul, amarela e azul, são um dos Lightspeed, porque o Lightspeed pode ser usado com outros plug-in de cache, diferente, o W3TC, o WP Rocket e o LS Cache, que é o azulzinho, que é o que mais deu lá em cima. O Keep it Alive, o iralto Keep it Alive, é quando não tem, na mesma conexão, ele faz várias requisições. E tem também, opa, opa, na mesma requisição e ultrapassa 5.000 transações por segundo, usando o LS Cache. Então, é bem poderoso. Aqui dentro do WHM, o panelzinho de configuração, tem uma linha, a segunda linha de ícones, que são essas aqui, vou ter um pouquinho maior para a gente poder ver. É aqui que a gente consegue gerenciar o plug-in dentro dos sites. Quando clica em Manage Cache Installations, nesse primeiro aqui, aí ele lista todos os sites, eu acho que estão habilitados com o plug-in, e se eu quiser habilitar ele na hora, é só clicar em Nebo. Se o plug-in já tem, se o site já tem plug-in de cache, ele flega, precisa tratar esse site aqui, porque ele não faz forçadamente. Aí tem que avisar a pessoa do site, ou se o site é ter o tiro plug-in do cache e habilita ali. E vamos à prática, faltando um minuto, complicado. Quem quiser baixar pode baixar. A prática vai ficar para depois. E vamos liberar as perguntas. Alguma pergunta? Manda, o microfone lá. Dá para usar o Quick se eu for usar em alguma aplicação com C Sharp, sei lá, que não vai ser a paixa rodando. C Sharp, como assim? Consumindo? É o IES da vida e usar o Quick de protocolo? Não, porque o IES não tem implementado. Quando o IES estiver, você pode usar. O Lightspeed é a mesma coisa que o IES, é a mesma coisa que o Apache, que é a NJX, entendeu? Então, só quem implementou o Quick, é o Lightspeed e o tal do outro lado, que eu não sei o nome direito. Sei lá, eu gosto desse sim, louco. São só dois web servers. E o Lightspeed tem suporte para C Sharp? Para linguagem? Não. Eu sou desenvolvedor dotnet, mas o Lightspeed não é para dotnet. É porque, como eu falei, seis anos atrás, para sites eu elegia a plataforma WordPress para eu construir sites. Eu não ia construir sites em dotnet, entendeu? Com relação à conexão UDP, eu estou falando sobre o protocolo Quick, e pelo que eu entendi, a garantia de dados, de coerência dos dados, é feita todo no lado do navegador. Porque o TCP lhe garante que todos os pacotes cheguem. O Dp não tem mais essa checagem, o protocolo não fornece mais essa garantia. Aí agora está sendo feito do lado do cliente. É porque ele é sobre SSL. Então, ele tem que chegar lá e tem que decryptar. Não importa muito se é sobre SSL ou não, mas é que ele é determinado, ele determina se a sequência de pacotes chegou, quem determina isso é do lado do browser, correto? É o browser que faz essa verificação se está certo, se não está certo, se chegou todos os pacotes ou não. Teóricamente sim. E na sua experiência, se chegou a ver se, do lado do cliente, aumenta muito o consumo do browser para fazer todas essas verificações, porque o protocolo, o TCP, praticamente, faz toda essa parte do lado de SSL, mesmo, nesses calls. E aí, eu não tenho a mínima ideia de como funciona essa parte no lado do browser. Eu também não tenho a mínima ideia, entendeu? Ah, entendi. Porque é algo novo, por exemplo, para mim, e é algo quase transparente para nós. Tipo assim, habilitou o quick, tem que habilitar o quick no light speed, o negócio passa a funcionar ali de uma forma... Da forma que eu consegui entender, interpretar o protocolo, ele funciona, ele simplesmente tirou do lado da camada de SSL, da pilha TCP, jogou para o DP, e quem está gerenciando isso é o browser. Tanto é que hoje só tem dois browsers que são compatíveis. Eu não cheguei a pesquisar essa tua pergunta da conferência. Eu acreditei que... ele confere. Entendeu? Quem quiser, depois... eu abro minha máquina e mostro as paradas acontecendo. A minha pergunta é muito parecida com o colega. Pois não. Mas ele já exponou sobre o DP, mais ou menos o que eu pensava. Eu queria saber se existe uma diferença entre o protocolo quick e o DP, porque me parece que são bem parecidos. O quick roda em cima de o DP. Ele é um protocolo de transporte. Tudo bom, velho? De fazer uma pergunta. Você escolheu ele, como observer, com base nos seus testes que você fez? Eu escolhi ele porque no passado eu tive um problema de desempenho em um site que tinha um portal de notícias, e quando publicava algumas notícias cabrosas, na fanpage, tinha poucos mil seguidores, o portal fazia isso. E aí, Mami, o Lightspeed resolveu a minha vida. Mas quando aconteceu isso, o que você usava? A parte com... Não usava... Usava Ndinex, e só que não tinha um cache. Não usava Vernish? Não usava Vernish. Então você não chegou a fazer teste com Ndinex e Vernish? Não. Eu só fui para ele porque eu cheguei a fazer esse tipo de testes. Então, assim, eu tenho um cliente que tem 30 mil visitas diárias únicas. Diária, né? Eu tive 4 mil visitas instantâneas. No final do ano passado. Usando o Lightspeed. Aham. Vou ser frango contigo. Nas primeiras vezes, caía. Porque eu estava mal configurado. Entendeu? Então a parte boa da licença é essa. Estava mal configurado. Ah, aqui, aqui, aqui. Pum. Entendeu? Era uma coisa boba. Ele tem um limite de conexões. Eu aumentei o limite e fui lá para cima. Não, tranquilo, parte da configuração. Mas o ponto que eu queria chegar é se você tinha feito um teste anterior com a Ndinex e o Vernish. Não, eu não fiz. Eu não fiz porque foi um amigo que me indicou. Porque o processamento estava muito alto. E por ele trabalhar com o sequestro, ele joga o processamento da máquina lá embaixo. O Lightspeed e joga o Lightpeed. E aí eu já usei. Ele botou o trial lá. Eu já me apaixonei. E comprei uma licença. Tá. O que me preocupa é a questão do Quick. O Quick, tu disse que ele só vai rodar sobre a gata TPS. Só que nos testes que eu fiz de benchmark, eu perdi muito tempo. Pela questão de a gata TPS. Sem a gata TPS, ele toca direto. Não tem estresse nenhum. Mas com a gata TPS, o cara já percebia que eu tenho muita perda. E aí o Ndinex e o Vernish, em mais um, observando na frente, passando só a requisição, a gata TPS, está tendo uma certa performance superior ao Lightspeed. Entendeu? Então eu queria ver se tu... Talvez, habilitando o Quick, ele melhora para ti. É, eu não conheci. Eu vou ter que fazer esse teste. Tu já fiz esse teste? Não. Eu só habilitei o Quick e está funcionando, beleza. Não é, porque como eu já tive esse problema, eu queria saber se tu... O teste de... Geralmente, esse cliente que eu tinha, ele não é mais cliente meu, optou não trabalhar mais com a gente. Beleza? Hoje, os testes que eu faço, que são os sites mais tranquilos, de acesso, eu vejo mais o tempo da resposta do primeiro byte. O TTFB, o Time Transfer First byte, que é quase o tempo de latência do site. Tu está usando o Quick em todos eles, no caso? É, o Abilitus... Eu uso o Lightspeed Encrypt, e aí eu boto o SSL em todo mundo e automát... Abilitei o Quick no servidor Lightspeed e automaticamente ele vai... quem o browser que vai, vai, o browser que não tem, não vai, vai via HTTP2. Beleza. Acho que complementando também a discussão anterior ali, eu tenho um site que eu fiz um teste, quando eu entrei em contato com Maurício. Eu peguei um site de um cliente que era... quem aqui nunca comprou um tema, e é aquele tema cheio de... um monte de chamada de JavaScript lá, um monte de função. E não é um tema que é bem otimizado. Aí eu usava esse site no Mediatempo, um servidor nos Estados Unidos lá, e, a princípio, estava o máximo de configuração depois de milhões de testes, com três total cache, optimais e outros plug-ins para otimizar o máximo. Quando entrei em contato com Maurício e ele configurou lá para mim esse servidor, esse site aí ficou... no primeiro acesso, antes de buscar do cache, já foi mais rápido. Mesmo o outro já com o cache, e ambos com o HTTPS. E depois que ele... na segunda requisição, depois que ele pega do cache, assim, fica em torno de 70% mais rápido para carregar. O outro já, assim, é um site em UCommerce, na página de listagem de produtos lá, era uma quantidade grande de produtos, carregava assim... terminava de carregar em torno de cinco segundos. Depois, com Lightspeed, a experiência pessoal não sou desenvolvedor ao ponto de entender o que acontece debaixo dos planos, mas na prática, ali pelo console, ali pelo network, checando, dava em torno de dois segundos no máximo, assim, para terminar de carregar 100% da página. Total, né? Em alguns casos... Primeiro byte é quase o tempo de latência. É, é muito rápido, assim. Bom, mas agora a minha pergunta é sobre a parte de segurança. Eu sempre utilizei plug-ins de segurança, o WorldFence e outros, para o site. Com o Lightspeed, parece que tem uma camada ali, antes de... em protocolo, existe uma segurança mais, mas nada muda na aplicação, entendeu? Ainda é necessário continuar usando esses plug-ins. Porque são coisas... é aplicação, né? É aplicação. Então, se eu estou errado, alguém me corrige aqui. O nosso amigo lá, a segurança da aplicação tem que ter. A segurança do servidor, aí é a responsabilidade do servidor, mas da aplicação tem que... Se a tua aplicação está com falha, o servidor está fechadinho, mas a sua aplicação vai entrar de qualquer jeito. Quanto custa em média uma licença vitalícia, para ter uma noção, assim, de custo? Ah, vitalícia? Acho que... A licença são 4... 4 ou 5 níveis de licença. Aí começa com a mais baratinha, vou falar que eu sei que é $14 por mês. Aí depois vai aumentando, aí eu sei que a última ali é $46 ou $90 e poucos, mas aí é para uma porrada, assim. Eu uso de $46, que é de dois cores. E tudo limitado, memória, tráfego, tudo limitado. Mas esses dois cores, não quer dizer que a máquina tem que ter dois cores. A licença de dois cores é para uma máquina com no mínimo 16 cores, entendeu? A vitalícia, cara, acho que é uns 400 porrada, uns 700 dólares, mas é uma vez só, né? E aí você pode mudar de servidor, é muito fácil. Você muda de licença, tira daqui, bota lá, é bem barbada. Mas no site da Lightspeed, é bem fácil de achar ali, vai lá no prai, isso ali... Beleza? Obrigado.