Originally Posted by Kalroth
Consider this, what's fastest; to transfer 1 100kb file or to transfer 100 1kb files? It's the former of course. So no, simple file requests don't put much strain on the server. Unless a lot of those requests fail and are re-requested. And this is exactly where XSLT transformation with synchronous JavaScript code is bad. An XSL file loads a included XSL file that loads javascript code that loads another XSL file that loads a file and fails. Now the file request in the bottom of the chain is broken, it's not responding and the javascript in the middle of the chain is using long timeouts. All of this might be happening while the browser itself tries to reload a image, because that also failed the first time.
|
On the other hand... What sort of resources do you need for your serving machine?
It may be that actually creating that 100kb page would be a nastier hit on the server?
After all, lets say my (imaginary) pvp alt Noobtastic wears an Armory concealment set on logout that is composed of all those items that get DE'ed from RFK, Mauradon, Gnomeran, and Black Temple.
The server might have to read each one of those, because they aren't cached, so this file/task that's slowly going from 0k ... 100k is sitting on server for 15s, waiting for all those data accesses to finish?
This almost sounds like your 50s timeout situation... but instead of doing it in our comp, it's done on the server. Which has 5000 other tasks building 100k records?
We may be better off having your computer sitting around 15s, waiting for the server to look up a 1k file holding the data it needs for that foo of blah item? Less task/memory lookdown and churn? That and things are easier to diagnose when you see the pant server is no longer serving pants, instead of just noticing the rate of serving characters has dropped 90%?
(I'm not denying that they can do better. I'm just wondering if there are places where one's intuition can go badly wrong when one finds out that we're dealing with larger sets of data)