LinkedIn Architecture - case de sucesso com Java

Assuntos Gerais Notícias
#1

Vejam esse artigo mostrando a arquitetura do LinkedIn:

Site Statistics:

:arrow: 22 million members
:arrow: 4+ million unique visitors/month
:arrow: 40 million page views/day
:arrow: 2 million searches/day
:arrow: 250K invitations sent/day
:arrow: 1 million answers posted
:arrow: 2 million email messages/day

Para manter isso rodando usam Tomcat e Jetty :slight_smile:

http://cookiesareforclosers.com/blog/2008/06/linkedin-architecture

#2

ola,
meu nome é Gian, sou da Praia Grande
gosto muito da linguagem java mas
tenho dificuldades em aprender
mas nao perco a minha força de vontade
vc tem alguma sujestão em poder me ajudar
grato.

#3

[quote=gian_grm]ola,
meu nome é Gian, sou da Praia Grande
gosto muito da linguagem java mas
tenho dificuldades em aprender
mas nao perco a minha força de vontade
vc tem alguma sujestão em poder me ajudar
grato.[/quote]

Comece lendo nossos artigos… :slight_smile:

#4

[quote]The cache is implemented in C++, accessed via JNI. They chose C++ instead of Java for two reasons:

* To use as little RAM as possible.
* Garbage Collection pauses were killing them. [LinkedIn said they were using advanced GC's, but GC's have improved since 2003; is this still a problem today?][/quote]

nunca vi um caso de alguem que o teria feito. interessante!

#5

Achei realmente curioso o cache ser implementado em C++

Alguem opinando ai ?

#6

Tomcat E Jetty? Não entendi!

#7

ola boaglio,
digitei no bloco de notas e como faço para fazer no java

#8

[quote=chun]Achei realmente curioso o cache ser implementado em C++

Alguem opinando ai ?[/quote]

Qual o problema disso? É muito difícil ter uma representação compacta de estruturas de dados em Java. Maioria da implementações de caching em Java que eu vi não usam objetos
para armazenamento. Ou usam ByteBuffers ou usam código nativo.

#9

[quote=gian_grm]ola boaglio,
digitei no bloco de notas e como faço para fazer no java[/quote]

Use sua força de vontade que você disse que tem e leia os tutoriais.
Tá tudo lá.

Foi a melhor solução na época.

Conheço uma empresa que optou por alterar um módulo do Apache e gerenciar a memória dessa maneira.

Hoje talvez Java atenda, seria um case legal se eles conseguissem migrar (e claro, houvesse algum ganho com a mudança).

#10

In prior JDK releases, the java command line launcher invoked the JVM in the primordial thread created by the operating system. This imposed several limitations on tuning the stack size and on the stack itself. With this release, the JVM is invoked from a user level thread, allowing stack sizes to be configured by the user.

See bug report 6316197 for more information.

In prior JDK releases, Xcheck:jni was stringent in its checking and would abort on the first minor error encountered. Updates in this release allow errors to be flagged as warnings, and the JVM will continue. This is intended to aid in debugging and uncovering potential underlying issues.

Please note that it’s not safe for user [size=18]JNI Applications[/size] to call into most JNI methods with a pending Exception. The exception must first be cleared or handled as described in the the JNI Specification.

If a JNI method is called with a pending exception, and if the JNI method while performing VM operations takes an Exception, the pending Exception is discarded and the new Exception is thrown.

See bug report 6253381 for more information.

At this release, the -Xincgc option invokes the incremental mode of the concurrent garbage collector instead of the standard mode of that collector. The incremental mode of the concurrent garbage collector does its concurrent work in time slices that are scheduled between minor collections. The intent of the incremental mode is to allow the application access to the processor otherwise used for the concurrent. This mode can be particularly useful on single processor platforms.

#11

conforme citacao acima. eles ainda aparentam ter problemas quanto ao GC. teve uma discussao a um tempo atras quanto a arquitetura utilizada no e-bay(acredito que no infoq) e nao foi preciso chegar a este nivel. pelo jeito eles apelaram mesmo ou sera que o jetty nao ta dando no tranco?

#12

O problema não me parece ser o GC, mas o fato que Java desperdiça muita memória com objetos pequenos. Se você quer construir uma tabela p/ fazer caching de 20 milhões de entradas, você vai desperdiçar coisa de 400 megas só por conta de headers e ponteiros. Isso se tem objeto só usar valores escalarem.

#13

Realmente estou em choque com isso tudo desse tamanho, e estou tb me perguntando como é esse “cache” em C++

Mais ta ai gostei viu…

#14

Muito interessante o artigo, achei legal o resumo no final e resolvi colar:

Seria este último item, uma alfinetada ao pessoal do Twitter !?!

#15

relamente uma estrutura de cache interessante pra aguentar tudo isso.

#16

Nem eu.

Um amigo de um amigo que tem outro amigo que trabalha no Google falou que o core deles é feito em C++ também…

edit
Aliás, queria até pegar rabeira e perguntar uma coisa: executei um AG que demorou ± uns 10 minutos. Se eu executar algo do tipo em C++, fica impossível de mexer no computador (minimizar e coisarada), mas se eu executar com o Java, posso trabalhar tranquilamente. Isso é por causa que vai rodar sobre a JVM ou algo parecido?

#17

Com relação ao Jetty e ao Tomcat, pelo que vi na estrutura deles, o Jetty é usando só pra fornecer os dados quem vem dos serviços (que são máquinas só para inclusão e atualização de perfil, notícias e etc…), e o Tomcat é usando como Front End.

Isso se deve a performance maior do Jetty, porém para os trabalhos de GUI e chamadas aos serviços que estão nos servidores com Jetty, deve ter sido usado o Tomcat pelo número maior de recursos que o Jetty (por isso o Jetty acaba sendo mais performático, implementação menor).

Isso vcs pode ver nos links abaixo:
http://www.slideshare.net/linkedin/linked-in-javaone-2008-tech-session-comm
http://www.slideshare.net/linkedin/linkedins-communication-architecture

No slide 22 do segundo link existe um diagrama dessa estrutura.

Já com relação ao cache implementado em C++ e com acesso via JNI, pode ter sido usado algo como memcached http://en.wikipedia.org/wiki/Memcached, ou pode ser uma implementação própria mas que tem a mesma idéia do memcached.

O uso do memcached é uma ótima idéia de cache distribuído, que pode ser acessado por várias linguagens.

Acho q é isso…

#18

Nem eu.
[/quote]

Acho que esse é o maior projeto que eu ouvi falar que está usando o Jetty.

A primeira vez que ouvi falar do Jetty foi aqui no GUJ mesmo, onde o CV sugeria pra alguém usar.

Depois que eu li o artigo do Fabio Kung , passei a usar para desenv e até hoje não me arrependo. :slight_smile:

#19

Realmente, arquitetura interessante. Fico pensando pq não utilizam esquemas como MapReduce para cacheamento, poderia ser uma alternativa à escrita em C++.

Também optaram por um modelo de JDBC direto, sem uso de mapeamentos ORM, provavelmente nos dias de hoje com técnicas de cache, talvez pudesse ser utilizado um sistema de ORM ao invés de fazer JDBC na mão. Imagino que tenham implementado um sistema de cacheamento de queries na mão, mas a implementação disso, acaba sendo árdua.

Queria ver alguma arquitetura com MapReduce, Gigaspaces… 8)

#20

esse modelo de programação distribuída, tenho visto, sendo bastante divulgado o uso do terracota.
Alguém já o utilizou ou deixou de utilizá-lo?