IDependOn-Set: 1
IDependOn-Set: 2
IDependOn-Set: 20
IDependOn-Set: 21
IDependOn-Set: 297
LastModifiedSecs: 936983419
Parent: 20
SequenceNumber: 5
Title: Performance Implications
Part: 0
Author-Set: neville@codestudio.com
HideAttributions: 1
LastModifiedSecs: 936983419
Lines: 12
We've successfully implemented a jserv <-> ejb app server solution, but found that it really was overkill for the servlet portion of the distributed app. While the EJB server performs tons of useful duties for the stand-alone client we created, jserv itself handles these duties for servlets.


Consider the performance implications of performing rmi or rmi-iiop lookups through jndi, and then subsequent distributed method calls through rmi, and add to that the app server's database calls (for container-managed persistence), and you have a ton of possibly unnecessary overhead. And if the app server isn't clustered in some way, its one machine quickly becomes a bottleneck.


So while the architecture certainly works, a better question is whether it's even necessary. We ended up using simply jserv on a bunch of cheap web servers (simple round-robin approach to load balancing and failover) with some jdbc connection pooling and simple authorization code thrown in. Had our servlets or web output been more complex, perhaps using the benefits of the app server would have outweighed its performance issues. But common sense dictated we avoid it, even though we love the new ejb technology.


PS Neville

neville@codestudio.com
EndPart: 0
