Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Optimização QlikView

Boa Tarde Pessoal,


Estou com algumas dúvidas referente ao servidor do QlikView onde precisava de algumas dicas para verificar qual a melhor tomada de decisão neste caso.

Tenho uma aplicação que hoje está com 35gb aproximadamente, a ideia é refazer esta aplicação, porém, tenho visto que o tamanho final do dashboard se deve ao tamanho de arquivos qvds que são armazenados de histórico, supondo que cada mês tem em torno de 2gb o arquivo qvd, gostaria de saber se existe alguma forma de diminuir este qvd ou até mesmo de fazer com que o dashboard não carregue o qvd e faça uma consulta de forma diferente a estes dados históricos.

Outra ideia também, seria separar o servidor hoje todas as aplicações estão em uma mesmo servidor, já li algumas pessoas informando de separar o publisher do server, alguém tem alguma documentação de qual a melhor forma de se fazer isso?

Fico no aguardo.

Att.

Maurício Rodrigues

Labels (2)
1 Solution

Accepted Solutions
afurtado
Partner Ambassador/MVP
Partner Ambassador/MVP

Mauricio,

Com certeza a separação do Server e do Publisher é uma coisa boa e recomendada (conforme ultima linha da imagem)

2017-08-07 18_37_11-Apresentacao Completo.pptx - PowerPoint.png

Em relação do tamanho do modelo, o que pode ser feito seria ter um aplicativo com o dashboard com os dados sumarizados. E, através do document chaining chamar outro com os detalhes.  Como parte da memoria é aumentada pelo cache dos usuários, se por exemplo 100 usuários acessarem o modelo somente com o dashboard e estes dados forem sumarizados (o que reduz enormemente o consumo de RAM) e destes 100 usuários, vamos supor que 50 acessem os dados detalhados, estamos reduzindo o consumo de RAM deste modelo, pois para cada usuário existe um incremento de RAM (para os state vetor) da ordem de 2% a 5% (sendo que alguns usam 10%). Neste caso estamos reduzindo em 50 usuários este consumo (pois foram os que não abriram o modelo com os detalhes e ficaram no modelo com o dashboard).

São ideias....

Outra coisa. O Qlik é colunar, portanto os dados únicos fazem muita diferença. Eliminar campos que não usa, usar o autonumber nas chaves,e floor() em datas para eliminar o datetime (quando não precisa), usar as conditional nos cálculos entre outras coisas que podem ser feitas para agilizar performance e consumo de RAM, como por exemplo o próprio modelo, que pode ser salvo com ou sem compressão e veja a diferença em um ambiente que testei...(ele pode mudar de server para server.....).

2017-08-07 18_53_20-Apresentacao Completo.pptx - PowerPoint.png

Esta ai um assunto bom para discutir......

furtado@farolbi.com.br

View solution in original post

5 Replies
Marcio_Campestrini
Specialist
Specialist

Bom dia Maurício

Acho que a primeira decisão é relacionada à "profundidade" dos dados que você deseja analisar. Quanto mais detalhe, maior o volume de dados. Se não for necessário o detalhamento final (nota fiscal, número do pedido, etc.), agrupe as informações em nível superior.

Outra coisa: limpe os campos que não são utilizados na aplicação. A aplicação QV Document Analyser do rwunderlich‌ vai te ajudar com isso.

Sobre a separação não posso te ajudar. Tenho o servidor SBR e não tenho Publisher separado.

Espero ter ajudado.

Márcio Rodrigo Campestrini
afurtado
Partner Ambassador/MVP
Partner Ambassador/MVP

Mauricio,

Com certeza a separação do Server e do Publisher é uma coisa boa e recomendada (conforme ultima linha da imagem)

2017-08-07 18_37_11-Apresentacao Completo.pptx - PowerPoint.png

Em relação do tamanho do modelo, o que pode ser feito seria ter um aplicativo com o dashboard com os dados sumarizados. E, através do document chaining chamar outro com os detalhes.  Como parte da memoria é aumentada pelo cache dos usuários, se por exemplo 100 usuários acessarem o modelo somente com o dashboard e estes dados forem sumarizados (o que reduz enormemente o consumo de RAM) e destes 100 usuários, vamos supor que 50 acessem os dados detalhados, estamos reduzindo o consumo de RAM deste modelo, pois para cada usuário existe um incremento de RAM (para os state vetor) da ordem de 2% a 5% (sendo que alguns usam 10%). Neste caso estamos reduzindo em 50 usuários este consumo (pois foram os que não abriram o modelo com os detalhes e ficaram no modelo com o dashboard).

São ideias....

Outra coisa. O Qlik é colunar, portanto os dados únicos fazem muita diferença. Eliminar campos que não usa, usar o autonumber nas chaves,e floor() em datas para eliminar o datetime (quando não precisa), usar as conditional nos cálculos entre outras coisas que podem ser feitas para agilizar performance e consumo de RAM, como por exemplo o próprio modelo, que pode ser salvo com ou sem compressão e veja a diferença em um ambiente que testei...(ele pode mudar de server para server.....).

2017-08-07 18_53_20-Apresentacao Completo.pptx - PowerPoint.png

Esta ai um assunto bom para discutir......

furtado@farolbi.com.br
Not applicable
Author

Bom dia Alessandro,

Informações bastante interessantes essas que você me passou. A minha dúvida ficou com relação a compressão, onde faço essa mudança? Porque não estou encontrando esta opção para realizar teste e verificar se consigo melhor performance.

Com relação ao Publisher e Server, hoje meu cenário é um servidor com 8 processadores com 105gb de memória, você recomendaria dividir este servidor colocando por exemplo 60gb de memória no server e o restante no publisher?

Outra coisa com o document chaining, eu conseguiria por exemplo, fazer uma aplicação com os dados de 2015, outra com as de 2016 e outra com 2017, daria uma desafogada, porque eu so usaria os dados de quando eu precisasse mesmo que eu viesse a fazer comparação de 2015 e 2016 não sobrecarregaria tanto o server.


Eu só nunca usei este recurso, mas pelo que você falou talvez tivesse um ganho relativamente alto com isso.

Fico no aguardo.

Att.

Maurício Rodrigues

afurtado
Partner Ambassador/MVP
Partner Ambassador/MVP

Mauricio,

a opção de compressão esta no modelo.  De um CTRL ALT D e na aba Geral estará a opção de salvar com compressão ou não.  Mas lembrar que com compressão ou não, na memoria ira ocupar a mesma qtde de RAM. Isto somente para salvar o QVW.  Mas neste caso, imagina uma rotina dando cargas, este tempo pode ser impactante (abrir e salvar).

Sobre tamanho dos servers, eu estou meio sem tempo de procurar, mas lembro que tenho um documento que fala de uma regra de ouro nestes casos,e se não me falhar a memoria, seria o Publisher ter 50% do Server, mas não tenho a certeza. Teria que procurar. Mas se você tem VMs, fica mais fácil.....

Sobre o Chainig, é passado as suas seleções para outro modelo, então este modelo teria os anos que deveria ter. Sobre ir para um ou outro modelo com mais anos, tem alem do chaining opção de opp on demand e o direct discovery.......mas tudo tem pros e contras.

Se os anos passados forem eventualmente vistos, eu deixaria eles como uma demanda do usuário para TI, mas depende de cada caso. As vezes poderia ter um modelo FULL que somente consumiria RAM se fosse aberto....e somente seria se o usuário quisesse fazer comparativos.....mesmo que num modelo grande e lento......

Tudo depende.......Para cada caso podemos ter uma verdade....

2017-08-08 13_44_42-Big_Data_Solutions.pdf - Foxit Reader.png

furtado@farolbi.com.br
Not applicable
Author

Bom dia,

Segui algumas ideias passadas pelo Alessandro referente a servidor e também estou refazendo a aplicação mudando alguns pontos que estão aumentando o consumo de memória.

Agradeço a contribuição e as dicas.

Att.

Maurício Rodrigues