|
|
Posted by Michael Fesser on 11/11/06 01:16
..oO(Jerry Stuckle)
>Michael Fesser wrote:
>>
>> Who cares? That's what a server is for. You won't be able to notice a
>> difference in time between a plain HTML file delivered as-is and another
>> HTML file, parsed by PHP. Even with PHP-(Fast)CGI the difference is too
>> small. The transfer over the network takes much more time.
>>
>Your hosting company, for one, unless you're on a dedicated server.
>You're needlessly taking cpu cycles away from other sites on the server.
No. I just use what I pay for. My scripts are limited to a certain
amount of memory and CPU time. Being able to use these resources is part
of my contract with the hoster. If it would affect other sites on the
same machine it would be a violation of the contract.
>> And BTW: Unnecessary 301 redirects are no overhead? Not much for the
>> server, but for all the clients and the network.
>>
>Very little compared to unnecessarily parsing .html files.
No. Parsing files is done on the server side, a redirection is handled
client-side. So you're just moving all the work from the server to your
clients. Every access to the old resource wastes network resources.
>mod_redirect
>is quite short and quick in its operation - especially if the redirect
>is in the httpd.conf file. But even in .htaccess it's quite fast.
Using mod_rewrite while trying to spare some CPU cycles is ... strange.
>And it's just plain sloppy programming or laziness to force it to do
>more than is called for in a case like this.
My servers don't do more work than necessary. They simply do what is
needed to satisfy my clients.
>> A 'php' in the URL is technical stuff that doesn't belong there. A URL
>> describes a resource, not details about the way it is generated.
>
>That may be your opinion. The extension just allows the server to do
>the most efficient processing of the file. You could call it .xyz for
>all I care - just set up the correct file type in Apache.
Sure, but there's still no need to show it in the URL.
>> Exactly. Reliable, long-living (in other words: "cool") URLs don't need
>> an extension, simply because it avoids a lot of problems.
>
>Then your definition of "cool" varies from almost all of the rest of the
>world. How many sites do you see with no extensions, for instance
>(other than your own, of course).
Nearly every big company uses URLs like <http://example.com/coolThing>,
even if it's often just used for redirecting the user to another page
inside a CMS. But it's a beginning.
>Yep, it describes a resource. One of the types of resource it describes
>is a file. And when it's referring to a file on a server, the extension
>is important. Not only .php, but things like .gif, .png, and others
>come to mind.
In this context omitting the extension provides another nice benefit. We
all know that IE has its problems with alpha transparency in PNGs. Using
server-side content negotiation you can easily deliver a fallback-JPEG
to IE and an alpha-PNG to real browsers - with the same URL. No need for
client-side hacks or switches, just let the server decide which is the
most appropriate variant to send back to the client.
>> You only need an extension if you directly map a URL onto the server's
>> filesystem. That's the most common, but not the only way. Of course on
>> the server the files still have their extension, but there's no need to
>> show it in a URL.
>
>No, it's not the *only* way. But it's the most common - AND THE MOST
>EFFICIENT.
Others are much more flexible.
>And expecting the server to do your work for you is just plan lazy.
>Sorry if it offends you - but that's how I see it.
>
>Now - one other thing. You may get by with this on a site with 20 pages
>and 1K hits/day. But try sites with 10K+ pages, and over 1M hits/hr.
>
>There is a huge difference in the processing time required.
We are not talking about high-traffic sites here. On such a beast there
are many other toys available for use - load balancers, local proxies,
bytecode caches etc. Even your highly optimized server could not handle
such a site on its own.
Micha
Navigation:
[Reply to this message]
|