<snip>
> > I suspect that it is relatively small and, when you
> > introduce sophisticated state and caching options, it may be faster.
>
> Relative to what? To the web server dealing with it? I would suspect
> it's actually relatively BIG compared to that. I'm certainly willing to
> be proved wrong though.
</snip>
As we agree, we just need to get the data. I think there should be a
lot of standard testing out there that is more reliable than I am
probably going to do off the top. I will look around a bit and maybe
someone will chime in with some help here.
<snip>
> That might be true... one other point to remember though is that the
> more "unusual" things you do, the harder it will be to get people able
> to maintain it. I fight standards at work as much as the next guy just
> because creative people don't like standards forced on them, but clever
> solutions usual equal difficult to maintain solutions. I don't think
> I'm telling you something you don't know :) But, that's not my
> argument, so don't spend any time on it. Just another side track we
> could go down :)
</snip>
I am 100% in favor of keeping maintenance low. That was my original
primary objective going here. I could not believe how much time was
being spent on URLs, base tags, etc., etc., with all the concomittant
confusion throughout the development process.
<snip>
> > I think the bigger hit is reading the danged thing. This obviously is
> > especially so when there is an ongoing use of changing the JSP page.
> > This has no penalty with ProtocolPages.
</snip>
I just mean the more complicated parsing rules that go with JSP, as
well as everything else.
<snip>
> That's what I like, woman that are easy to please :) (You were left SO
> wide open there I just couldn't resist!)
</snip>
Heh, heh! Remind me never to fence with you, Frank. Actually, and
this is really off topic, in my milieu I am dearly loved because I
have really learned how to be a friend, husband, etc. This has been
the largest accomplishment by far in my life and the one I most
cherish.
<snip>
> * (Does the app server pass the response back to the web server to
> serve, or does it serve it directly to the client at that point? I'm
> actually not sure, but let's be optimistic and say the web server is out
> of the equation at this point, although I suspect that's NOT the case)
> In any case, images are returned to client<-
</snip>
I think that the ResourceAction class actually acts as the web server
and that is why the return is null. The class writes to the responses
output stream and that is all the server does, right?
FileInputStream fis = new FileInputStream(fileName);
BufferedInputStream bis = new BufferedInputStream(fis);
byte[] bytes = new byte[bis.available()];
OutputStream os = response.getOutputStream();
bis.read(bytes);
os.write(bytes);
os.flush();
os.close();
<snip>
> There is clearly more work done with the second chart because the app
> server is now involved. How costly is all that work?
</snip>
Again, I am not sure about this, and it is the sort of thing that one
typically makes mistakes about if one does not go by the data. So, I
am going to hold judgment on it, but my intuitions are not running in
the same direction as yours. I keep remembering how the following of
good OOP principles can make Java applications faster that C
applications doing the exact same thing, although most think that
would not be the case. Just the other day I was reading about a guy
who tried and failed to do some imaging work in early Java and had to
go to C. Now Java is faster in that area.
<snip>
> You could make the argument that because any servlet-based application
> is incurring those costs with most requests, what's the big deal about
> adding a few more? To a degree that would be a reasonable argument, but
> scalability is most certainly at risk because viewed from the point of
> view of the app server, a single page really corresponds to 10 app
> server requests.
</snip>
I think there are trade-offs that will need to be measured. For
example, I can envision with some of the stuff I do creating whole
pages dynamically with images. The new Java imaging stuff is really,
really, cool on this. Flash has its side too.
<snip>
> Even if it's all done in the most efficient way, those ten requests
> look, for all intents and purposes, like 10 simultaneous USERS (assuming
> 1 request per user). So, maybe your app server can handle 100
> concurrent requests... If the web server was allowed to serve the
> images, your app server still has 100 slots available to service
> requests, which corresponds generally to 100 concurrent users... If it's
> serving 10 images for each physical user though, now you can only
> service 10 concurrent users, so you've reduced your overall server
> capacity (as viewed by outside clients) by 90%. Ouch.
</snip>
Now just one moment, Bub! LOL ;-) You really are not seeing the
ways you can save time here. For example, there is such a thing as
caching, pragmas and expiry headers which can be set with a response
in a way that the meta tags just cannot handle. There will be savings
of creating no calls where pure HTML would be lost. There will be
other things like this too. Remember too that the ResourceAction
class is acting as a multithreaded alternative mini-server. Indeed,
the approach allows us to get the images, for example, from some other
server that is maximized to do just this. Conceivably that could be
quicker for cached images. Remember I said "conceivably". The
ability to be flexible can make for great rewards in efficiency and
fluidity that are not immediately obvious.
I don't say you are mistaken. I just think that this is going to be
an interesting little inquiry, if you want to chase it to its end,
which is my normal proclivity.
<snip>
> I fully acknowledge those are rough, worst-case numbers... I certainly
> don't mean to imply that your approach is 90% worse. Not at all! Just
> trying to illustrate the problem, as I see it, in certain environments.
</snip>
I understand. All your comments are quite fair, in my opinion. We'll
look around and learn a bit here.
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be
crows. We are poor . . . but we are free."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
