I'm currently looking at a project, and a few different optimizations for a project. The problem with most of them is that they will help out when the server is under light load, making it even lighter. Think something like adding etags to your server, when the file isn't changing often you save bandwidth. As the server gets busier, the file will be changing even more often, possibly approaching a situation where it's changing every time the file is requested.
My concern with a possible etag implementation is that it changes my load vs. users graph from being a simple line with a given slope, to an arc. Likely peaking slightly higher (doing that work isn't free), but with a much higher slope towards the right hand side. To be honest I'd rather have a flat graph myself, as it makes it easier to predict when things are going to explode.
What would you pick? Am I just being lazy?
My concern with a possible etag implementation is that it changes my load vs. users graph from being a simple line with a given slope, to an arc. Likely peaking slightly higher (doing that work isn't free), but with a much higher slope towards the right hand side. To be honest I'd rather have a flat graph myself, as it makes it easier to predict when things are going to explode.
What would you pick? Am I just being lazy?
Comments »
No Trackbacks
"As the server gets busier, the file will be changing even more often"
Well, that isn't always true. in a lot of (or maybe the majority) of applications the number of files will increase rather than the update frequency of the files themselves.
So it depends on the application, but if files really change all the time, you're right that etags won't save you.
Well, that isn't always true. in a lot of (or maybe the majority) of applications the number of files will increase rather than the update frequency of the files themselves.
So it depends on the application, but if files really change all the time, you're right that etags won't save you.
Typically when you get ready to implement etags, you've already done many many optimizations to everything else.
Typically, the things PHP communicates with bottleneck MUCH faster before handle large volumes of HTTP requests. I've had a site recently that added grew exponentially over 3 months. While etags in theory would help, the ROI of implementing etags vs other options is pretty low. Optimizing your Queries, DB Schema, Indexes, or implementing better Memcached techniques typically yield a much higher ROI.
So while not dogging on etags, typically they are more for squeezing out more room for HTTP requests rather than major optimizations.
Typically, the things PHP communicates with bottleneck MUCH faster before handle large volumes of HTTP requests. I've had a site recently that added grew exponentially over 3 months. While etags in theory would help, the ROI of implementing etags vs other options is pretty low. Optimizing your Queries, DB Schema, Indexes, or implementing better Memcached techniques typically yield a much higher ROI.
So while not dogging on etags, typically they are more for squeezing out more room for HTTP requests rather than major optimizations.
It may not always be true, heck it may even only be rarely true. But in the case of the application I'm working on, it will be true.
IMHO, optimizations for a light load that won't help during a heavy load aren't worth the time it takes to do them.
Stick with what you've got and throw hardware at the problem.
IMHO, etc.
=C=