Slashdot Mirror
Java EE & Streaming Architectures
Amin Ahmad writes "Implementing a streaming architecture on a Java EE application server provides asymptotically better memory performance, and, hence, scalability, than current, widely-implemented, Java EE patterns endorsed by Sun. This article provides a concrete implementation of a streaming architecture and compares its scalability to two other, standard implementations: Remote EJB and Local EJB-based solutions. The implementation based on a streaming architecture comes out the hands-down winner: for example, when sending back 300 rows of data to the client, the Local EJB solution fails beyond 16 concurrent users whereas the streaming solution is still running at 128 concurrent users!
The article includes complete source code and the entire results database for the stress test. I would be interested in hearing your feedback."
Anyone interested, please check the source code. If I understand it correctly, in his benchmark, he is not using any EJBs, he simply "simulate" this by adding serialization+deserialization to the code. It's quite optimistic to call this benchmark at all. Is it really that surprising that when I order computer to do X and then do X + something more, that it will be slower than the first case?
Adding layers to architecture is not primarily done to increase performance, but to create clean and easy to maintain design. If the implementation is not performing as required, it should be profiled and only then critical parts should be optimized for performance. If somebody in my team would dare to write code similar to this "streaming architecture" (read: plain old servlet with database access and model object polluted with html tags) it would be his last contribution to the project.
Wow, so much ignorance in just one post.
JSP is a nice try to eat into the PHP market.
Nope, different markets. JSP is for people who understand the Model, View, Controller architecture and are capable of building systems around generalised code (POJO's). PHP is ideal for small scale web apps, but that's it - it encourages unstructured code and no separation between presentation and business logic tiers.
But it's so slow and far away from the reality of productive systems that the Apache crew rather forked their server to a Java-only server (Tomcat) to keep their httpd codebase clean and free of anything that is Java.
Tomcat originated with Sun, as a proof of concept web container. The code was donated to the Apache foundation, and there has never been any plan to merge it with the Apache HTTP daemon. People usually proxy from Apache to Tomcat, as they have static content to serve as well, or just to keep web servers in the DMZ behind a single firewall and the web container servers behind a second firewall so that database connections and things like CORBA connections are more secure.
EVen if Java is open source now. There is a reason why Java applets have become almost distinct. Even Flash evidently performs better than an Java applet.
I assume you mean "extinct" rather than "distinct". However, applets have bugger all to do with JSP and webapps. They were a neat way of promoting the Java platform when it came out, but are tiny part of what made Java popular.
And why the hell would anyone still need this "Compile once, run anywhere." nonsense?
Because it's easier to port a virtual machine than a complete toolchain.