Dicas Técnicas BufaloInfo

Visual Basic : Otimizando aplicações ASP.NET : Worker Threads

O arquivo web.config nos permite ajustar diversas configurações de execução do ASP.NET, nos permitindo otimizar ao máximo sua execução. Vale citar ainda que no IIS 7 (Vista/Windows Server 2008) toda a configuração do IIS é feita pelos arquivos .config

Uma das configurações que podemos controlar são as worker threads. Cada worker thread, basicamente uma thread do sistema operacional, é responsável por receber uma requisição de um client e processar. Se o número de worker threads for muito inferior ao número de requisições *simultaneas* dos clients, os clients começam a ser enfileirados e você tem um problema de performance.

O número de worker threads que você aplicar vale para cada processo de execução do site e poderão haver mais de um no caso de multiplos cores ou processadores na máquina.

Como decidir se o número está bom ou não ?

Pode-se utilizar o system monitor para analisar contadores de performance como por exemplo "solicitações enfileiradas", permitindo saber se é ou não necessário aumentar o número de worker threads.

Além disso, observe que se sua aplicação usa pouco o processador e muito a comunicação, leitura, resposta, etc, um número maior de worker threads é possível. Se sua aplicação usa muito o processador, um número grande de worker threads pode engargalar o servidor.

Para ter uma noção da importância ou não desta configuração para o seu site, pegue o número de visitas mensais ao site e divida pelo número de minutos existente em 1 mês. O resultado fornece um número levemente aproximado das visitas simultâneas que seu site possui.

Enfim, para configurar o número total de worker threads insira no web.config :

<processModel maxWorkerThreads="100" />

Visual Basic : Utilizando o profile no Global.asax

Um ótimo local para inicializar dados do Profile do ASP.NET seria o session_start no Global.asax, ou seja, a sessão do usuário começa e de imediato ajustamos o seu profile.

Porém existe um problema nisso : O objeto Profile não encontra-se disponível durante o session_onstart. Na sequencia de eventos no servidor, o objeto Profile é criado apenas bem depois, *durante* o evento acquireRequestState.

Por isso o primeiro evento seguro para fazermos uso do profile é o PostAcquireRequestState.

Porém este evento ocorre em todos os postBacks e não apenas no start da sessão. Por isso para que a configuração de profile ocorra apenas no start da sessão precisaremos definir um flag (uma variável boolean) no session_onstart e testa-la no postAcquireRequestState.

Visual Basic : Controlando o timeout

O banco de dados (SQL Server) por default não define um tempo de timeout, ou seja, uma instrução poderia esperar indefinidamente para que seja executada e é isso que acontece se for utilizado o query analyser do sql server.

Mas quando fazemos a execução via aplicação, se a instrução demora muito a ser executada ocorre um timeout. Por que ?

Porque o OLEDB, como intermediário na comunicação entre aplicação e banco, possui um timeout definido e aborta a execução se esse timeout for atingido.

Para alterarmos o timeout do oledb devemos definir o valor da propriedade commandtimeout, que existe tanto em objetos command como no objeto connection. Se o valor desta propriedade for definido como 0, o timeout fica infinito.

Visual Basic : Criar uma string de conexão pela janela de conexão OLEDB - VB 6

Vimos esta dica anteriormente para o VB.NET, mas também é possível realizar isso em VB 6 sem dificuldade, afinal, a biblioteca que permite a abertura do diálogo de conexão OLEDB é uma biblioteca COM, perfeitamente acessível pelo VB 6.

No caso do VB 6 marcamos references para a biblioteca OLEDB Service Component 1.0 Type Library. Essa biblioteca nem sempre aparece no references, portanto se não estiver lá precisaremos utilizar o browse e localiza-la no seguinte caminho : program files\common files\system\ole db\oledb32.dll

Veja como fica o código :

Dim dataLink As New MSDASC.DataLinks
Dim connString As String
Dim cn As New ADODB.Connection

' abaixo fazemos um vínculo da janela oledb com o formulário atual
dataLink.hWnd = Me.hWnd

' Exibimos o diálogo no promptnew
On Error Resume Next
connString = dataLink.PromptNew
If Err = 0 Then
' Utilizamos a connection string obtida em um objeto de conexão
cn.ConnectionString = connString
Else
' Usuário cancelou a operação
End If

'No exemplo abaixo, outra forma de abrir a janela, utiliza-se o método
' promptEdit, ao invés de promptnew, para editar a string de conexão de um
' objeto de conexão existente
If dataLink.PromptEdit(cn) Then
MsgBox cn.ConnectionString
Else
MsgBox "Cancelou"
End If

Visual Basic : Simplificar o registro de DLLs no S.O.

Quando trabalhamos com a criação de componentes COM a necessidade de registrar e desregistrar DLLs é muito frequente. Para registrar ou desregistrar DLLs utilizamos o regsvr32 com ou sem a opção /U .

Mas como essa necessidade é muito frequente, podemos utilizar um truque de registry para simplificar o registro da DLL :

Em primeiro lugar devemos encontrar uma key chamada dllfile dentro da key HKEY_CLASSES_ROOT. dllfile representa os arquivos dll.

Abre-se essa key e, caso já não exista, devemos criar uma sub-key chamada shell.

Abaixo da sub-key shell criamos sub-keys com nomes de instruções que aparecerão ao clicarmos com o botão direito sobre este arquivo. Por exemplo, podemos criar, abaixo de shell, as keys "Registrar" e "Desregistrar".

Abaixo de cada uma das últimas keys criadas devemos criar a key "Command".

Dentro da key command, no lado direito do registry, devemos utilizar um duplo clique para editar o valor default. Para registrar digitamos "Regsvr32 %1" (sem as aspas) enquanto que para desregistrar digitamos "Regsvr32 %1 /u"

Voltando à key shell, podemos alterar seu valor default para o nome de uma de suas sub-keys, determinando assim qual será a instrução default.

Ao clicarmos com o botão direito sobre um arquivo DLL veremos ambas as instruções criadas. Se utilizarmos duplo clique a instrução default será executada.

A chave shell pode ser posteriormente exportada para um arquivo .REG, sendo assim basta dar um duplo clique no arquivo .REG e as novas entradas de registry são implantadas

Visual Basic : Alguns mistérios da compatibilidade binária

A compatibilidade binária, necessária no momento da recompilação de componentes em especial em um sistema no qual existam muitos componentes utilizando outros componentes, pode ser um grande problema de gerenciamento.

Garantir que todos os programadores a utilizem e nunca haja uma quebra de compatibilidade ou, se houver em um componente A, por exemplo, que os componentes que usam o componente A sejam recompilados, isso já é um problema.

Mas o mecanismo da compatibilidade binária esconde alguns mistérios a mais. Os programadores sabem que para manter a compatibilidade binária é necessário que não hajam alterações na interface. Porém o Visual Basic é muito amigável com os programadores e permite que mesmo que hajam alterações em parâmetros ou inserção de novos métodos a compatibilidade binária seja mantida. Porém isso tem um custo.

Vamos imaginar um cenário. O componente A utiliza o componente B e o componente B sempre é compilado com a compatibilidade binária. Mas compilar o componente B, que já ganhou muitos novos métodos, com compatibilidade binária tem uma consequencia que muitos programadores não conhece : O ID (GUID) da interface default do component B muda. Ele mantém o ID antigo, mas passa a ter também um novo.

Imagine nesse cenário que a empresa possui um ambiente de desenvolvimento e um para homologação e que no momento os componentes estão funcionando em ambos os ambientes. Se o componente B é recompilado e reinserido no ambiente de homologação ele ganha um novo ID de interface, mas mantém o antigo. Assim sendo, o componente A que encontra-se no ambiente de homologação e que só conhece o ID de interface antigo ainda consegue acessa-lo, porém se o componente A em desenvolvimento for recompilado, seu novo executável (dll) passará a utilizar o novo ID de interface do componente B.

Imaginemos que mais uma vez o componente B foi atualizado em desenvolvimento, mas não foi passado para homologação. O componente A também foi atualizado em desenvolvimento, recompilado, e resolveu-se passa-lo para homologação.
Resultado : Por ter sido recompilado, o componente A aponta para o ID de interface do componente B mais atualizado. Porém ao ser inserido no ambiente de homologação o componente A encontrará um componente B que não possui essa interface. Consequentemente teremos uma falha no relacionamento entre o componente A e o componente B.

Resumindo : Se o componente A for compilado fazendo references para uma versão mais antiga do componente B, ele pode ser perfeitamente utilizado com a versão mais nova, pois esta guarda o ID de interface antigo. Mas se o componente A for compilado com uma versão mais nova do componente B, mesmo que não utilize nenhum recurso novo ele não pode ser utilizado com uma versão mais antiga, pois guardou o ID da nova interface. E tudo isso acontece mesmo com a compatibilidade binária estando sempre marcada.

Visual Basic : Registrando um componente via código - forma alternativa

Na dica 74 (http://www.bufaloinfo.com.br/dicas.asp?cod=74) já haviamos visto como utilizar APIs para registrar um componente via código.

Mas existe uma forma alternativa de fazer esse registro. Podemos utilizar uma biblioteca COM chamada Type Library Information (deve ser marcada no references para utilizarmos early binding) para manipular a type library de um componente e isso inclui registra-lo e desregistra-lo. Veja :

Private Sub Form_Load()

Dim x As New TLI.TLIApplication
Dim y As TypeLibInfo

Set y = x.TypeLibInfoFromFile("C:\teste\com\prjteste.dll")

y.Register

End Sub

O método TypeLibInfoFromFile carrega a type library a partir da DLL e o método Register se encarrega de registrar o componente na máquina. Desregistrar o componente também é muito simples, veja :

Private Sub Form_Load()

Dim x As New TLI.TLIApplication
Dim y As TypeLibInfo

Set y = x.TypeLibInfoFromFile("C:\teste\com\prjteste.dll")

y.UnRegister

End Sub

Visual Basic : Identificando as classes existentes em uma DLL

Na dica 74 (http://www.bufaloinfo.com.br/dicas.asp?cod=74) expliquei como registrar um componente via código. Isso é muito útil para o late binding. Mas ainda fica algo pendente : Como descobrir o progID de cada classe existente no componente ?

Para resolver esse problema encontramos uma biblioteca COM chamada TypeLib Information. Podemos então fazer o references para esta biblioteca e utiliza-la para descobrir as classes contidas em uma DLL.

Considerando que temos um form com uma listbox, observe o seguinte código :

Dim x As New TLI.TLIApplication
Dim y As TypeLibInfo
Dim z As SearchResults
Dim w As SearchItem

Set y = x.TypeLibInfoFromFile("C:\Max\Exercicio08\BancosdeDados.dll")
List1.AddItem y.Name
Set z = y.GetTypes()

For Each w In z
List1.AddItem w.Name
Next

O método TypeLibInfoFromFile carrega a type library contida em uma DLL, resultando em um objeto do tipo TyhpeLibInfo. A propriedade Name que adicionamos na listbox é o nome da biblioteca, ou seja, a 1a parte do progID.

Em seguida utilizamos o método GetTypes para obter os tipos (classes) contidos dentro da type library e fazemos um for/each para inseri-los na listbox.

Visual Basic : Controlando o tempo em loops

Inicialmente poderia parecer complicado fazer com que um determinado loop rode exatamente por um determinado periodo de tempo (segundos ou algo menor que isso), mas utilizando algumas funções da API do windows podemos obter esse resultado. Veja :

#If Win32 Then
Private Declare Function GetTickCount _
Lib "kernel32" () As Long
#Else
Private Declare Function GetTickCount _
Lib "User" () As Long
#End If

Essa função, GetTickCount, nos fornece um número que funciona quase que como um timer. Utilizando uma função que nos dê a diferença entre 2 chamadas de GetTickCount chegamos ao resultado desejado. Veja a função :

Public Function TickDiff( _
ByVal TickStart As Currency, _
ByVal TickEnd As Currency) As Long

' CCur(2 ^ 32)
Const TwoToThe32nd As Currency = 4294967296@

' Handle two's complement for values larger than
' 2147483647&
If TickStart < 0 Then
TickStart = TickStart + TwoToThe32nd
End If
' Handle two's complement AND the case where
' timeGetTime/GetTickCount wraps at (2 ^ 32)ms,
' or ~49.7 days:
If (TickEnd < 0) Or (TickEnd < TickStart) Then
TickEnd = TickEnd + TwoToThe32nd
End If
' Return the result
TickDiff = TickEnd - TickStart
End Function

Agora veja como utiliza-la :

Public Sub SampleLoop()
Dim TickStart As Currency
TickStart = GetTickCount()
' Loop for 5 seconds
Do While TickDiff(TickStart, GetTickCount()) _
< 5000
' loop code here
Loop
End Sub

Primeiramente foi pego na variável TickStart o valor de GetTickCount. O loop então é feito com base no resultado da função TickDiff : Quando a diferença entre o start e o GetTickCount atual for maior que 5000 (5 segundos) o loop para.

Visual Basic : Enviando dados via POST com o INET

O componente INET do VB nos permite fazer transmissões de dados via método POST, nos permitindo realizar comunicações, troca de dados, com páginas na web mesmo que estas não tenham sido preparadas para este fim.

A transmissão POST apenas pode ser realizada através do método EXECUTE e não através do método OPENURL. Mas além disso existe um truque para que a transmissão funcione : É necessário enviar ao servidor um cabeçalho indicando o que está sendo transmitido, do contrário o servidor irá ignorar os dados.

Veja um pequeno exemplo :

Inet1.Execute "http://localhost/livro/testalogin.asp", "POST",strData, "Content-Type: application/x-www-form-urlencoded"

Lembre-se que o método execute é assincrono, ou seja, a aplicação não irá parar esperando que ele seja executado. Portanto é necessário que você recupere a resposta do servidor através do método getchunk utilizado no evento statechanged, veja :

Private Sub Inet1_StateChanged(ByVal State As Integer)
Dim vtdata As String
Dim res As String

If State = 12 Then
Do
vtdata = Inet1.GetChunk(1024, icString)
res = res & vtdata
Loop While Len(vtdata) <> 0
Debug.Print res
End If

End Sub