Comment Clarifying several points (Score 2, Informative) 40
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 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.
