Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Client/Server Architecture

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Client/Server Architecture

    Being a thug, I feel no obligation to play by your rules. Please define 'best', tell us why companies use computers, and should all business problems require an IT department to solve them?

  • #2
    Client/Server Architecture

    Being a thug, you don't play by any rules but your own. That's what makes you a thug. And although you're a thug, and an anonymous thug at that (the worst subcategory in my opinion), I'll answer your questions once, even though they have nothing to do with my article (this is another Thuggery Tactic: ask unrelated questions and then complain when they're not answered). Here are the answers: "Better than any other", "to speed the processing of data into information", "no". And since you missed my point, I'll restate it: a message-based client/server architecture using RPG as the controller and server communicating with a JSP front end is the best architecture for web-based iSeries applications. If you don't need web-based iSeries applications, then feel free to ignore the statement. Otherwise, feel free to challenge it. However, use facts and stay on topic. Thugs, especially anonymous ones, should not be surprised if their statements are simply ignored. Joe

    Comment


    • #3
      Client/Server Architecture

      Joe Pluta wrote: Facts tend to shut up the Thugs quicker than anything. My experience is quite the opposite. I have found that the technical purchasing and direction decisions made by non-technical execs are like stating "Damn the Facts, , , , ,Full speed wherever!" And it would appear that most technical purchasing and direction decisions are being made by non-technical execs. Been there and done that so many times, I've worn out the T-Shirt. Dave

      Comment


      • #4
        Client/Server Architecture

        This article refers several times to the SQL-vs-native performance "benchmarking" that Joe has available on his site, and holds it up as an example of how to fight thuggery. Sadly, however, that benchmarking is so immature that its results are severely misleading. The tables have no primary key, and are accessed by RRN, something that is outside the conceptual framework of SQL. Also, no statistics are given about the standard deviation of test runs, so it's impossible to tell if there's simply a higher "one time activation cost" of one method over the other, or if variations are consistent. Finally, the tests are so simplistic that they're too far removed from real applications to have any meaning. A meaningful benchmark needs to test the performance of a meaningful task. For example, "find the 10 customers with the most open orders", or "for each manager, find the average salary of each job title that reports to them". Sample tables should be defined in third or 4th normal form, etc, etc. Now, Joe, you know your benchmarks are a long ways from perfect. In fact, they barely scratch the surface. Your knowledge of this is reflected in the fact that your benchmark is release 0.2. So don't you think presenting potentially misleading information as gospel is disingenuous, if not the kind of out-in-out thuggery you claim to be fighting?

        Comment


        • #5
          Client/Server Architecture

          I have said over and over again that my benchmarks are not perfect. However, that's about all that I agree with in your post. First, I emphatically disagree with your assumption that benchmarks must "do some meaningful work" to be valid. Untrue. While workload-related benchmarks such as the SAP benchmark are certainly a more well-rounded measure, the fact that JDBC is 50 times slower than native RPG I/O for simple fetches is hardly meaningless. My tests provide raw data that can be used for analysis. Second, you cite my benchmarks as immature. Perhaps, but such derogatory language is uncalled for and, given the nature of the site, not a little ironic. Did you read the posts on the site, wherein I call for others to make the benchmarks better? That's why I made the site open source. You don't like them? Feel free to write additional tests to test your assumptions. Rather than complain, which is easy to do and helps no one, I challenge you to instead put in even one tenth the work I have. I have already written the frameworks, put up the website, developed the tests and made the entire thing open source. All you have to supply is your wisdom in the form of more "mature" benchmarks. Third, you say my results are misleading. J'accuse! Name one result I got which is misleading, and how and why it misleads. Be warned that I'll ask you to back up your statement with FACTS, meaning a benchmark that proves your point. Finally, you state that my programs use RRN. Not true, or at best only partially true. The files are keyed, the access for FETCH tests is by CHAIN and WHERE clause. I do read sequentially for update tests, but I do that with both: I read through a result set or I read sequentially through a file. And of course, the concept of "RRN" access is meaningless on writes, where SQL and JDBC both perform miserably. So, let's get back to it. You basically complained that my tests are immature and misleading, and I challenge you to back your opinion up with facts. Here are mine: FACT: SQL is much slower than native I/O for any non-set based functions. Sometimes as much as ten times slower. FACT: JDBC is even slower, by another factor of five, for nearly every operation. CHALLENGE: Prove me wrong. Submit some tests to the site. It would probably take you less time to write a test program than to respond to this post. So don't sit here and complain, write some tests to test your hypothesis and add something to the community. Joe

          Comment


          • #6
            Client/Server Architecture

            Joe, I thought you were a proponent of JSP Model II -- using a Java servlet as the controller, not RPG. Or, in your article, is the form action of the JSP just a servlet which simply passes control to an RPG controller program? Chris

            Comment


            • #7
              Client/Server Architecture

              JSP Model II is a somewhat overused term. People call Struts JSP Model II, when it really isn't. Others insist that JSP Model II must be 100% pure Java, even going so far as to require EJB. Me, I like to use a MVC architecture in which the servlet proxy is a thin facade over an RPG controller. This puts all my business logic - database and application - in RPG, where I like it. The servlet is primarily used to pass data back and forth between the JSP view and the RPG controller (although as your design evolves, you can add some simple validations on the servlet side, as well as providing helper methods to the JSP for UI formatting). That doesn't mean it's impossible to design 100% Pure Java solutions. There, the controller and database logic is in Java. And for relatively simple applications, it's really not a terrible solution. It's just that the code complexity goes up exponentially as your business rules get more complicated. Joe

              Comment


              • #8
                Client/Server Architecture

                Joe, Actually, I was referring to the JSP Model II definition in your JavaServer Faces article. I knew you must be using a servlet somehow because I know you don't use CGI (calling an RPG program directly from JSP). Regards, Chris

                Comment


                • #9
                  Client/Server Architecture

                  It looks like I have one apology to make, but it won't change my overall stance much. I'm sorry for representing your select performance test as being based off of relative record number. It wasn't intentional slander, but rather a misunderstanding I had after reading one of the posts on your website a few months back. I did start to try to verify the claim yesterday, but unfortunately the package download took longer than my patience lasted. I've subsequently loaded your test suite, and have verified that in fact, it does compare keyed chain versus fetch performance. We'll have to agree to disagree on the relevance of comparing simple i/o operations, however. Your agreement that workload-centric tests such as the SAP benchmark, or one of the TPC benchmarks, are more well-rounded satisfies my primary concern. Perhaps in the future, you could qualify your performance claims so that the scope of your claim is more clear. Also, I would encourage you to write one of the workload-centric tests in native I/O, to see if you could make a less qualified assertion. The article, as it stands, with its unqualified assertions, is misleading. As far as your challenge goes, it should be clear that I'm only interested in benchmarks that model a real-world workload. If your intent is to benchmark something else, then you wouldn't be interested in any contributions that I might make. And if you want it to grow into a real-world test, then it would be best to base it off of an existing model. The onus is on the person with something to prove, and since the rest of the benchmarking world uses SQL, that person is you. Finally, please note that all of my comments are regarding the SQL vs native claims. The rest of the article is very good, and I wish you the best of luck in bringing some performance numbers to the "best web methodology" argument. I hope this hasn't been too much of a side-show from the main point of the article. -Ken PS: Just for grins, I went ahead and ran the test suite as you have it. Without endorsing the testsuite, I thought I'd share the results. On the box I tested on (1.75 physical/2 virtual CPU LPAR on a 840 running v5r2, latest cum level), after 10 test runs, the multitable fetch (SQL) tests averaged about 5.5 sec each, whereas the chain (native) version, took about 2 seconds. Also, the single table fetch tests took 3-4 seconds, while the native chain test averaged 9 seconds. The different runs varried widely, however. I still believe strongly that if this benchmark is to be used, some sort of normalized average should be used instead of a straight average. For instance, the native chain test ended up with a 83 second result in one of my tests, which was obviously bogus & should have been thrown out. NOTE: The SQL used to calculate times in the test suite is buggy! When you subract timestamp fields in SQL, the result is _NOT_ seconds, it's an interval! The result is numeric, but it's encoded to have the minutes in the 3rd decimal precision, hours in the 5th decimal precision, etc. So, for example, if two timestamps are a minute apart, the difference is 100, not 60. See the following article for details on how to compensate for this article

                  Comment


                  • #10
                    Client/Server Architecture

                    I'm going to try to avoid propagating the confrontational tone of your posts. Just so we're clear: I don't have anything to prove. I am not on some sort of anti-SQL vendetta; as you can see, my tests already encompass RPG, Java, JDBC and SQL. I plan to add tests comparing program calls to procedure calls and data queues to sockets. The fact that SQL performs like a dead yak is not my fault, nor is it my goal to prove that. So, no, Ken, there is no onus on me. I am presenting my findings, and if you disagree with them, the onus is on YOU to provide alternate facts. Argue all you want, but until you provide alternate tests, my results stand. And if the "rest of the benchmarking world" uses SQL, then it doesn't include the hundreds of thousands of iSeries shops running native RPG and COBOL applications. And if it doesn't, then they're really not that germane to this forum, are they? I'm sorry for the slow download. Feel free to donate a T1 line for your downloading convenience . Just to be clear, it's my belief that SQL is okay for queries, especially mutli-file queries with ad hoc ordering and selection. I hate it for single-record fetch and especially for transactionla update. I notice you didn't share your results on the INSERTs or UPDATEs, and my guess is they performed as poorly on your machine as they did on mine. Thanks for the update on SQL date math. I would NEVER have guessed that. What an atrocity. Anyway, it should be noted that the problem only occurs when a test runs over a minute, and the vast majority of the tests did not. It will, however, skew results for the poorer performers. So, yes, it's BUGGY! But the bug affects nearly none of the results. You might want to clarify that sort of remark, especially when you use EXCLAMATION POINTS AND CAPITAL LETTERS! Joe

                    Comment


                    • #11
                      Client/Server Architecture

                      The important concept of JSP Model II is not the language of the controller or the servers, but instead the fact that beans are loaded by something other than the JSP, and that which JSP is displayed next depends on the controller, rather than the current JSP. In JSP Model I, each JSP determines the next JSP to display, while in JSP Model I.5, there's a configuration file that identifies the program flow. The language implementation of the controller and servers is really a matter of choice. In my article, I think I implied a 100% Pure Java implemenation, but there's a spectrum from pure Java to almost no Java. I think this is important, because this very-thin-servlet approach can be implemented by shops with very little in-house Java expertise. In fact, if you've created the base classes correctly, they can be managed by simple .ini files or XML configuration files, with no Java programming whatsoever except for what is needed to modify the JSPs. Joe

                      Comment


                      • #12
                        Client/Server Architecture

                        Joe, thanks for overlooking the confrontational nature of my posts, just as I've overlooked the confrontational nature of your article, and of your second reply. However, you have apparently intentionally overlooked some of my FACTS (I assume from your earlier response that FACT is an acceptable word to capitalize). As I indicated in my last post, using your test suite I came up with the result that single file native chains are significantly slower than "select into". In fact, the initial numbers were that "chain" was about 5 times slower than "select into". Using your standards for scientific integrity, I should be screaming up and down right about now how chain performs like "a dead yak". But I'm not, because the result defies common sense. Instead, I looked into the cause for about 5 minutes & saw two things that accounted for the non-sensible result. The use of erroneous timestamp math accounted for 4 of the 10 second gap. Not throwing out the bogus high & low runtimes accounted for another 7 seconds. In other words, once I improved the reporting to not contain these problems, the chain was shown to perform slightly better then "select into" (under the supplied test conditions). I suggested in my first post that you include standard deviation when reporting your test summaries, and I hinted in my second post that you throw out the best & worst times. Since you ignored me the first two times, I'm saying it again now: a straight average is a misleading number without standard deviation. In addition to the two improvements I suggested above, I propose that you also check to see to what degree the following variables have on the reported performance: number of test iterations per run, use of the "optimize of n rows" clause, the number of fields returned (including a test that allows use of a perfect index), program object size, the use of primary keys, the size of the tables being accessed, the use of journaling, and the use of commitment control. So, now, even though I don't believe in the value of what you're doing, I've suggested improvements in each of my three posts. You ignored me the first two times.. if you ignore me a third time, I'm going to have to assume that you're just trolling. PS: Thanks clearing up the fact that you're not on some "sort of anti-SQL vendetta", just that you "hate it" sometimes.

                        Comment


                        • #13
                          Client/Server Architecture

                          Ken, you miss my primary point. You seem to think I am asking people for input on how I should write the tests. That's not correct. These tests are open source. If you don't like the tests or the calculations of the results, provide some better tests of your own. Don't expect me to write programs that explore every nuance; I've said over and over that I'm not a good enough SQL programmer to do that. That's why I have explicitly asked that rather than complain about the tests, people provide better ones. I'm looking forward to your contributions on the website. If, on the other hand, you refuse to contribute because you don't believe in the value of what I'm doing, then your complaints are pretty much a waste of time, don't you think? They are then in fact the sort of argument that I address in the article: "You didn't do THIS and THIS, so your results are invalid." Pshaw. At least I took the time to do something concrete; feel free to either expand on it or ignore it, but further criticism is counter-productive. Joe

                          Comment


                          • #14
                            Client/Server Architecture

                            kskuhlman: The way you are approaching and evaluating your tests sounds like the way I was taught. I think it'd be great if you'd take Joe up on his offer and work on some better benchmarks. Then other people can see what you've done and maybe improve on it, just like you can improve on Joe's. I especially agree with your comments on standard deviation. On Joe's behalf, he has consistantly said this was just a beginning. And he made it open source. So he's WELL within his right to respond to criticisms with "put-up-or-shut-up" since he's made it so easy for ANYONE to "put-up". -dan

                            Comment


                            • #15
                              Client/Server Architecture

                              Hi Joe, I hope you don't mind me asking more questions about your design. I'm intrigued by it. I read your redeployment book a few years ago and I don't recall you using RPG as the controller, but you may have. Is there a one-to-one relationship between a JSP and the servlet? Or can many JSPs (different forms) point to one servlet? Does the servlet retrieve the form parms and forward those to the RPG progam? How do you manage the parms to the RPG program if one servlet can handle many JSPs (many "screens" of unalike form data)? Do you have a hidden field in the form to tell the servlet which screen it needs to process? Do you use ProgramCall or call the RPG pgm as a stored procedured? If ProgramCall, do you use PCML to automatically convert from UNICODE to EBCDIC and back? Thanks! I certainly appreciate your presence in these forums. Chris

                              Comment

                              Working...
                              X