> I didn't want to suggest that GF is slow,
I know... I was just using the oppty to suggest that you may want to
wait for some news on this front. We have made very significant
performance improvements since GF v1 and we hope to talk about them
pretty soon.
Sorry for the teaser...
- eduard/o
glassfish_at_javadesktop.org wrote:
>> Stay tuned on performance; I think you will like what
>> you will see...
>>
>> I can assure you we are not "just 'fast enough'"...
>
> I didn't want to suggest that GF is slow, but I have simply not run into any performance problems in my use, but we don't stress it really hard however.
>
> By using the term "Fast enough", basically I don't feel that GF is getting in the way of our system getting things done. Every method call and whatever "counts", and all of that infrastructure "adds up", but we're not seeing or feeling anything from GF. It seems to stay out of the way.
>
> I will be frank tho, that according to the SPEC marks as of mid last year (I don't recall the last time you guys ran your spec test), it was certainly "less fast" than Weblogic, if you compared server to server, instance to instance. This was a J2EE 1.4 benchmark also. Yes I know they didn't run on the exactly the same hardware, etc. etc. etc., but on a server per server case, the WLS benchmark hardware wasn't that drastically different than SJAS hardware, at least not enough in my eye to compensate for the difference in performance recorded.
>
> HOWEVER, in many cases, most applications are limited by their DB tier rather than the application server. And if your application is written well enough to partake in a load balanced configuration (not spectacularly difficult for many applications -- the community has been preaching the design models for year), then whatever performance difference is recorded between WLS and SJAS can be readily, and practically, compensated by hardware. And you can buy a LOT of hardware for the price of BEA WLS licenses.
>
> Finally, many IT systems are tapped out trying to eek out the last 10/10th of performance, but a significantly larger percentage really aren't. They're simply not loaded that hard.
>
> I can safely say, tho, so far, that because of JEE 5, EJB3, and the JPA, and leveraging that technology, our applications run better, and are easier to maintain. GF is not the sole perveyor of such technology, but the combination and integration of the whole thing: GF, NB, EJB3, and the low learning curve and overall ease of use makes the entire package a "performance win" for our apps as is.
>
> If and when GF gets in the way, we'll route around it, just like we always have, just like we've done with other JEE servers in the past, and leverage the server where it fits us best. The best part is the server is handling more and more of the stuff we need to do and we have to work around it less and less.
>
> Trust me, if GF implodes and starts getting in the way, y'all will hear about it here from me first.
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=223609
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>