|
Nathan - where does "small amount of data" become "apparently no database access" and "assume in-line..."? I have a screen for parts inquiry - key in part# - press enter - I do database access, return part description & price. Not much data. IBM built a comparison between the different methods with a very simple application. Since what is being compared has more to do with executing various program methods & not data access, why not a simple app. A second comparison involving large volume of data would be nice, but I think belongs in a separate table. As we have seen in recent posts about high volume web serving that would require a book to properly detail all the various bottlenecks to good performance. IBM did a redbook on this a few years ago, but is out of date now.(Still an interesting read). imho jim franz ----- Original Message ----- From: "Nathan M. Andelin" <nandelin@relational-data.com> To: <midrange-l@midrange.com> Sent: Wednesday, October 03, 2001 10:48 AM Subject: Re: CGIDEV2 performance versus Net.Data > > The iSeries Performance Capabilities > > Reference Version 5, Release 1, > > http://publib.boulder.ibm.com/pubs/pdfs/as400/V4R5PDF/as4ppcp4.pdf, > > has a table on page 99 that shows number of transaction > > per second per CPW on the Apache server. In the non-SSL > > case, servlets: .46; CGI named activation group .29; CGI > > new activation group .06.; Net.Data 0.19. > > Quote from page 102: "The data in the Table 6.1 assumes that a small amount > of data is being served (say 100 > bytes)." > > How relevant are these benchmarks? 100 bytes? Apparently no database > access? Apparently the response is produced entirely from in-line output > statements? > > Properly structured Java applications normally involve a Servlet, a Java > Bean, and a JSP, and frequently a Session, to produce a response. > > Most Net.Data macros evoke calls to the SQL language environment. > > The referenced comparisons seem to be almost completely divorced from > real-life. > > > Nathan M. Andelin > www.relational-data.com > > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.