Hi Ayudh,

not wanting to start a huge debate but a stream of fallacy should not be left 
as the final word in an 'informative' discourse.

now: #1 If DNS is not an issue why does adding a server to the HOSTS file 
dramatically increase the performance on the majority of requests? There are a 
number of reasons why this may still be a DNS issue, and in a properly 
configured setup this shouldn't occur, true, but this is trying to find an 
answer to a problem not describing the ideal situation.  It could be an issue 
of external vs. internal DNS, incorrect information from DHCP etc.  I would 
also guess that the server in question is not a windows machine and your 
ipconfig command will not work.

On a side note the TCP/IP layer does not cache anything. at all.  The resolver 
might.

#2 No matter how you spin it it cannot be better to make the client responsible 
for assembling the pages in this fashion.  The entire content of the page will 
be greater as a result of your having rewritten half a Fscking web browser in 
JavaScript, not to mention the reliablilty issues (say the php server is 
contacted okay and the coldfusion server is not?)  The major issue here is 
latency, the more requests, the longer you have to wait and you have an entire 
propagation delay between requests.  Remember this is not concurrently (The 
misconception that having 1 image cut into many smaller ones is faster is 
because it seems that way as your browser opens multiple connections meaning 
you see parts of many images formed sooner rather than just a few lines at the 
top of a large image)
In the case of this client side system proposed you have to wait until the page 
is loaded BEFORE the javascript can run.

#3 Waiting until it 'gets here' is exactly the problem.  No, I think fixing the 
existing system so that we don't have the delay would solve the issue.

I think Ben Smith was spot on; if you are going to start recoding stuff I would 
be looking at doing the client display in PHP. (leave the content management in 
CF if you like)

Sorry, bad day of looking at bad code and would hate to see it propagate.

Regards,

James



-----Original Message-----
From:   Ayudh Nagara [mailto:[EMAIL PROTECTED]
Sent:   Tue 1/02/2005 5:58 PM
To:     CFAussie Mailing List
Cc:     
Subject:        [cfaussie] Re: PHP & CF

        
Okay, okay, not wanting to get into a big debate here - it was just a 
suggestion based on things we've done quite successfully, but just to point out 
a few facts...

> #1 it is quite likely that the DNS caching IS an issue, as who knows how PHP 
> handles the
> DNS. (hence this is why it improved dramatically when the host was defined in 
> the hosts
> file on the PHP server.)

Actually, the TCP/IP layer does the caching of IP addresses, not the 
application layer. That's one of the reasons the entire Internet is as scalable 
as it is. If every time someone makes a request, it has to revisit the DNS, the 
whole thing would not be sustainable. Wanna see what hosts your computer is 
currently caching? Just type ipconfig /displaydns into the command prompt.

> #2 Moving processing in the client is going to slow things down 
> dramatically... you
> have (probably) 100Mbits between the 2 servers and what to the client 
> exactly? 100k at
> best?  You're doubling the number of requests on the slower link, effectively 
> doubling
> your data transfer costs.

Think again. No matter what you do, you still basically have to move the same 
amount of content down the narrow pipe to the user. Having a fat pipe between 
the two servers is fine, but you still eventually have to get it down to the 
user. Spreading out the load into 2 separate http requests may in some cases be 
better (same reason why it's better to break up a large image into multiple 
fragments).

#3 CPU load for including data is not that great.
That is true, provided the included content is at hand. Otherwise we wait till 
it gets here.

Regards: Ayudh

+----------------------------------------------------------------+
| SOAP is the glue! Hook up your server directly to your bank.   |
| Connect to VeriPay xServ, the Australian Payments Web Service. |
| Reliable, Secure, FAST: http://www.xilo.com/xserv              |
+----------------------------------------------------------------+

        

---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/


<<winmail.dat>>

---
You are currently subscribed to cfaussie as: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]

Aussie Macromedia Developers: http://lists.daemon.com.au/

Reply via email to