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."
I am 2 years gradutad in Electrical Marketeering and want to break into java2ee. Please send me the codes. I so love this sight, all storuies very fashinating. Thank thank thankyou all.
Will code for new sig.
I see the following problems with the article.
1. Other than MySQL, it doesn't specify the software in use (it implies Apache Tomcat, but that is not explicitly stated), except...
2. Microsoft Web Application Stress Tool. Pardon me if I refuse to put any faith into tools by Redmond. Particularly since, if Tomcat was in use, MWAST is being used instead of Apache's own ab tool.
3. Why wasn't Java 1.5 tested? By definition, Java 1.4 means that you're testing vs. EJB 2.x instead of EJB 3.x. I don't know what changes have been made between the two, as I haven't learned EJB, but I'm assuming there have been some changes between the two, for better or for worse.
4. What's causing the OutOfMemory errors? If a pair of servers are falling over at 16 simultaneous requests for a 301 row dataset, there's a major problem.
Just some thoughts.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
But you have to get the hell away from it when it you want to run something fast(!) and productive on a server.
JSP is a nice try to eat into the PHP market.
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.
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.
And why the hell would anyone still need this "Compile once, run anywhere." nonsense?
We have 2006. Not 1995.
The article could say ANYTHING vs. EJBs is faster. I love Java and have successfully built several websites, but I feel EJBs are the antichrist. I avoid EJBs like the plague.
"No matter where you go, there you are." -- Buckaroo Banzai
A new DriverManager and a new db connection for every request? Welcome to 1998.
Even though they return 1000 rows, 50 requests per minute is pretty poor. Voca processes 80 million bank payment per day using Spring.
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.
So the moral of this article, if you read and process any decent amount of data, process this data in a serialized fashion; for example use SAX instead of DOM. Also make sure your JDBC connections are tuned correctly to exhibit this 'chunking' behavior or else it won't matter anyways.
From the Article: Lines 8 through 14 open a connection to the database and configure the statement. It is critical to configure the connection and statement so that the database server does not send the entire result set to the application server, but rather sends chunks on demand. Clearly if the entire dataset is sent in a single piece to the application server, we will have nothing to show for our labors! To accomplish this in MySql 5 requires setting useCursorFetch=true and setting the fetch direction of the statement to ResultSet.FETCH_FORWARD. DB2 automatically chunks the data if the statement is scrollable (either ResultSet.TYPE_SCROLL_INSENSITIVE or ResultSet.TYPE_SCROLL_SENSITIVE). Finally, note that normally a connection would be obtained from an application server's connection pool, but for the sake of producing an application that can be deployed easily, this example takes a shortcut. Lines 17-25 loop through the result set, populating a president object and writing it to the page in each pass. This is the crux of the streaming architecture: No more than a single row is kept in memory at once.
Another obvious problem is that he's "testing EJBs" by completely ignoring them. He uses Java 1.4, sure, but the bigger problem is that he's not actually using EJBs at all - he's fetching the data directly from the DB in the servlet, and his "local EJB" returns the data immediately while his "remote EJB" serializes it.
This isn't what EJB does.
This is a retarded "benchmark." A real benchmark might be useful, but it'd require actually figuring out what kind of EJB implementation would make sense on the backend, remote or local. This test is completely invalid, I'm afraid.
Everybody dies.
This test is not completely invalid! His "EJBs" will actually outperform real EJBs because they're doing less work. He's just illustrating a point in the interface design: an EJB is supposed to have a coarse-grained interface, so it returns all the presidents as an array in a single call. His benchmark demonstrates how such a design can cause memory problems.
The real flaw in his benchmark is that he didn't publish the heap size he's using. We run JVMs with 1.7G heaps around here, and I'll bet his benchmark would able to hold a lot of those arrays with a heap that large, so much that I bet he would saturate his I/O before hitting an OutOfMemoryError.
The streaming design obviously uses less memory, but the design constraints it imposes are not trivial. You would only code this way if you really needed the scalability.
After reviewing the comments, I realize I could have been clearer as to intent in the article. Unfortunately, most of the comments here miss the mark. Only sonofagunn "gets" the point.
The article compares two classes of algorithms with asymptotically different memory usage:, traditional store-and-forward approaches against a streaming architecture. It is similar to comparing quicksort with bubble sort and saying that one is an (n log n) algorithm while the other is n^2. The point of the practical example is to "prove" that the difference does indeed exist. The actual number mean little, it is their relative values that are of interest. Let me take a sampling of the comments here and try to respond:
> "A new DriverManager and a new db connection for every request? Welcome to 1998."
Not really relevant. The article mentions this was done for convenience, and the fact is that all three implementations aquire the JDBC connection in the same manner. Therefore, relative performance numbers will not be skewed.
> "Even though they return 1000 rows, 50 requests per minute is pretty poor. Voca processes 80 million bank payment per day using Spring [infoq.com]."
Completely irrelevant. This test platform was a core 2 duo with a bunch of other services running. Run it on a big beefed up server and you will get a much higher throughput. Again, the point is the comparison between the numbers obtained for each impl., not the absolute numbers, as sonofagunn pointed out.
> "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?
What is the point? an EJB call is like a method call+some container lookup overheads. If you were to use EJBs, it would slightly reduce the throughput numbers for the remote and local ejb impls., although it would remain asymptotically similar.
> 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."
I'm calling BS here. Claiming that architectural layers are added primarily to "create clean and easy to maintain design" is ludicrous. That can be one motivation, but not necessarily the only one, and definitely not always the dominant one: For example, in theory, J2EE's decoupling of the web and application tiers is primarily meant to improve scalability (though that rarely turns out to be the case).
> 3. Why wasn't Java 1.5 tested? By definition, Java 1.4 means that you're testing vs. EJB 2.x instead of EJB 3.x. I don't know what changes have been made between the two, as I haven't learned EJB, but I'm assuming there have been some changes between the two, for better or for worse.
I should have mentioned the testbed specs in more detail. This example was tested using Tomcat 5.x running Java 6, milestone 2, with default memory allocation for java.exe (128mb, I think, but I would have to check). However, you can run this test on WAS 3 and JDK 1.2 and you would receive similar results. You could up the memory to 8GB, and, with a high enough concurrency, you would see the EJB implementations fail and the streaming servlet continue to perform. Hell, you could switch to PHP, COBOL, ASM, Perl, or Ruby, and validate that a streaming architecture scales better than a store-and-forward approach.
As sonofagunn points out, streaming architectures are not rocket science, but EJBs preclude (you cannot stream between the application and web tiers using EJBs, AFAIK) their use and therefore, in the Java EE world, their potential utility is often overlooked.
The test is invalid. He's actually doing far MORE work with his "EJB" than a "real" EJB application would. I've written a version of his application, using actual EJBs and a decent architecture. The memory usage is nowhere near "worse" with the EJB version, because the container caches the entities. The scalability he illustrates is rubbish.
Everybody dies.
You may also want to try GlassFish. Updated version of the Java EE 5 SDK was released toady. It is free. Sun's Application Server (9.0 Update 1 Patch 1) based on Project Glassfish is included in the SDK. It contains a performance bugfix that enables record-breaking price/performance on the application tier with SPECjAppServer result of 521.42 JOPS@Standard - see Scott's latest blog for all the details.