Servidor DataSnap

Colocando um Servidor DataSnap Prova - Revista ClubeDelphi Mag...
http://www.devmedia.com.br/colocando-um-servidor-datasnap-a-prova...
Tecnologias
Revistas
Cursos
Pocket videos
DevWare
Frum
Servios
Publicar
Compre Crditos Fale conosco
Loja Virtual
Assine
Seja bem vindo, LUIZ FERNANDO CAMPOS BHERING!
Meus Servios
[ClubeDelphi 151 - ndice]
15
Curtir
Gostei (11)
comentrios
(1)
Neste artigo apresentaremos uma anlise de performance e estabilidade da tecnologia DataSnap. As ltimas verses do Delphi trouxeram mudanas e melhorias para a tecnologia que a mais popular em softwares multicamadas para Delphi.
favoritar marcar como lido inserir nota pessoal
Artigo do tipo Exemplos Prticos Recursos especiais neste artigo: Artigo no estilo mentoring
Colocando um Servidor DataSnap Prova Neste artigo apresentaremos uma anlise de performance e estabilidade da tecnologia DataSnap. As ltimas verses do Delphi trouxeram mudanas e melhorias para a tecnologia que a mais popular em softwares multicamadas para Delphi. A anlise vai mostrar at que ponto a tecnologia capaz de suportar aplicaes com grande volume de requisies usando REST. Em eventos da comunidade Delphi, geralmente organizados pela Embarcadero, como a Delphi Conference e Webinars, a tecnologia DataSnap aparece como unanimidade entre os especialistas. comum assistirmos palestras de profissionais que contam experincias fantsticas com essa tecnologia e recomendam-na para qualquer software Delphi. Contudo temos aqui uma anlise que visa esclarecer at que ponto a tecnologia realmente uma escolha bvia para softwares Delphi e at onde a tecnologia atende as necessidades de um software grande. Essa anlise foi motivada como estudo de viabilidade para um projeto de software. importante fazer testes antes de comear a usar uma API. No se pode escolher uma API que ser responsvel por toda comunicao entre as camadas do seu software sem ter total conscincia do que ela capaz de suportar. H muito a ser avaliado na escolha de um framework desse tipo. necessrio assegurar-se que ele atende os requisitos de desempenho, estabilidade, escalabilidade e recursos que sero necessrios no projeto. Mudar um framework pode ser extremamente complicado no meio de um projeto e muitas vezes simplesmente invivel. muito mais barato testar e conhecer o que voc vai usar antes de colocar ele em seu projeto. s vezes uma tecnologia parece excelente em uma primeira anlise e mais tarde voc percebe que no serve para o projeto. Antes de adotar um framework, API, biblioteca, componente, faa testes de estresse e provas de conceito. Submeta a tecnologia ao mximo de estresse que for possvel, encontre o limite dessa tecnologia, s assim possvel ter condio de avaliar se a tecnologia serve ou no para o seu projeto. exatamente isso que fizemos com o DataSnap.
1 de 11
26/07/2013 08:02
Em que situao o tema til Quando se est avaliando a migrao de um software Delphi que usa a estrutura cliente-servidor para multicamadas ou est preocupado com a escalabilidade e performance de seu software multicamadas.
O modelo cliente-servidor ainda uma realidade para muitos softwares atuais. Este modelo atende bem a necessidade de softwares desktop, mas apresenta problemas a partir do momento em que se tem a necessidade de oferecer outras interfaces, como Web e Mobile. Ter diversas interfaces se conectando diretamente a uma base de dados traz grandes desafios que geralmente no compensam os riscos em softwares de grande porte. O mais indicado na maioria dos casos mudar o software para um modelo multicamadas. O modelo multicamadas nos permite separar diferentes partes do software tornando mais simples oferecer diversas interfaces para um nico domnio de negcio. Um exemplo de um modelo multicamadas simples, pode ser representado por trs camadas: base de dados, regras de negcio e interface. A camada onde se concentram as regras de negcio uma camada servidora, que vai fornecer dados e servios s camadas mais externas (interfaces). Uma mudana no modelo da arquitetura pode oferecer muitos desafios. A adio de camadas em uma arquitetura geralmente acrescenta complexidade, principalmente, na camada de comunicao entre as camadas. Desenvolver um software servidor tambm possui particularidades que uma empresa acostumada a trabalhar somente com softwares desktop pode no estar preparada para enfrentar. Gerenciamento de memria e desenvolvimento multithread passam a ser cruciais. Vazamentos de memria podem no ser um grande problema em um software desktop, mas certamente ser em um servidor. A anlise detalhada neste artigo vai avaliar o gerenciamento de memria e threads de algumas APIs. Para softwares Delphi, a tecnologia mais difundida para modelos multicamadas o DataSnap, desenvolvido pela Embarcadero. As ltimas verses do Delphi trouxeram grandes mudanas e melhorias.
O objetivo dessa anlise foi levar a tecnologia DataSnap ao seu limite. Descobrir seus limites nos permitiu avaliar com mais preciso quais requisitos a tecnologia capaz de atender e quais os ambientes onde a tecnologia recomendada. Os testes realizados buscaram medir os ndices de performance e estabilidade em ambientes crticos, com um alto nmero de requisies ao servidor.
Os testes se basearam em um servidor fornecendo um mtodo simples via REST. O mtodo disponibilizado pelo servidor no realiza qualquer processamento ou alocao de memria, simplesmente retorna o texto "Hello World". Dessa forma a API ser estressada ao mximo, no havendo influncia de qualquer outra implementao. Alm do servidor DataSnap, preparamos servidores com outras tecnologias. As tecnologias no necessariamente possuem o mesmo propsito, mas todas oferecem uma API REST. So elas (veja seo Links): mORMot (Delphi) ASP.NET WCF Jersey/Grizzly (Java) Node.Js (JavaScript) So tecnologias para diferentes plataformas e linguagens. Elas vo nos permitir ter uma base de comparao com o DataSnap. Essas tecnologias e linguagens no foram estudadas a fundo e estes softwares foram elaborados com um conhecimento mnimo. O ambiente e hardware utilizados so compostos por dois computadores intermedirios conectados atravs de uma rede gigabit. A Figura 1 mostra com mais detalhes esse ambiente.
2 de 11
26/07/2013 08:02
abrir imagem em nova janela Figura 1. Ambiente de testes No lado cliente utilizou-se o software JMeter para efetuar as requisies ao servidor. O JMeter uma ferramenta especializada em testes para servidores, desenvolvida em java. Essa ferramenta propicia uma srie de informaes relevantes, que foram utilizadas na anlise. A informao que serviu como base para a avaliao de desempenho foi a de requisies por segundo. O consumo de memria foi obtido atravs do software ProcessExplorer (ver seo Links) no final de cada execuo. Os testes realizados so de dois tipos, com e sem concorrncia nas requisies. No teste sem concorrncia, apenas um cliente realizava as requisies para o servidor. No teste com concorrncia a aplicao cliente possui 50 e 100 threads enviando requisies ao mesmo tempo.
A anlise apresenta resultados de quatro diferentes servidores usando a tecnologia DataSnap, so eles: DataSnap (Console) XE3: Aplicao console compilada no Delphi XE3; DataSnap (Console) XE3u1: Aplicao console compilada com o Delphi XE3 Update 1; DataSnap (ISAPI) XE3u1: Aplicao ISAPI compilada com o Delphi XE3 Update 1. DataSnap (VCL) XE3u1 w/ optimizations: Aplicao VCL compilada com o Delphi XE3 Update 1 com as otimizaes. Os testes mostraram problemas de estabilidade no DataSnap quando submetido a um teste de carga com concorrncia. A partir desses testes a Embarcadero liberou correes no Update 1 da verso XE3 para corrigir os problemas. Correes estas que no foram disponibilizadas para verses anteriores. Um dos servidores DataSnap foi compilado no Delphi XE3 (sem update) para efeito de comparao com o Delphi XE3 Update 1.
Nota: No h dados para os testes de carga com concorrncia para o servidor DataSnap (Console) compilado com o Delphi XE3 porque ele incapaz de rod-los devido aos problemas de estabilidade.
Existe uma srie de otimizaes que podem ser aplicadas a um servidor DataSnap. Geralmente as configuraes padres dos componentes e cdigos gerados pelos wizards do Delphi possuem configuraes suficientemente boas para funcionar, mas s vezes pouco otimizadas. importante buscar informaes sobre configuraes dos componentes que se est usando para buscar um maior conhecimento da API. Saber como ela funciona ajuda na hora de fazer algum ajuste fino. Uma boa forma de comear a conhecer a API do DataSnap montar um servidor sem a ajuda do wizard do Delphi. Ser necessrio conhecer qual a responsabilidade de cada componente e como ele se comunica com os demais. Conhecer cada componente da API e como eles se inter-relacionam vai fazer diferena na hora de buscar otimizaes. No veremos todos os tipos de otimizaes para o DataSnap, so apresentados alguns, que possuem influncia direta em estabilidade e desempenho do servidor.
Em uma comunicao HTTP, cada requisio enviada ao servidor requer a abertura de uma conexo. Assim que a requisio for respondida, essa conexo fechada. Desse modo, para cada requisio cria-se uma nova conexo. O procedimento de abertura e fechamento de uma conexo HTTP pode afetar o desempenho das aplicaes em casos onde a frequncia de requisies muito alta, como nos testes apresentados nesse artigo. O Keep-Alive um recurso do protocolo HTTP que tem como objetivo diminuir a quantidade de novas conexes que so estabelecidas com o servidor. Quando a aplicao cliente e servidor possuem o recurso Keep-Alive uma conexo pode receber diversas requisies, poupando tempo e processamento. Por outro lado, uma requisio ao servidor deixar sempre uma conexo aberta por um determinado tempo. Se o software cliente no estiver fazendo requisies em uma frequncia alta, isso pode afetar negativamente o desempenho do servidor. importante se aprofundar no assunto e sempre efetuar testes de estresse de acordo com situaes reais de cada projeto. Ao contrrio das demais tecnologias, essa opo vem desativada por padro no DataSnap. Para ativ-la basta alterar a propriedade Keep-Alive do IdHTTPWebBrokerBridge, que um componente da API. Infelizmente essa otimizao no foi aplicada nos servidores DataSnap usados nos testes. Inexplicavelmente houve uma queda muito grande na velocidade do servidor. Todos os demais servidores esto usando Keep-Alive e obtiveram ganhos de desempenho significativos. Aparentemente algum bug na API que deve ser corrigido pela Embarcadero no futuro.
Consumo de memria sempre importante, mas em servidores crtico. Servidores devem funcionar 24 horas por dia, 7 dias por semana. Devem funcionar anos a fio sem a necessidade de ser reiniciado.
3 de 11
26/07/2013 08:02
Se tratando de Delphi, onde o ciclo de vida dos objetos de responsabilidade do programador, comum haver problemas de vazamento de memria (memory leak), quando objetos no so destrudos aps sua utilizao. Em aplicaes desktop isso pode no ser um grande problema, por que frequentemente o sistema reiniciado. Em um servidor, um nico vazamento de memria em qualquer mtodo pode fazer sua aplicao entrar em colapso depois de alguns dias funcionando. Para quem est migrando de um modelo cliente/servidor para multicamadas, talvez, ter que se reeducar com relao a isso. Desenvolver para servidor requer um cuidado especial com a quantidade de memria que alocada. Todo e qualquer novo mtodo inserido no servidor deve ser avaliado. Um mtodo consumindo muita memria pode ser requisitado por centenas de clientes ao mesmo tempo e fazer com que o servidor use toda memria disponvel, o que far o servidor entrar em colapso. Em aplicaes 32 bits isso ainda mais crtico, porque voc ter no mximo 4Gb de memria para utilizar. Isso leva a um problema de escalabilidade da aplicao, que pode ser ainda mais difcil de resolver. Se todo cuidado pouco com relao a consumo de memria no servidor, tambm um item importante da API. Se a API tiver um gerenciamento instvel de memria, isso vai afetar sua camada de negcio. Um servidor parado significa a camada de negcio parada, o que semelhante a uma falha no banco de dados em um modelo cliente/servidor. Se isso acontecer, voc estar encrencado. A tecnologia REST propem servios que no mantm estado (Stateless), ou seja, o servidor no deve guardar dados da aplicao cliente em sesses. Na prtica isso mais complicado, porque s vezes se precisa dessas informaes. De qualquer maneira, internamente o DataSnap possui sesses, que parecem no ter utilidade para o servidor em si mas devem ser importantes para a API, j que no se pode desativ-las. Uma sesso criada a cada requisio REST ao servidor. Curiosamente, essa sesso no reaproveitada, mesmo quando o mesmo cliente faz outra requisio. Essa sesso possui um timeout em torno de 20 minutos e no destruda automaticamente. Dessa forma, requisies ao servidor significam novas sesses, que s so destrudas quando alcanarem o tempo determinado pelo timeout, ou seja, 20 minutos. Todas as requisies efetuadas em 20 minutos iro criar sesses e nenhuma ser destruda. Obviamente isso causar um consumo excessivo e desnecessrio de memria. Nos testes notou-se um aumento constante no uso de memria do servidor nos primeiros 20 minutos de execuo. Aps os 20 minutos iniciais as sesses comeam a ser destrudas devido ao timeout. Alm do consumo de memria existe o problema de overhead que essas sesses trazem. A criao e destruio delas afetam negativamente o desempenho do servidor, mas no se encontrou uma maneira de evitar isso. No h como desativar essas sesses e evitar o overhead, mas existe uma forma de forar a destruio dela ao final da execuo de um mtodo, diminuindo a quantidade de memria consumida pelo servidor. A cada requisio feita ao servidor, uma sesso ser criada e destruda. Daniele Teti escreveu um artigo no seu blog (ver seo Links) explicando essa tcnica. A Listagem 1 mostra um exemplo de um mtodo simples forando a destruio de uma sesso. Listagem 1. Forando a destruio das sesses internas do DataSnap
uses System.StrUtils, DataSnap.DSSession, Data.DBXPlatform; function TServerMethods1.HelloWorld: String; begin Result := 'Hello World'; GetInvocationMetaData.CloseSession := True; end;
Por padro a tecnologia DataSnap cria uma thread para responder cada requisio HTTP. Isso pode causar um problema de overhead quando se tem muitas conexes. Pode-se mudar isso criando um Thread Pool, que basicamente uma lista de threads criadas para responder as requisies. Essas threads so criadas na inicializao da aplicao e destrudas somente quando o aplicativo for fechado. Teoricamente haver sempre uma lista de threads pronta para atender as requisies e no haver criao e destruio de threads para cada requisio. A Listagem 2 mostra a implementao de um thread pool com 50 threads. Esse cdigo foi retirado do blog do Marco Cant (ver seo Links) Listagem 2. Criao de um Thread Pool
var SchedulerOfThreadPool: TIdSchedulerOfThreadPool; begin FServer := TIdHTTPWebBrokerBridge.Create(Self); SchedulerOfThreadPool := TIdSchedulerOfThreadPool.Create(FServer); SchedulerOfThreadPool.PoolSize := 50; FServer.Scheduler := SchedulerOfThreadPool; FServer.MaxConnections := 150; end;
A propriedade MaxConnections do servidor tambm pode ser alterada conforme a necessidade. Marco Cant sugere usar 150 no exemplo, mas isso depende do ambiente em que o servidor ser utilizado.
Nesse teste, h uma aplicao cliente com somente uma thread, enviando requisies sequencialmente, uma aps a outra. O servidor s recebe uma
4 de 11
26/07/2013 08:02
requisio por vez, sem haver qualquer concorrncia. O objetivo deste teste verificar o comportamento do servidor em um ambiente menos crtico que tambm servir de base para os outros testes. Foram efetuados testes com 100 mil e 1 milho de requisies (Figura 2).
abrir imagem em nova janela Figura 2. Teste de desempenho com 1 milho de requisies, uma thread possvel ver o resultado do primeiro teste e esse revela uma diferena grande entre as demais tecnologias e o DataSnap. Todos os servidores DataSnap obtiveram resultados semelhantes, mas extremamente baixos, j que os demais servidores foram em torno de 12 vezes mais rpidos. Os resultados semelhantes entre as demais tecnologias mostra que todas atingiram o limite imposto pelo ambiente e hardware utilizados. Como o desempenho foi idntico para os testes com 100 mil e 1 milho de requisies, os grficos mostram somente os resultados dos segundo teste. Quanto ao consumo de memria, obtiveram-se resultados diferentes nos dois testes, a Figura 3 exibe os dados de ambos os testes.
abrir imagem em nova janela Figura 3. Consumo de memria nos testes com uma thread Os resultados indicam diferentes comportamentos entre os servidores DataSnap. O servidor que no possui as otimizaes mostrou um consumo progressivo que aumenta conforme o nmero de requisies. Esse comportamento perigoso porque pode fazer com que o servidor consuma toda memria disponvel e entre em colapso. importante salientar que o consumo avaliado indica somente o que a API est consumindo, j que o mtodo implementado no servidor no realiza alocao de memria. Em uma aplicao real o consumo ser naturalmente maior. O servidor com otimizaes mostrou um consumo baixo, apesar de ter variado durante o teste. Isso demonstra que a otimizao realizada visando diminuir o consumo de memria fez o efeito esperado. Forar a destruio das sesses parece reduzir consideravelmente o consumo de memria, mas importante salientar que durante o teste o consumo varia, chegando a nveis mais elevados do que o apresentado nos grficos. Durante os testes verificou-se um comportamento, por vezes, imprevisvel com relao ao consumo de memria dos servidores DataSnap. possvel notar que no primeiro teste o servidor compilado com o XE3 Update 1 consome menos memria (77,8MB) que o servidor compilado no XE3 (95,30MB), mas esse mesmo comportamento no observado no segundo teste. O Update 1 do XE3 no traz melhorias no consumo de memria.
5 de 11
26/07/2013 08:02
O servidor java apresentou um consumo elevado, mas esse resultado precisa ser avaliado com cuidado, pois se trata de uma medio realizada sobre a JVM. Aplicativos Java para servidores tendem a utilizar o mximo da memria disponvel em prol do desempenho, mas esses aplicativos geralmente podem ser otimizados para utilizar diferentes quantidades de memria e isso no foi feito para esse servidor. Os demais servidores apresentaram consumo de memria baixo e invarivel. Destaque para o mORMot que utilizou somente 6MB durante todo o teste. O consumo de memria invarivel significa que independente das requisies que forem realizadas, a API sempre vai consumir a mesma quantidade de memria. Isso facilita o desenvolvimento com essa tecnologia porque no ser necessrio se preocupar com os picos de utilizao de memria da API durante a execuo do servidor. Os testes sem concorrncia apresentaram resultados a baixo do esperado para a tecnologia DataSnap. Ao que se referem estabilidade, todas as APIs testadas apresentaram bons resultados nesse teste.
Nesse teste a aplicao cliente possui diversas threads realizando requisies simultneas. O servidor recebe dezenas de requisies ao mesmo tempo. Foram realizados testes com 50 e 100 threads buscando simular um ambiente com uma grande quantidade de usurios. Cada thread responsvel por enviar 100 mil requisies ao servidor. Como o hardware cliente possui um processador com quatro ncleos, no se pode considerar que so executadas 100 requisies exatamente ao mesmo tempo, algo que pode acontecer em um ambiente de produo. A Figura 4 mostra os resultados do teste de desempenho de ambos os testes, com 50 e 100 threads.
abrir imagem em nova janela Figura 4. Teste de desempenho com multiplas threads No primeiro teste (50 threads) as tecnologias mORMot, Jersey e WCF apresentaram os melhores resultados. O Node.JS no obteve resultados to bons, mas ainda assim impressiona devido a sua arquitetura que s aproveita um ncleo do processador. possvel ter vrios servidores Node.JS na mesma estrutura para usufruir dos recursos de processadores com vrios ncleos, o que traria resultados, provavelmente, superiores aos demais. No segundo teste (100 threads) o mORMot obteve resultados significativamente melhores com relao aos demais, que praticamente repetiram o desempenho do primeiro teste. O desempenho dos servidores DataSnap em ambos os testes decepcionante. O servidor DataSnap leva 43 segundos para responder as requisies que um servidor mORMot responde em 1 segundo. Avaliando os resultados tem-se a impresso de que as otimizaes fazem o efeito contrrio com relao a desempenho, mas como h uma variao muito grande entre as diferentes verses, no se pode afirmar isso com certeza. A partir desses testes h uma nova varivel a ser considerada, a quantidade de requisies rejeitadas pelo servidor. No houve nenhuma requisio rejeitada nos testes sem concorrncia, mas nos testes com concorrncia flagramos um nmero considervel de erros, como mostra a Figura 5.
6 de 11
26/07/2013 08:02
abrir imagem em nova janela Figura 5. Porcentagem de requisies rejeitadas pelo servidor Esse ndice aparece somente nos servidores DataSnap. Todos os servidores DataSnap apresentaram taxas de erros em nveis preocupantes, prximos da totalidade de requisies. Por mais que os problemas de estabilidade, que faziam o servidor travar estejam corrigidos na verso XE3 Update 1, um servidor que rejeita 97% das requisies no pode ser usado em produo. Mesmo o servidor ISAPI, que obteve o melhor ndice, no poderia ser considerado um aplicativo estvel com uma taxa de erros de 61%. A Figura 6 exibe os resultados dos testes de consumo de memria. O servidor Java mostrou novamente um consumo excessivo de memria, o que comprova que a tecnologia Java tende a usar o mximo de memria possvel. Obviamente isso um comportamento que pode ser alterado e no representa com fidelidade o potencial dessa tecnologia.
abrir imagem em nova janela Figura 6. Consumo de memria em teste com mltiplas threads Servidores mORMot, WCF e Node.JS apresentaram novamente um consumo esttico e muito baixo, idnticos aos resultados dos testes sem concorrncia. O servidor DataSnap sem otimizaes consumiu uma quantidade grande de memria para este teste. Percebe-se novamente que o consumo sobe conforme a quantidade de requisies aumenta. Se o teste fosse estendido, em menos de 24 horas o servidor teria chegado ao limite de memria disponvel e entraria em colapso. O resultado do servidor DataSnap com as otimizaes melhor, mas no deixa de ser preocupante. Esse servidor apresentou um consumo normal no primeiro teste (50 threads), embora tenha atingido o dobro do teste sem concorrncia. Porm chegou a 250MB no segundo teste (100 Threads). Com as otimizaes impedindo que sesses fiquem abertas, no deveria haver esse consumo elevado.
Nem todos os testes puderam ser acompanhados durante todo o tempo de sua execuo, principalmente, devido ao tempo de execuo dos testes com DataSnap, que levaram vrios dias. Durante o monitoramento em tempo real de alguns testes notou-se alguns comportamentos estranhos, os quais sero apresentados a seguir. As Figuras 7 e 8 mostram informaes do servidor DataSnap com otimizaes.
7 de 11
26/07/2013 08:02
Figura 7. Servidor DataSnap durante teste com mltiplas threads
8 de 11
26/07/2013 08:02
Figura 8. Servidor DataSnap durante teste com mltiplas threads Nos grficos do ProcessExplorer possvel perceber uma variao no consumo de memria e alguns picos nos ndices de I/O. O I/O estava estvel a 22.3KB e subitamente pulou para 464,5KB. Depois de algum tempo voltou a estabilizar. Ao mesmo tempo o servidor possua 1153 threads. Foi possvel observar mais de 1450 threads em determinados momentos. No se encontrou uma explicao para esse comportamento, j que estamos usando um thread pool nesse servidor. No deveria haver mais threads do que o informado no Thread Pool. Outro comportamento estranho observado, este nos testes sem concorrncia, que alguns softwares interferem no desempenho do servidor DataSnap. Identificaram-se dois, Google Chrome e Eyebeam (VOIP). O mais impressionante que esses softwares interferem positivamente no servidor, ou seja, o servidor fica mais rpido quando esses softwares esto abertos. O servidor chega a ser quatro vezes mais rpido quando o EyeBeam est aberto. J com o Google Chrome, o desempenho do servidor varia conforme voc usa o navegador. A diferena facilmente identificada monitorando os ndices de I/O durante os testes.
Nota: Durante os testes aqui avaliados, as mquinas utilizadas no possuam nenhum software que pudesse interferir no teste. Antivrus, Firewall, Google Chrome, Eyebem, etc.
9 de 11
26/07/2013 08:02
O problema de estabilidade identificado na verso XE3, possivelmente tambm presente em verses anteriores, um problema srio para quem pretende utilizar essa tecnologia e est utilizando essas verses do Delphi. Quanto ao desempenho e estabilidade, o DataSnap no apresentou resultados satisfatrios no ambiente em questo. Isso no significa que ele no funcione bem em outros ambientes. Isso tambm no significa que um framework melhor que o outro. No se pode afirmar que um melhor do que o outro somente avaliando desempenho e estabilidade, embora sejam itens importantes. As melhorias lanadas no XE3 update 1 no representam uma grande reestruturao no DataSnap. Embora ele esteja um pouco mais estvel, ainda no se pode esperar que a tecnologia funcione em ambientes com muita concorrncia. Para resolver esses problemas a Embarcadero ter que reestruturar a API. O Marco Cant (atualmente Delphi Project Manager) escreveu a respeito do DataSnap em um de seus livros e a concluso foi semelhante apresentada por este artigo: Eu penso que se voc quer construir uma aplicao muito grande usando arquitetura REST voc deve construir sua prpria tecnologia ou usar algum desses prottipos. Para aplicaes de pequeno e mdio porte, por outro lado, voc pode provavelmente se beneficiar do suporte nativo da tecnologia DataSnap. - Marco Cant (Delphi Product Manager), Delphi 2010 Handbook Traduo livre. O DataSnap no ideal para aplicaes grandes, com uma grande quantidade de usurios, mas pode atender bem aplicativos de pequeno e mdio porte. O mais importante avaliar com cuidado cada framework, biblioteca ou componente antes de usar em qualquer projeto. Os testes realizados foram testes sintticos, visando o estresse mximo das APIs. No representam com exatido uma situao real. Aplicaes reais dificilmente chegaro a esse nvel de estresse na API, mas podem chegar prximo. Dependendo do tamanho e requisitos da aplicao voc poder utilizar o DataSnap sem problemas, mas tambm pode ser que voc se veja obrigado a encontrar outra soluo.
Links Blog do Roberto Schneiders http://robertocschneiders.wordpress.com/ Process Explorer http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx Artigo do Daniele Teti sobre DataSnap http://www.danieleteti.it/2012/12/15/datasnap-concurrency-problems-and-update1/ Post do Marco Cant sobre os problemas de desempenho http://blog.marcocantu.com/blog/datasnap_deployment_performance.html mORMot http://synopse.info/fossil/wiki?name=SQLite3+Framework WCF http://msdn.microsoft.com/en-us/library/dd456779.aspx Jersey https://jersey.java.net/ Node.js http://nodejs.org/
Roberto Schneiders
Bacharel em sistemas de informao pela UNOESC-SMO. Atua como analista/programador de sistemas pela Sysmo Sistemas (www.sysmo.com.br). Co-fundador da Eletrone (facebook.com/EletroneBrasil). Trabalha com Delphi e Java.
10 de 11
26/07/2013 08:02
15
Curtir
Gostei (11)
(1)
2 COMENTRIOS
Jos Moacir Tavares Moreira Poderia mostrar como utilizar o mORMot. Instalar e um pequeno exemplo [h 9 dias] - Responder
Wesley Yamazack Ol Jos, obrigado pelo seu comentrio.
Enviamos sua solicitao ao Roberto e tambm ao editor chefe da Clube Delphi.
Um abrao. [h 8 dias] - Responder
Cursos relacionados
Curso online - Aplicaes Client/Server com dbExpress e Firebird Curso Online - Sistema SysCash Curso Online - Criando uma Aplicao multi-camadas Completa com Delphi Aplicaes client/server com Windows Forms no Delphi 2006 Administrao do Firebird/InterBase [Ver todos]
DevMedia
Curtir 11.649 pessoas curtiram DevMedia. DevMedia | Anuncie | Fale conosco Hospedagem web por Porta 80 Web Hosting
2013 - Todos os Direitos Reservados a web-03
Plug-in social do Facebook
11 de 11
26/07/2013 08:02

Servidor DataSnap

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Servidor DataSnap

Uploaded by

Copyright:

Available Formats

Colocando um Servidor DataSnap Prova - Revista ClubeDelphi Mag...

Compre Crditos Fale conosco

Seja bem vindo, LUIZ FERNANDO CAMPOS BHERING!

[ClubeDelphi 151 - ndice]

Colocando um Servidor DataSnap Prova - Revista ClubeDelphi Mag...

Colocando um Servidor DataSnap Prova - Revista ClubeDelphi Mag...

Colocando um Servidor DataSnap Prova - Revista ClubeDelphi Mag...

Colocando um Servidor DataSnap Prova - Revista ClubeDelphi Mag...

Colocando um Servidor DataSnap Prova - Revista ClubeDelphi Mag...

Colocando um Servidor DataSnap Prova - Revista ClubeDelphi Mag...

Colocando um Servidor DataSnap Prova - Revista ClubeDelphi Mag...

Figura 7. Servidor DataSnap durante teste com mltiplas threads

Colocando um Servidor DataSnap Prova - Revista ClubeDelphi Mag...

Colocando um Servidor DataSnap Prova - Revista ClubeDelphi Mag...

Colocando um Servidor DataSnap Prova - Revista ClubeDelphi Mag...

Wesley Yamazack Ol Jos, obrigado pelo seu comentrio.

Enviamos sua solicitao ao Roberto e tambm ao editor chefe da Clube Delphi.

Um abrao. [h 8 dias] - Responder

You might also like