RE: 520 pricing structure -- WEB400

> From: Brad Stone
>
> Impossible.  MI.  Keep using outrageous terms and
> comparisons to prove your point, Joe.

I insist that except for the mot trivial of applications, straight CGI
with no templates is impossible to maintain in a production shop.  Do
you disagree?


> Let's just say the difference was negligable.  I'd be happy
> to run them again.  Just let me know what other specifics
> you'd like besides 100% load before I do it.

That's it.  Just make sure you're testing the actual code that generates
HTML, not the HTTP transmission or any other part of it.  Just one piece
at a time.


> But that's "only" startup... nothing else...  I mean,
> switching from page to page in the admin server taking 2
> minutes... that's negligable.

What does the admin server have to do with this conversation, Brad?  The
admin server is using crazy stuff like EJBs.  I've seen some really bad
RPG-CGI sites, too.


> Ok..  let's make this simple.  Hits do mean something
> because App A may take 2 seconds, and app B may take 10
> (500 hits).  If you have a busy site, I know I'd rather
> take app A because I don't want my CPUs eaten up.

The typical overhead on "hits" has little to do with the UI.  Usually
the most time is spent in transmission, followed by the time spent in
database access.  Actual UI formatting is usually only a small portion
of the entire job.  That's why measuring the performance of UI
processing as a function of hits is roughly equivalent to measuring the
performance of two hammers as the function of putting up a high-rise
apartment.

If you want to do an architectural benchmark, focus on a specific
portion of the cycle.  Otherwise, you're just doing an application
benchmark, and then you need to have something other than a trivial
application to measure.


> > The overhead from a JVM is almost entirely at startup
> > time.  Said
> > overhead becomes negligible after a servlet is loaded,
> > and actually
> > becomes less as the UI (the JSP) gets compiled to machine
> > code.
> > Eventually the servlet will outperform the RPG.
> >
> 
> Bullsh*t.  Even you know that (but I'm sure we'll hear
> differently).  Especially for each job that starts to
> handle more jobs... which means another JVM startup.

Wow.  No wonder you can't get servlets to perform.  You don't understand
how they work.  A single JVM handles all the requests from an instance
through multithreading.  No extra jobs get started up.


> You first say they're close in performance (JSPs being a
> little behind), then that a servlet (I thought we were
> talking JSPs) will outperform...

Again, I'm taken aback at how little you know about the topic.  JSPs ARE
servlets, Brad.  A JSP is converted into a servlet.  The servlet is
compiled into bytecode.  Finally, the bytecode is compiled into native
code by the JIT compiler.

This is one of the reasons that JSPs start out a little behind CGI, then
begin to catch up and eventually surpass them.  The other reason is the
superior multi-threading capabilities of Java over RPG, which is very
important in high-volume UI processing.


> So, memory is slow (template storage), but JVM and Data
> Queues are not.  Nice condradiction.

I said that data queues are additional overhead, but that the OS/400 is
highly optimized for data queue handling.  Nothing contradictory about
it.


> No, the point is I don't need to.  Only those network
> admins that fell it's necessary or want something to do
> NEED to do it.

If you want to put your iSeries in the DMZ, that's your business.  Some
people won't want to.  And with RPG-CGI, that's impossible.


> Ya, dude... like I really seriously meant Dell is what you
> wanted to buy.  Get real, man.  Quit arguing crap like this
> to try and prove a point.  Your "screaming" linux box is no
> more powerful than a $500 Dell.  I've built and bought
> quite a few PCs... and these days you don't save much
> building over buying...

I have no idea what the point of this paragraph is.  You brought up
Dell, not me.  I simply said that a $500 FreeBSD box is quite powerful.
I think you need to take a little breather and answer the questions
posed.  For example, what load level do you think that $500 box could
not handle?


> > > I would be happy to name my procedures the same as
> > CGIDEV2
> > > or others, but there are subtle differences in my
> > > procedures and how they function with the product.
> >
> > Thank you for making my point more clearly than even I
> > could have.
> 
> Your sarcastic statement here proves nothing.

It proves that if I use CGIDEV2, I have to learn something different to
use e-RPG, and something yet again different to use Bob's package.  And,
unlike JSP and Java, none of them are being taught in any school on the
planet.


> So that would mean that because I don't need to access DB's
> natively in JSPs/Java but I may want to, it's a flaw in
> that architecture?

Actually, yes, a flaw in a pure JSP architecture is that you cannot
access data natively.  That's why I believe the very best architecture
is JSP for UI and RPG for business logic.


> Ya, and we RPGers are still not flipping burgers.  Again,
> your comparison here has nothing to do with the facts at
> hand... it's all opinion.  Calling RPG a dumb tube and JSP
> a PC means nothing to anyone except those who can't think
> for themselves.  It also doesn't prove your point.

You say "we RPGers" as if I'm not one.  That's almost fanatical... those
who don't agree with you must be the enemy.  But that dog don't hunt
here, Brad.  I continue to say that RPG is the best business rules
processing language available.  It's just one of the worst possible
languages for HTML processing.  I don't compare RPG to a dumb tube.  I
compare RPG-CGI to a dumb tube.

You can't turn this into Joe vs. RPG; I love RPG.  I just think that
RPG-CGI is a bad architecture and a dead end from a strategic
standpoint.  There are a certain small number of companies for whom
RPG-CGI makes good business sense despite those shortcomings, but it
will always be an architecturally deficient solution.

Joe