Arquivo da tag: Ferramentas

Padrão

Publicado por

Postado no

20/11/2013

Publicado em

ASP.NET

comentários

1 comentário

aspnet_intern.exe

É comum termos aplicações ASP.NET que fazem uso de uma mesma DLL, como por exemplo, NHibernate, log4Net, etc., e além destas, há também aplicações que consomem uma DLL que é criada para uso exclusivo, para uma empresa reutilizar alguns recursos em diversas de suas aplicações.

Quando há diversas aplicações que consomem a mesma DLL, ela deve estar fisicamente em todos os diretórios (bin) de suas respectivas aplicações, obrigando o sistema operacional a ler, carregar e manter separadamente cada uma dessas DLLs, ocupando memória RAM desnecessária, afinal, trata-se exatamente da mesma DLL para todas as aplicações.

O utilitário, tema deste post, tem a finalidade de diminuir a quantidade de RAM que é utilizada, centralizando as DLLs que são consumidas por várias aplicações em um local, e uma vez que ela está carregada, todas as aplicações fazem uso dela, sem a necessidade de cada aplicação fazer o mesmo (carregamento) para si, mantendo em memória uma única DLL. Fisicamente falando, esta DLL também deverá estar separada dos diretórios virtuais das aplicações, ou seja, cada site ainda manterá a sua própria cópia da DLL localmente (diretório bin), mas ao rodar o utilitário, vamos copiar estas DLLs que são candidatas à serem compartilhadas para um outro diretório a nossa escolha.

aspnet_intern.exe
-mode exec
-sourcedir “C:WindowsMicrosoft.NETFramework64v4.0.30319Temporary ASP.NET Files”
-interndir C:Common

Local: C:Program Files(86)Microsoft SDKsWindowsv8.1AbinNETFX 4.5.1 Tools

Ao rodar este utilitário ele sai em busca de DLLs que estão sendo utilizadas por, no mínimo, três aplicações e separa todas elas no diretório especificado no atributo -interndir. Mas é importante dizer que esse número mínimo pode ser configurado através do atributo -minrefcount. Ao rodar esse utilitário ele faz uma varredura, sugere e/ou adiciona as DLLs no diretório compartilhado, e inclui nas aplicações (dentro do diretório Temporary ASP.NET Files) o link para esta DLL, agora, compartilhada.

É importante dizer que na medida em que novas aplicações vão sendo instaladas neste servidor, pode ser com que elas façam uso das mesmas DLLs já compartilhadas ou trazerem novas DLLs, mas não farão uso daquelas que já estão compartilhadas. Para evitar isso e garantir a reutilização, basta rodar este utilitário periodicamente ou, no mínimo, quando novas aplicações forem instaladas no servidor web.

Publicidade
Padrão

Publicado por

Postado no

03/10/2011

Publicado em

WCF

comentários

Deixe um comentário

WCF Web API Test Client

Uma das ferramentas que a Microsoft criou para facilitar o teste de serviços WCF baseados em SOAP foi o WCF Test Client. Este utilitário permite consumir serviços simples através de alguns protocolos, sem a necessidade de ter que escrever uma aplicação cliente para apenas testá-lo.

Já para testar serviços baseandos em REST, esse utilitário não ajuda. Podemos recorrer ao navegador. Mas ele também não vai ajudar. Não é possível testar métodos POST diretamente, ele não consegue interpretar o formato JSON, não é possível customizar headers, etc. Por conta de todas essas “limitações”, precisamos de uma ferramenta extra para nos auxiliar nos testes destes tipos de serviços. Isso nos leva a instalar uma aplicação de terceiros, como por exemplo, o Fiddler.

Apesar do Fiddler ajudar imensamente, ainda é um pouco complicado, pois precisamos descobrir quais são as URIs e seus respectivos métodos HTTP que foram disponibilizados pelo serviço. Para facilitar os testes, a Microsoft incorporou na WCF Web API uma ferramenta, escrita em jQuery, para que possamos testar os serviços tão logo quando eles forem criados, já listando os endereços disponíveis e com uma interface acessível no navegador que conduz facilmente os testes. Esta ferramenta é chamada de WCF Web API Test Client.

Por padrão, esse recurso está desabilitado. Para habilitá-lo precisamos customizar as configurações do serviço, utilizando a classe HttpConfiguration. Essa classe expõe uma propriedade boleana chamada EnableTestClient. O código abaixo ilustra como efetuar a configuração no arquivo Global.asax:

RouteTable.Routes.MapServiceRoute<ServicoDeUsuarios>
    (“usuarios”, new HttpConfiguration() { EnableTestClient = true });

Ao definir esta propriedade como True, podemos acrescentar o sufixo “/test” na endereço do serviço, e a interface qual foi mencionada acima é exibida no navegador, e dali em diante, podemos utilizá-la para efetuar os testes. As imagens abaixo exibem alguns dos testes que foram capturados em um exemplo simples, que posta informações e também captura os dados que foram inseridos.

 

 

Padrão

Publicado por

Postado no

10/08/2011

Publicado em

WCF

comentários

Deixe um comentário

Utilizando o utilitário netstat

Quando hospedamos mais que um serviço em uma mesma máquina, pode ser difícil gerenciar, e de uma forma simples, visualizar o que está ativo e aceitando requisições. Se não temos o luxo de utilizar algum sistema de gerenciamento mais eficiente, como é o caso do AppFabric, podemos recorrer à um utilitário de linha de comando que existe no sistema operacional chamado netstat.

Este popular utilitário exibe uma lista com as conexões de rede estabelecidas no computador onde o mesmo está sendo executado. Se tivermos serviços WCF hospedados em uma determinada máquina, é possível visualizá-las através deste utilitário, e no mínimo, enxergar em qual porta eles encontram, se ela (porta) está aberta ou não e seu status. Abaixo temos um código de teste, que cria e abre vários hosts dentro de uma aplicação Console.

static void Main(string[] args)
{
    ServiceHost[] hosts = new ServiceHost[10];

    for (int i = 0; i < 10; i++)
    {
        var host = 
            new ServiceHost(typeof(Servico), 
                new Uri(string.Format(“http://localhost:987{0}”, i)));

        host.AddServiceEndpoint(typeof(IContrato), new BasicHttpBinding(), “srv”);
        host.Open();
        hosts[i] = host;
    }

    Console.ReadLine();
}

Ao rodar esta aplicação, dez hosts são criados e abertos. Ao executar o utilitário netstat, essas conexões já são listadas, assim como podemos perceber na imagem abaixo: