Programação Paralela em Arquiteturas Multi-Core_Aplicações Internet - Wikilivros

Prévia do material em texto

Programação Paralela em Arquiteturas Multi­
Core/Aplicações Internet
Origem: Wikilivros, livros abertos por um mundo aberto.
< Programação Paralela em Arquiteturas Multi­Core
Índice
1 Introdução
2 Aplicações para infra­estrutura
2.1 Banco de Dados
2.1.1 Otimização de consultas em paralelo
2.2 Protocolos paralelos
3 Aplicações distribuídas
3.1 Grid
3.1.1 Definição
3.1.2 Benefícios e Desafios
3.1.3 Conclusão
3.2 Peer­to­Peer
3.2.1 Definição
3.2.2 Arquitetura e classificação
3.2.3 Vantagens
3.2.4 Conclusão
3.3 Web Crawlers
3.3.1 Definição
3.3.2 Arquitetura de um crawler paralelo
3.3.3 Conclusão
4 Programação paralela na web
4.1 Linguagens de programação
4.1.1 Java Script
4.1.1.1 Carregando componentes em paralelo
4.1.1.2 AJAX (requisições concorrentes)
4.1.2 PHP
4.1.2.1 Principais funções
4.1.3 JAVA
5 Conclusão
6 Referências
Introdução
A Internet é um conglomerado de redes em escala mundial de milhões de computadores interligados pelo Protocolo de
Internet que permite o acesso a informações e todo tipo de transferência de dados. A Internet é a principal das novas
tecnologias de informação e comunicação (NTICs). Ao contrário do que normalmente se pensa, Internet não é sinónimo de
World Wide Web. Esta é parte daquela, sendo a World Wide Web, que utiliza hipermídia na formação básica, um dos
muitos serviços oferecidos na Internet. De acordo com dados de março de 2007, a Internet é usada por 16,9% da
população mundial[1] (http://www.internetworldstats.com/stats.htm).
Neste capítulo abordaremos sobre algumas aplicações paralelas que existem na Internet. Falaremos primeiro sobre
aplicações para a infra­estrutura da rede mundial de computadores, depois sobre aplicações distribuídas e por último sobre
algumas linguagens que permitem a construção de aplicações paralelas para a Internet.
Aplicações para infra­estrutura
Banco de Dados
Sistemas de banco de dados altamente paralelos estão começando a substituir os tradicionais mainframes para maiores
bancos de dados e tarefas de transações.
A partir da hegemonia do modelo de dados relacional, sistemas de banco de dados relacionais começaram a aparecer no
mercado. As consultas relacionais são idealmente convertidas para execução em paralelo, pois elas consistem em
operações uniformes aplicadas a conjuntos de dados uniformes. Cada operação produz uma nova relação, então as
operações podem ser decompostas em fluxos de dados altamente paralelos.
Ao utilizamos a saída de um operador na entrada de outro, os dois operadores podem trabalhar em série, o que gera um
pipeline paralelo. Podemos também particionar os dados de entrada entre vários processadores e memórias, pois uma
operação pode, com grande freqüência, ser dividida em várias operações independentes, cada um trabalhando em uma
parte dos dados. Esta divisão de dados e execução gera um paralelismo particionado.
Esta técnica requer uma comunicação entre os sistemas de bancos de dados paralelos, seja através de mensagens, seja
através de recursos compartilhados ou de outros métodos possíveis. Esses métodos se baseiam na arquitetura do sistema
de banco de dados.
Apesar do grande número de arquiteturas de sistemas de banco de dados paralelos e distribuídos, há um consenso quanto
ao uso da arquitetura sem compartilhamento. Nesses sistemas, as duplas de cada relação no banco de dados são
particionadas dentre as unidades de disco que estão ligadas diretamente a cada processador. Isso permite que vários
processadores possam buscar em grandes relações paralelamente sem precisar de dispositivos de E/S sofisticados.
Otimização de consultas em paralelo
Os otimizadores de consultas a banco de dados não consideram todos as possíveis formas de otimização em uma consulta
relacional devido a sua complexidade e, apesar dos modelos de custos para consultas relacionais executadas em um único
processador serem bem conhecidos, eles ainda dependem de estimativas de custo, que no melhor caso, adivinham.
Algoritmos paralelos para cada operação e organização das árvores de consultas podem ser usados para aumentar
significativamente o número de otimizações possíveis encontradas a cada consulta, aumentando consideravelmente a
velocidade das consultas.
Protocolos paralelos
O aumento da demanda por conteúdo multimídia, atualizações dentre outros, tornaram os servidores distribuídos cada vez
mais utilizados para suprir esta demanda, sem o congestionamento na transmissão e falha do servidor por falha em um
ponto único, que são problemas comuns de servidores centralizados. Além disso, servidores centralizados só podem
responder a um número limitado de clientes, devido ao limite de conexões.
Servidores distribuídos permitiram que recursos sejam disponibilizados em pontos de grande demanda, aliviando o
problema de congestionamento em servidores centralizados. Apesar disso, as taxas de transferências continuam as mesmas
dos servidores centralizados, pois apenas um nó no sistema distribuído realiza a transferência. Paralelismo pode melhorar a
transmissão.
O objetivo dos protocolos paralelos é provê suporte a transferências de arquivos paralelas em servidores distribuídos.
Os protocolos têm que resolver problemas como:
descobrir aonde o arquivo existe no servidor distribuído
distribuir a tarefa entre os servidores selecionados
transmitir o arquivo em seguimentos paralelos
unir o arquivo automaticamente
recuperar segmentos perdidos
Além disso, existem dois problemas básicos ao utilizar download distribuído: balanceamento de carga dinâmico e
transparência ao usuário.
Enquanto o download está ocorrendo, a carga dos servidores deve ser checada para garantir que a carga continue baixa,
senão o desempenho é reduzido. Quando um servidor ultrapassa sua capacidade, replicas são migradas para outros
servidores até o servidor carregado atinja o nível adequado de carga. Se a demanda for muito alta, uma replica é criada ao
invés de migrada e é destruída se a demanda for baixa.
Balanceamento dinâmico de carga é essencial para manter transmissões efetivas de arquivos. Apesar de manter a demanda
no máximo parecer lógico, as vezes, isto atrapalha a transmissão. Focar somente na demanda gera outros problemas na
rede como congestionamento, o que degenera o propósito dos sistemas distribuídos.
A transparência ao usuário, permite sistemas de software mudem sem alterar os sistemas ao redor, usando interfaces. A
transparência é obtida ao construir uma interface para o sistema e depois construir os sistemas ao redor baseados na
interface. Ao realizar isto, o sistema atrás da interface pode ser mudado sem afetar os sistemas em volta.
Os protocolos paralelos devem ser transparentes ao usuário e a outras aplicações, para que possam ser compatíveis com
as aplicações atuais e outros protocolos.
Aplicações distribuídas
Uma aplicação distribuída consiste de um conjunto de processos de aplicação que interagem por meio de mensagens. É
uma aplicação na qual os programas que a compõem são distribuídos entre dois ou mais computadores interconectados em
uma rede, como a Internet por exemplo.
O objetivo desta subseção é mostrar algumas aplicações distribuídas muito comuns e importantes na Internet hoje em dia,
como o Grid (Computação em Grade), as redes Peer­to­Peer e os Web Crawlers.
Grid
Definição
Organizações Virtuais acessando
diferentes e sobrepostos conjuntos de
recursos
A computação em grade (do Inglês grid computing) é um modelo computacional capaz de alcançar uma alta taxa de
processamento dividindo as tarefas entre diversas máquinas, podendo ser em rede local ou rede de longa distância, que
formam uma máquina virtual. Esses processos serão executados no momento em que as máquinas não estão sendo
utilizadas pelo usuário, evitando assim o desperdício de processamento da máquina utilizada. A metáfora adotada na
computaçãoem grade é a da rede elétrica (grid, em inglês). Isto é, o poder computacional deveria estar disponível na
Internet da mesma forma que energia elétrica está disponível na tomada: sob demanda e de maneira transparente.
Uma experiência de integração de processamento distribuído é o projeto SETI@home (http://setiathome.ssl.berkeley.edu/),
uma continuação do projeto da NASA de busca de inteligência extraterrestre. Usando um software que pode ser baixado
pela Internet, um microcomputador pode analisar sinais do rádio telescópio de Arecibo. Atualmente, existem 4 milhões de
assinantes em 224 países, criando um computador virtual com uma performance de 20 Tflops.
Um outro exemplo são as famosas redes peer­to­peer, como Emule (Edonkey), Kazaa, Gnutella, em que se compartilham
arquivos por exemplo, mas sem nenhum controle de acesso e não interoperam entre si. Com a evolução dessas aplicações
elas acabaram por inter­operar e haverá uma convergência de interesses entre computação ponto a ponto, Internet e
computação em grade.
A diferença existente entre a computação distribuída e computação em grade se dá pelo fato de que a computação
distribuída é um conceito que vem dos anos 80 e 90, e consiste na possibilidade de resolver um determinado problema
computacional através da utilização de diferentes recursos distribuídos geograficamente. A computação distribuída passa a
ser uma “Computação em Grade” no momento em que existe uma infra­estrutura física e uma infra­estrutura lógica
(software) que permita coordenar os trabalhos que vão ser processados e garantir a sua qualidade de serviço.
O surgimento das Grids Computacionais nasceu da comunidade de Processamento de Alto Desempenho (PAD). O
conceito foi apresentado pelos pesquisadores Ian Foster e Carl Kesselman, sendo composto por uma infra­estrutura de
hardware e software que permite­nos acesso a grandes capacidades computacionais geograficamente distribuídas, de
forma confiável, consistente, econômica e persistente. Na verdade o conceito é antigo, mas com uma nova dinâmica, em
que se pode utilizar a capacidade de computação (ex. Storage/CPU) sem ter que se preocupar de onde vem, como é
mantida, fazendo uma metáfora às redes elétricas.
Chamamos de Organização Virtual (VO) quando temos participantes que desejam compartilhar recursos para poder
concluir uma tarefa. Além disso, o compartilhamento esta além de apenas troca de documentos, isto pode envolver acesso
direto a software remoto, computadores, dados, sensores e outros recursos.
Grids são construídos como um grupamento de serviços básicos independentes.
Um aspecto essencial dos serviços de Grid é que esses estão disponíveis
uniformemente através dos ambientes distribuídos na Grid. Os serviços são
agrupados em um sistema integrado, também chamado de middleware.
Exemplos de ferramentas atuais de Grid incluem Globus, Legion, OpenGrid,
AppLeS.
O Grid permite também o uso de técnicas de programação paralela por
passagem de mensagens. O ambiente MPI ("Message Passing Interface") está
disponível no Grid através da versão MPICH­G2 (versão portátil do MPI para o
Globus). O padrão MPI define uma biblioteca de rotinas que implementam uma
comunicação ponto a ponto, em que a operação "send" é usada para iniciar uma
transferência de dados entre dois programas concorrentes e a operação "receive"
é usada para obter dados do sistema no espaço de memória da aplicação; existem ainda operações coletivas envolvendo
múltiplos processos. Mas que devido a alta latência provocada na comunicação entre processos, as aplicações devem ser
construídas com uma granularidade bem projetada de tal forma que se comuniquem o mínimo possível. Então, as
aplicações mais adequadas ao Grid são as que possuem tarefas independentes (bag of tasks), pois as tarefas não
dependem da execução de outras e podem ser executadas em qualquer ordem.
A Internet surgiu no início da década de 70 com o objetivo de interligar diferentes ambientes computacionais e
geograficamente dispersos. Os web sites desenvolvidos pela indústria sempre foram interoperáveis em relação usuário­site,
por meio de aplicações criadas neste contexto, em que o usuário dispõe de um menu de serviços fechados. O que ocorre
em um ambiente de Grid é o inverso, onde o usuário tem de submeter suas aplicações para serem resolvidas dentro do
ambiente por ele montado.
Um ambiente de cluster constitui em um sistema formado por hardware e software conectados em um local apenas,
servindo a usuários que estão trabalho somente em um projeto, usado exclusivamente para resolver os problemas
computacionais de uma determinada organização. Por outro lado, um Grid presta serviços de uma forma geograficamente
distribuída. Em um cluster, os recursos são gerenciados por uma entidade central, e os computadores agem como se fosse
um único dispositivo. Nas configurações em Grid, cada "organização virtual" faz o gerenciamento de seus recursos não
tendo a visão de uma imagem única do sistema. Ou seja, o usuário tem consciência dos diversos serviços disponíveis e que
deverá requisitá­los para sua utilização. Portanto, os Grids são mais heterogêneos, complexos e distribuídos.
Benefícios e Desafios
Um Grid possui muitos benefícios, entre os quais podemos citar:
Organizações podem agregar recursos ­ a computação em Grid permite que as organizações possam agregar
recursos com toda a infraestrutura dos ITs, não importando localização global. Isso elimina situações onde um site
esteja sendo executado com sua capacidade máxima, enquanto outros tenham ciclos disponíveis.
Poderosa plataforma de suporte a Organizações Virtuais ­ organizações podem melhorar dramaticamente sua
qualidade e velocidade de produtos e serviços disponibilizados, enquanto os custos de IT são reduzidos por habilitar
a colaboração transparente dos recursos compartilhados
Acesso distribuído a diversos tipos de recursos ­ permite que empresas acessem e compartilhem bases de dados de
forma remota. Isto é essencialmente benéfico para as ciências da saúde ou comunidades de pesquisa, onde volumes
grandiosos de dados são gerados e analisados durante todo dia.
Colaboração entre centro de pesquisas ­ possibilita a larga dispersão das organizações para que facilmente possam
colaborar em projetos pela criação da habilidade do compartilhamento de tudo, desde aplicações a dados, até
projetos de engenharia, etc.
Melhor utilização de largura de banda ­ pode­se criar a mais robusta e resistente infraestrutura de informações.
Aproveitamento de recursos ociosos – pode­se aproveitar os ciclos de processamento idle disponíveis dos PCs
desktops que se encontram em várias localidades pelo planeta. Por exemplo, os computadores que se encontram
tipicamente ociosos durante a noite de uma empresa em Tóquio pode ser utilizado durante o dia para operações na
América do Sul.
A computação em grade, por ser uma tecnologia ainda muito recente, possui muitos desafios operacionais e de pesquisa a
serem combatidos. Apenas para exemplificar, citamos alguns deles:
Localização dos recursos
Reserva de recursos
Capacidade para adaptar­ se a mudanças no ambiente
Criação e escalonamento das tarefas
Autonomia de cada grupo participante para definir suas próprias políticas de segurança
Recursos requisitados podem estar em diferentes localidades
Qualidade de serviço exigida por cada aplicação
Conclusão
O Grid Computing é um desafio bem maior do que formas mais simples de computação paralela e distribuída. Hoje, a
maioria dos projetos de Grid permanecem localizados nos centros de supercomputação e laboratórios universitários. Os
centros de pesquisa são ligados a conexões em rede cerca de 20 vezes mais rápidas do que as conexões de banda largas
normais, são equipadas com sistemas de armazenamento capazes de lidar com vastos arquivos de dados e com
computadores de alta performance. O Grid Computing é um conceito sobre o qual existe ainda uma grande expectativa eque poderá evoluir em diferentes direções, mas que é já hoje entendido como a próxima geração da Web para a
comunidade científica.
Peer­to­Peer
Exemplo de uma rede Peer­to­
Peer.
Exemplo de uma rede de servidor.
(Não Peer­to­Peer)
Definição
As redes Peer­to­Peer (P2P) são um modelo de comunicação em que todas as
partes possuem as mesmas capacidades e responsabilidades, podendo também
iniciar uma seção de comunicação. Difere do modelo de cliente/servidor, no qual
alguns computadores são dedicados a servirem dados a outros. Os computadores
que constituem a rede não possuem um papel fixo de cliente ou servidor, pelo
contrário, costumam ser considerados de igual nível e assumem o papel de cliente ou
de servidor dependendo da transação sendo iniciada ou recebida de um outro peer
da mesma rede.
Os nós da rede Peer­to­Peer podem diferir em termos de configuração local,
capacidade de processamento, capacidade de armazenamento, largura de banda,
entre outras características particulares. O primeiro uso da expressão Peer­to­Peer
foi em 1984, com o desenvolvimento do projeto Advanced Peer­to­Peer
Networking Architecture na IBM.
O termo é também utilizado em diferentes tecnologias que adotam o modelo
conceitual ponto­a­ponto, tais como o protocolo NNTP (para Usenet News),
SMTP (para envio de e­mails) e sistemas de trocas de mensagens instantâneas
(MSN, ICQ, GTalk).
Na Internet, Peer­to­Peer é um tipo de rede transiente que permite a um grupo de
computadores usuários com um mesmo programa conectarem e terem acesso direto
a arquivos no disco rígido um dos outros. Esses programas de compartilhamento de
arquivos, como por exemplo o w:en:Napster Napster, eMule e Kazaa, entre outros,
forma responsáveis por popularizar o termo P2P.
Há também outros tipos de recursos podem ser compartilhados em redes Peer­to­
Peer, tal como capacidade de processamento de máquinas, espaço de
armazenamento de arquivos, serviços de software (analogamente aos Web
Services), entre outros.
Arquitetura e classificação
As redes Peer­to­Peer podem ser classificadas em relação o seu uso.
Compartilhamento de arquivos
Telefonia
Streaming de midia, como áudio e vídeo
Fóruns de discussão
Outra classificação possível para as redes Peer­to­Peer é em relação ao grau de centralização delas. Algumas aplicações
são baseadas em arquiteturas cliente/servidor para algumas tarefas críticas como a indexação de informações, por exemplo.
Outras aplicações usam uma arquitetura Peer­to­Peer pura, sem nenhuma centralização de tarefas. Essa arquitetura
completamente descentralizada faz com que os usuários tenham o mínimo de contato com o servidor central, o que provém
maior escalabilidade do sistema.
As aplicações Peer­to­Peer puras são raras. Em geral é utilizada uma arquitetura híbrida, utilizando alguns elementos
centralizadores na execução de algumas tarefas cujo desempenho é crítico. As questões de desempenho são o que induzem
a uma centralização parcial das atividades em peers de maior capacidade.
Nas arquiteturas puras, os peers são iguais, fazendo os papéis de clientes e servidores. Não há um servidor central para
controlar a rede, nem um roteador central. Nas arquiteturas híbridas há um servidor central para manter informações sobre
os peers e atender a requisições pelas informações. Os peers são responsáveis por armazenar dados, deixar o servidor
central saber quais arquivos eles querem compartilhar, e disponibilizar os dados a outros peers quando eles requisitarem.
Os peers numa rede Peer­to­Peer são considerados nós na rede. Existe uma ligação entre quaisquer dois nós que se
conhecem, isto é, peers que sabem a localização do outro na rede. Baseando nisso, as redes Peer­to­Peer também podem
ser classificadas como estruturadas ou não­estruturadas.
As redes não­estruturadas são formadas quando as ligações são estabelecidas arbitrariamente. São redes que podem ser
facilmente construídas quando novos peers querem entrar na rede, já que basta que ele copie ligações existentes de outro
nó da rede e então o novo vai formando suas próprias ligações ao longo do tempo. Nessas redes, se um peer deseja um
dado é necessário fazer uma busca pela rede para achar os peers que podem disponibilizar o dado. A desvantagem dessas
redes é que nem sempre se encontraram peers para disponibilizar um dado em determinado momento. Os arquivos mais
populares são mais fáceis de se encontrar do que um arquivo raro.
Uma rede estruturada possui um consistente protocolo global para assegurar que qualquer nó possa distribuir
eficientemente um caminho a algum peer que possui o arquivo que ele busca, mesmo que seja raro. Para isto ser possível é
necessário um padrão mais estruturado de ligações.
Vantagens
Um fato importante numa rede Peer­to­Peer é que todos os clientes disponibilizam recursos, incluindo largura de banda,
espaço de armazenamento e poder computacional. Então, se chega um novo peer, a demanda no sistema aumenta, mas a
capacidade total do sistema também aumenta junto, fato que não é verdade numa estrutura cliente/servidor com um número
fixo de servidores, onde a adição de novos clientes pode significar uma transferência de dados mais lenta para todos os
clientes.
A distribuição natural nas redes Peer­to­Peer também aumenta a robustez do sistema em caso de falhas replicando os
dados entre os peers e, nas redes puras, possibilitando aos peers encontrar os dados sem passar por um servidor central.
Conclusão
O interesse nas redes Peer­to­Peer é muito grande por parte de empresas e estudos acadêmicos devido ao poder de
comunicação e distribuição de dados que elas podem oferecer. Grandes esforços são feitos para garantir a qualidade dos
dados, já que há diversas formas de ataques maliciosos nessas redes, além da qualidade da transmissão e distribuição dos
dados.
Web Crawlers
Uma outra aplicação interessante do paralelismo na internet é na construção de Web crawlers, também conhecidos como
robôs. Um crawler é um programa que coleta e armazena páginas da Internet, sendo muito utilizados em máquinas de
busca.
Definição
Um crawler geralmente começa a funcionar a partir de um conjunto inicial de URLs,  , armazenadas numa fila. Partindo
do conjunto inicial, o crawler pega alguma URL, em alguma ordem pré­definida, coleta a página, extrai novas URLs
encontradas a partir da página coletada, e insere essas novas URLs na fila. O processo se repete até que o crawler decide
parar. As páginas coletas podem ser utilizadas para aplicações como em máquinas de busca, em Web caches ou em
estudos científicos, por exemplo.
Com a expansão diária do tamanho da Web, fica cada vez mais difícil coletar toda ou uma significante parte da Web em
um só processo. Então, a paralelização dos Web crawlers se tornam uma medida essencial para maximizar a taxa de
captura dos dados.
A construção de Web crawlers paralelos tem muitas vantagens mas trazem também alguns problemas e desafios
interessantes. Entre eles, podemos citar:
Sobreposição: com muitos processos rodando em paralelo para coletar páginas, é possível que diferentes processos
coletem uma mesma página múltiplas vezes.
Qualidade: geralmente é mais interessante coletar as páginas mais "importantes" primeiro, a fim de maximizar a
"qualidade" dos dados coletados. Em crawlers paralelos, cada processo pode não ter conhecimento da imagem de
toda a rede coletada, tomando decisões de acordo com a imagem local da parte que coletou.
Banda de Comunicação: periodicamente os processos precisam se comunicar para prevenir a sobreposição de
dados ou melhorar a qualidade da coleta. Entretanto, essa comunicação pode crescer bastante à medida em que o
número de processos aumentam.
A paralelização dos web crawlers nos trazem importantes vantagens em relação aos crawlers não paralelizados, como:
Escalabilidade: devido ao enorme tamanho da Web, é quase que uma obrigaçãoutilizar crawlers paralelos. Um
crawler de um único processo simplesmente pode não atingir a taxa de coleta desejada em certos casos.
Dispersão: os múltiplos processos de um crawler paralelo podem rodar em lugares geograficamente distantes, cada
um coletando dados de locais próximos geograficamente. Por exemplo, um processo no Brasil pode coletar páginas
dos países da América do Sul, enquanto um outro processo na Alemanha coleta dados da Europa. Essa dispersão
pode ser necessária quando um crawler serial não consegue lidar com uma carga pesada de uma coleta em larga
escala.
Redução: um crawler paralelo pode também reduzir a carga na rede. Por exemplo, assuma que um crawler na
América do Norte precise coletar uma página da Europa. Primeiramente, a página deve ir pela rede na Europa,
passando pela rede inter­continental Europa­para­América do Norte, e finalmente passa pela rede na América do
Norte. Se um processo de um crawler paralelo coleta todas as páginas européias, e outro processo coleta as
páginas da América do Norte, então o tráfego total na rede será reduzido.
Note que as páginas coletadas devem ser transferidas para uma central de comando, a fim de se construir um índice geral.
Essa transferência de dados pode ser bastante reduzida usando algum dos seguintes métodos:
Compressão: as páginas coletas e armazenadas podem ser comprimidas antes de serem enviadas a uma localização
central.
Diferença: ao invés de mandar uma imagem inteira de todas as páginas coletadas por um processo, é possível
mandar apenas a diferença entre a imagem corrente e a anterior. Isso pode reduzir o tráfego porque muitas páginas
são estáticas e não costumam ser atualizadas com muita frequência.
Sumarização: em muitos casos é necessário apenas um índice central, e não as páginas originais. Nesses casos,
apenas as informações relevantes precisam ser enviadas ao centro de comando.
Fica claro que para a construção de Web crawlers efetivos é necessário muito mais do que apenas uma simples
paralelização.
Arquitetura de um crawler paralelo
A figura acima nos mostra a arquitetura geral de um crawler paralelo, que consiste de múltiplos processos, referidos por 
. Cada   é responsável por executar uma tarefa básica de um crawler não paralelo. Ele coleta
páginas da Web, armazena as páginas localmente, extrai todas as URLs que encontrar e segue os links. Dependendo da
forma com que as tarefas são divididas entre os  , pode ser necessário a troca de dados entre os processos. A
distribuição de tarefas entre os   pode ser feita numa rede local (como uma LAN), ou em localizações
geograficamente distantes (como uma WAN).
Intra­site crawler: quando todos os processos rodam em uma mesma rede local e se comunicam em alta velocidade.
Na figura anterior, isso pode ser observado no caso onde todos os   rodam na rede local da parte de
cima.
Crawler distribuído: quando todos os processos rodam em localizações geograficamente distantes. Quando os
processos nessas localizações distantes se conectam via Internet, se torna importante determinar a frequência e a
quando os processos devem se comunicar.
Em um crawler que roda com múltiplos processos, é possível ocorrer o problema da sobreposição. Para evitar esse
problema, os processos devem ser coordenados entre eles para saber quais páginas cada um deve coletar. Essa
coordenação pode ser feita seguindo algum dos caminhos:
Independência: os   podem coletar páginas de uma maneira completamente independente um dos outros
sem qualquer coordenação. Cada processo começa com um conjunto de URLs e vai seguindo os links sem
consultar outro processo. Neste cenário, o problema da sobreposição pode ocorrer.
Assinalamento Dinâmico: ocorre quando existe uma central de comando que divide a Web em partições pequenas,
usando para isto alguma função pré­estabelecida, e dinamicamente assinala cada partição a um processo. Essas
partições podem ser feitas em diferentes granularidades, o que afeta a comunicação entre os processos e a central
de comando.
Assinalamento Estático: ocorre quando a Web é particionada e assinalada a cada   antes de começar a
coleta. Neste caso, cada   sabe qual   é responsável por qual página, não precisando de uma
central de comando para isto.
Conclusão
Web crawlers vem sendo utilizados com cada vez mais frequência para coletar dados da Web para máquinas de busca,
caches e mineração de dados. Como o tamanho da Web aumenta a cada dia que passa, o uso de crawlers paralelos vem
se tornando cada vez mais importante. Conforme observado nessa subseção, construir um crawler paralelo eficiente é
muito mais complicado do que uma simples paralelização.
Programação paralela na web
Ambientes de programação
Bibliotecas de programação
Linguagens de programação
O aumento da velocidade da conexão à internet pela maioria dos usuários permitiu que as páginas na web se tornassem
verdadeiras aplicações, podendo até mesmo susbstituir algumas (como um editor de texto ou uma planilha eletrônica) que à
pouco tempo atrás pensou­se ser inviável.
Essa sessão apresentará algumas linguagens voltadas para web e como tratar questões de paralelização e concorrência em
cada uma delas.
Java Script
Essa sessão terá como foco como carregar componenetes em paralelo em um site em HTML. Esses componenets podem
ser arquivos em javascript, podendo ser extendidos a arquivos css, ou imagens. Ápos isso será abordado a questão do
AJAX principalmente usando o objeto XmlHttpResquest.
Carregando componentes em paralelo
O número de conexões HTTP que o cliente abre com o servidor é definida pelo navegador. Navegadores atuais
geralmente abrem muitas conexões com o mesmo site quando se requisita uma página (esse número de conexões depende
do navegador em questão[2] (http://www.mozilla.org/quality/networking/docs/netprefs.html), mas navegadores antigos
abrem no máximo duas conexões com o servidor [3] (http://support.microsoft.com/kb/183110). Isso permite que o
navegador faça download dos componentes paralelamente, baixando o site mais rápido. Figuras são um bom exemplo de
componentes que são baixados paralelas, automaticamente, pelo navegador. Mas arquivos javascript não são.
Quando você carrega arquivos em javascript na sua página, na forma usual, eles são carregados em sequência:
<script src="Arquivo1.js" type="text/javascript"></script>
<script src="Arquivo2.js" type="text/javascript"></script>
O tamanho dos arquivo em javascript tem crescido muito, e está se tornando comum páginas com chamadas à muitos
arquivos grandes. Isso pode deixar a página lenta e bem de desagrádavel para o usuário. A saída é carregar esses arquivos
em paralelo:
é claro que se a conexão do usuário é ruim carregar os scripts em paralelo não resolve muita coisa.
Uma das maneiras de se fazer isso é usar um document.write:
<script type="text/javascript">
 document.writeln("<script src='Arquivo1.js' type='text/javascript'><" + "/script>");
 document.writeln("<script src='Arquivo2.js' type='text/javascript'><" + "/script>");
</script>
O navegardor abrirá duas conexões com o host e fazendo os downlaods dos arquivo em paralelo. Entretanto a execução
dos mesmo é sequencial. Mas se Arquivo2.js for carregado e o usuário pára o carregamento da página enquando o
Arquivo1 ainda é baixado o Arquivo2.js será executado (isso pode não ser válido para o internet explorer).
O número de arquivos, ou qualquer outro componente que é baixado separadamente como imagens, que podem ser
baixados em paralelo, usando esse esquema, é limitado pelo número de conexões que navegador pode fazer com o host.
Para se estender o número de conexões paralelas é necessário mudar o nome do host, criando alias para o nome do host,
por exemplo imagens1.exemplo.com e imagens2.exemplo.com.
 <img src="imagem1.png" />
 <img src="imagem2.png" />
 <img src="http://imagens1.examplo.com/imagem3.png" />
 <img src="http://imagens1.example.com/image4.png"/>
 <img src="http://imagens2.example.com/image5.png" />
 <img src="http://imagens2.example.com/image6.png" />
Atualmente os navegadores abrem muitas conexões em paralelo, e ainda é póssivel aumentar esse número. Esse último
esquema é mais útil para navegadores limitados a somente duas conexões.
AJAX (requisições concorrentes)
A algum tempo atrás o modelo clássico das aplicações na web era puramente sequêncial. Você tinha uma seqüência de
chamadas de funções e elas sempre eram executadas em uma certa ordem. Mas a forma de programar para web mudou.
As aplicações aumentaram de porte. Muito disso deve­se ao conjunto de tecnologias AJAX.
A razão pela qual o AJAX se tornou tão popular deve­se a sua capacidade de realizar ações concomitantes ou por "traz
dos panos" para o usuário. Entretanto não existe uma real concorrência em javascript, muito menos processamento
paralelo. Mas é póssivel criar uma ilusão de certo grau de concorrência.
Um dos modos de se trabalhar com AJAX é recuperando os dados de forma assíncrona usando o objeto
XMLHttpRequest. Há duas maneiras de se fazer uma requisição com um objeto XMLHttpRequest, uma é síncrona, outra
assíncrona. No modo síncrono, quando você manda o objeto fazer uma requisição, o seu script é interrompido esperando
pelo retorno. Quando a chamada é assíncrona, logo que a chamada é feita o fluxo de execução volta para o script,
permitindo que ele execute outras funções ou ainda outras chamadas ao objeto. Como a essa chamadas não são realmente
concorrentes a ordem que elas são feitas é um fator importante. O que define uma chamada como síncrona ou assíncrona é
o terceiro parâmetro do método open do objeto. Um modelo clássico de fazer chamadas ao XMLHttpRequest é esse:
var req;
function loadXMLDoc(url)
{
 req = null;
 // Procura por um objeto nativo (Mozilla/Safari)
 if (window.XMLHttpRequest) {
 req = new XMLHttpRequest();
 req.onreadystatechange = processReqChange;
 req.open("GET", url, true);
 req.send(null);
 // Procura por uma versão ActiveX (IE)
 }
 else if (window.ActiveXObject) {
 req = new ActiveXObject("Microsoft.XMLHTTP");
 if (req) {
 req.onreadystatechange = processReqChange;
 req.open("GET", url, true);
 req.send();
 }
 }
}
function processReqChange()
{
 if (req.readyState == 4) {
 if (req.status == 200) {
 document.getElementById('teste').innerHTML += '<br><br> Nova Requisição'+req.responseText;
 } else {
 alert("Houve um problema ao obter os dados:\n" + req.statusText);
 }
 }
}
Fazer chamadas ao ao método open em sequência, sem que a primeira chamada tenha sido concluída costuma não
funcionar e os resultados são inesperados. O que gerealmente é feito é criar uma fila de chamadas e executa­las
sequencialmente:
function insereFila(id,url){
 //insere na fila
 fila[fila.length]=[id,url];
 //Se não há conexões pendentes, executa
 if((ifila+1)==fila.length)executa();
}
//Executa a próxima conexão da fila
function executa(){
 req.open("GET",fila[ifila][1],true);
 req.onreadystatechange=function() {
 if (xmlhttp.readyState==4){
 document.getElementById(fila[ifila][0]).innerHTML=req.responseText;
 //Roda o próximo
 ifila++;
 if(ifila<fila.length)setTimeout("executa()",20);
 }
 }
 req.send(null);
}
Ou ainda é póssivel criar outros objetos XMLHttpRequest.
PHP
PHP não é uma linguagem multithread, mas é póssivel simular paralelismo utilizando multiprocesso. Quando um processo
pai cria um processo filho ambos os processos são executados concorrentemente. Isso é póssivel em PHP através do PHP
Process Control Functions (PNCTL). Para isso o pacote PHP deve ser compilado com a opção ­­enable­pcntl, disponível
somente em sistemas linux.
Essas função não deveriam ser usadas dentro de um servidor web e resultados inesperados podem ser obtidos quando isso
é feito [4] (http://www.php.net/manual/en/ref.pcntl.php).
Esse é um exemplo simples de criação de um processo em PHP:
$pid = pcntl_fork();
if($pid) {
 //o que deve ser rodado no processo pai
 echo "pai";
}
else {
 // o que deve ser rodado no processo filho
 echo "filho";
}
Principais funções
Essas são as principais funções para criação e manipulação de processos:
Int pcntl_alarm (interno $ segundos)
Cria um temporizador que envia um sinal SIGALRM para um processo. Qualquer nova chamada a pcntl_alarm cancela a
anterior.
void pcntl_exec ( string $path [, array $args [, array $envs ]] )
Executa um programa no espaço de mémoria do processo conrrente. O primeiro argumento é o caminho para o programa.
O segundo é um vetor de argumentos passados ao programa.
int pcntl_fork ( void )
Essa função cria um processo filho que difere do precesso pai pelo PID ou PPID. Equivale à uma chamada ao fork() do
sistema.
bool pcntl_signal ( int $signo , callback $handler [, bool $restart_syscalls ] )
envia um sinal definido por signo.
int pcntl_wait ( int &$status [, int $options ] )
O processo atual suspende sua execução e aguarda até que determinado sinal seja emitido.
JAVA
Nessa seção estaremos vendo detalhes da implementação de aplicações multitarefa usando a linguagem Java.
A linguagem Java fornece uma classe chamada Thread a partir da qual o programador pode criar suas próprias threads.
Para isso, é preciso que o programador estenda essa classe e implemente as devidas customizações, reescrevendo o
método run().
public class ThreadSimples extends Thread {
 public ThreadSimples(String str) {
 super(str);
 }
 public void run() {
 for (int i = 0; i < 100; i++) {
 System.out.println(i + " " + getName());
 try {
 sleep((long)(Math.random() * 1000));
 } catch (InterruptedException e) {}
 }
 System.out.println("Pronto! " + getName());
 }
}
O método run() é onde colocamos toda a lógica de execução da thread. O método run() da classe ThreadSimples contém
um loop que é executado 100 vezes. Em cada iteração, o método exibe na saída­padrão do sistema o número
correspondente àquela iteração e o nome que foi associado à thread. Então, a thread entra em modo de espera de acordo
com o retorno da chamada Math.random(). Quando o loop termina, o método run imprime Pronto! seguido do nome da
thread.
No exemplo a seguir é usado duas threads da classe acima:
public class exemplo {
 public static void main (String[] args) {
 new ThreadSimples("Jamaica").start();
 new ThreadSimples("Fiji").start();
}
}
Uma outra técnica que pode ser utilizada para implementação de threads na linguagem Java é o uso da interface Runnable:
import java.awt.Graphics;
import java.util.*;
import java.text.DateFormat;
import java.applet.Applet;
public class Relogio extends Applet implements Runnable {
 private Thread clockThread = null;
 public void start() {
 if (clockThread == null) {
 clockThread = new Thread(this, "Clock");
 clockThread.start();
 }
 }
 public void run() {
 Thread myThread = Thread.currentThread();
 while (clockThread == myThread) {
 repaint();
 try {
 Thread.sleep(1000);
 } catch (InterruptedException e){
 ...
 }
 }
 }
 public void paint(Graphics g) {
 Calendar cal = Calendar.getInstance();
 Date date = cal.getTime();
 DateFormat dateFormatter = DateFormat.getTimeInstance();
 g.drawString(dateFormatter.format(date), 5, 10);
 }
 public void stop() {
 clockThread = null;
 }
}
Conclusão
Neste capítulo foi apresentado sobre algumas importantes aplicações paralelas que existem na Internet. A principal
vantagem apresentadas por essas aplicaçõessão o aumento da escalabilidade, desempenho e confiabilidade.
Inicialmente foram apresentadas algumas importantes aplicações sobre infra­estrutura, em seguida sobre aplicações
distribuidas, e por último mostramos alguns recursos que linguagens de programação oferecem para a construção de
aplicações paralelas para a Internet.
Referências
A Parallel Downloading Protocol for the Internet
(http://www.deakin.edu.au/scitech/sit/dsapp/archive/upload/20071002_134654brock_06_appfti.pdf)
Preparing PHTTP for the Real World
(http://www.deakin.edu.au/scitech/sit/dsapp/archive/upload/20071002_135006Brock%202007%20­
%20Preparing%20PHTTP%20for%20the%20Real%20World.pdf)
Implementing a parallel file transfer protocol (http://www.patentstorm.us/patents/6085251­fulltext.html)
Parallel Database Systems: The Future of High Performance Database Processing
(http://web.archive.org/web/20090206093546/http://pages.cs.wisc.edu/~cs764­1/paralleldb.pdf)
Using parallel Oracle for high­speed e­commerce systems (http://www.dba­oracle.com/art_ops1.htm)
Parallel Crawlers (http://oak.cs.ucla.edu/~cho/papers/cho­parallel.pdf)
Computação em Grade ­ Uma Visão Introdutória (http://www.clubedohardware.com.br/artigos/124/1)
Grid Computing (http://en.wikipedia.org/wiki/Grid_computing)
Rodando Aplicações Paralelas Leves em Escala Mundial: A Perspectiva do Usuário
(http://web.archive.org/web/20041123211831/http://www.inf.ufrgs.br/procpar/hetnos/grid/papers/open_grid.pdf)
Peer­to­Peer ­ Wikipedia (http://en.wikipedia.org/wiki/Peer­to­peer)
Peer­to­Peer (http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci212769,00.html)
Mozilla Network Preferences (http://www.mozilla.org/quality/networking/docs/netprefs.html)
Loading Javascript Files in parallel (http://blogs.msdn.com/kristoffer/archive/2006/12/22/loading­javascript­files­in­
parallel.aspx)
Concurrent Ajax (http://www.hunlock.com/blogs/Concurrent_Ajax)
Introdução ao Ajax (http://tableless.com.br/artigos/ajaxdemo/)
Ajax faq for the JAVA developer (https://blueprints.dev.java.net/ajax­faq.html#concurrent_requests)
Concurrent xml queries with ajax (http://www.hwhappy.co.uk/2006/11/07/concurrent­xml­queries­with­ajax/)
Thread em JAVA (http://www.lcmi.ufsc.br/~romulo/discipli/cad­ii2/thread­socket­java.pdf)
Processo paralelos em PHP
(http://www.hristov.com/andrey/projects/php_stuff/pres/writing_parallel_apps_with_PHP.pdf)
PHP Process Control Functions (http://www.php.net/manual/en/ref.pcntl.php)
Obtido em "https://pt.wikibooks.org/w/index.php?title=Programação_Paralela_em_Arquiteturas_Multi­
Core/Aplicações_Internet&oldid=272476"
Categoria:  Livro/Programação Paralela em Arquiteturas Multi­Core
Esta página foi modificada pela última vez à(s) 07h54min de 25 de agosto de 2014.
Este texto é disponibilizado nos termos da licença Creative Commons Atribuição­Compartilhamento pela mesma
Licença 3.0 Unported; pode estar sujeito a condições adicionais. Consulte as Condições de Uso para mais detalhes.