|
|
Posted by Jerry Stuckle on 11/11/06 03:02
Michael Fesser wrote:
> .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 when you get shut down for overusing the CPU, don't come crying to me.
>
>>>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.
>
Yes and no. The redirection is initiated server-side. There is very
little overhead doing this. Then the client requests the new page.
>
>>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 why is that? It's much cheaper than needlessly parsing even a
single 2K html file.
>
>>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.
>
If you program like you indicate, your servers are doing a lot more work
than necessary. But that's OK. You aren't dealing with any serious
sites - just Mom and Pop outfits. So it really doesn't matter to them.
They don't know the difference anyway.
>
>>>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.
>
And pray tell how are you going to do that without parsing every single
file for php (and possibly other languages)?
Face it - for files, the file extension IS meaningful to Apache, IIS and
any other webserver on the market.
>
>>>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, and if you check, that's normally the index.html or index.php file
in a directory. IOW the server is picking up the default page for that
directory.
>
>>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.
>
So? If that's a problem on your site, just use JPEG in the first place.
Then you don't even need to worry about the negotiation.
>
>>>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.
>
Not at all. 301 redirects allow the most efficient way to be just as
flexible when necessary.
>
>>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
No, YOU AREN'T. But that is NOT TRUE of the entire internet. And not
true of some of the other programmers here.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|