Dakota Jack wrote:
What I was getting at is the fact that if I return a page to the browser that have ten images, all referencing ResourceAction, what's happening is that the browser is making ten separate requests TO THE APP SERVER, whereas in a "typical" setup, these requests would be handled by the fronting web servers. It's clearly more resource-intensive in your approach.
</snip>
I am not clear what part of the process you are referring to, Frank. We both agree that the first delivery of the page is via the "front
server" (I tend to only use the "back server" anyway).
I wasn't clear on that part I guess, but it doesn't change my argument. I guess your saying the pages aren't even JSPs, which is fine. Doesn't really change anything though except that there's no servlet involvement to serve the initial page, which is slightly better. That's cool...
If there are
ten calls to ten images, as you assume for discussion purposes, then
there will be ten calls either way.
That's correct. Just basic HTTP here :)
> I think you are saying that in
addition there will be a penalty of a pass to a server that can handle Servlets or an equivalent technology that will respond to the ProtocolPage by routing the call to some Action, Command, or whatever in some language, in the way I suggest. Is that right? If so, let me know and we will go from there after you confirm.
That's it exactly. The web server has to forward the .do request to the app server, which then serves the images, 10 total servlet invocations in all. Yes, there would be ten requests either way, but one assumes that the web server can serve static content more efficiently than any Action you can devise. Perfectly logical argument, ceteris paribus (I love using Greek in real conversations!), because that's exactly what web servers are optimized to do.
I wouild need, as you would too I assume, more information on the
actual penalty.
Absolutely. The only assumption I'm making is that there IS a penalty. There are any number of factors that would go into how big or small it is, whether it's enough to outweigh the benefits of the approach. I make no attempt here to reach any conclusion on the magnitude of the problem, if it is a problem at all.
> 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.
I don't dismiss what you are saying. Don't get me wrong. I just have
learned to get the data and then to see what the real difference is.
And I would agree that's the right frame of mind in all things :) It may in fact be such a small penalty that it's worth ignoring. I have a suspicion it's not, but without empirical data, it's just a hypothesis.
When considering costs and so on, I am not sure whether the balance goes to which side. I would suspect, from my experience, that software maintenance and so on would clearly outweigh the hardware and associated requirements.
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 :)
I am surprised at this. You may be right, but my sense is that this difference is not really that important when everything else is taken into account. Even if you had to cluster multiple machines instead of one, say, as a ratio, that would seem to be *probably* cheaper as a GUESS. I don't know. We could look at some data and if you have any handy I would love to see it.
I don't have any handy, but I agree, some real data here would be better than us bantering back and forth for the next week :) I suppose the simplest thing to do is set up a test where you serve 10 static images from a web server vs. 10 images from your ResourceAction with a web server in front of the app server and see what the overall response time is. It would be a little rough, but at least we could tell if there is a perceivable difference or not.
Then we get into whether thousands of imperceivable hits accumulate enough over time to hurt us. That's obviously far trickier to guage, but that's the kind of things us enterprise architects have to bother about. :)
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.
Not following... reading from where?
Well, I bet you are being too humble. I am happy to say that my wife just thinks I am the most adorable, wonderful, guy. Go figure, eh?
That's what I like, woman that are easy to please :) (You were left SO wide open there I just couldn't resist!)
> Technology seems to get ahead of rumor in our little world of web
work. So, I definitely would like to revisit this. I am going to squeeze getting the *facts* in here soon.
I look forward to your test results :)
This seems to be false to me. Maybe I misunderstand you. I don't think the browser has a clue whether we are looking at src='myCss.css' or src='resource.do?file=myCss.css'. Right? Jack
That's right, the browser doesn't know the difference, but the "server side" does, and I put that in quotes because it's a little tricker in this discussion to define it.
Here's a typical sequence chart, simplified a bit:
* Browser requests page from web server-> * Web server returns HTML page<- * Browser parses page and constructs list of resources to retrieve... * Each image is requested from web server (in parallel, one hopes!)-> * Web server returns images, in many cases from a memory cache<- * Browser renders page.
Nothing unusual there. So you have 11 total round-trips to the "server", one for the document, 10 for the images... It might be the same HTTP connection, but that's not definite (in fact I think it's definitely NOT the case, HTTP being stateless and all, but there could be something I don't know there at a very low level), and ultimately not relevant to this discussion anyway because it's still 11 requests, whether the actual connection is torn down between them and rebuilt anew for each or not.
Now, let's see what happens using ResourceAction, and I'll take the simpler case of the page being straight HTML and not a JSP...
* Browser requests page from web server...
* Web server returns HTML page<-
* Browser parses page and constructs list of resources to retrieve...
* Each image is requested from web server->
* Web server recognizes .do and passes the request on to app server->
* App server performs whatever functions it needs to in order to fulfill the request (in this case we're talking the whole litany of Struts functionality, including your Action of course)<-
* (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<-
* Browser renders page.
There is clearly more work done with the second chart because the app server is now involved. How costly is all that work?
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.
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.
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.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
