I have somewhat lower requirements, so my options are a) tarballs copied somewhere on another server and b) a SATA DDS3/4/72 drive and some $8 DDS tables. One tape is quite sufficient to my needs, and backup tapes are a lot sturdier than hard disks.
That's why most RDBMSes have some level of support for generating live snapshots and keeping them stable for a while. Get a DB backup at midnight and replicate rewrite logs somewhere else and you'll lose very little data when someone thermites your server.
Yeah, and a browser isn't necessarily going to benefit from them. Being MS, I would hazard that the main reason IE7 doesn't support win2k is that MS wants to push people towards XP/vista.
What's interesting is that the $80k damages figure was basically the entire cost of production, and assumed that he took the only copy for himself. That takes balls...
this is an emergency - why are you planning to run dryers off the generator? If your power dies, you can stop laundry service or hang dry inside; seriously, all you need is lights, heat, fridge, and some left over for electronics.
No, I was discussing that whole premature optimization aphorism, which you distorted in order to claim that it was faulty. I'm sorry your code has a crappy design - that's what prototypes, iteration, and capacity planning are for, to show you what your design needs to do before you spend too much time on in.
You can't optimize something until it's been built. If you address performance requirements before building, that's called design. I think you're confused about what optimization actually is.
You have to consider that the author is writing for his particular niche - server-hosted apps written by US devs. He's also saying that throwing hardware at a problem is often the most cost effective solution. I don't see why people take issue with that.
I have forced air (spit!), so if I grab a bunch to play with clustering solutions, it's a wash. I'd do heat pump or gas, but it's an apartment/condo. If I had a proper house, I'd get some surplus rackmount boxes and stick them in the basement.
Hey, good luck on that, but as long as a house in seattle costs $500k and rent is $1200+, I'll be demanding a salary that can support that kind of thing. Or do you think only the few deserve to live in houses they own? Oh, and a good indian programmer is probably already working here.
Have you ever talked to an engineer who said, "yeah, just double the power and that won't affect anything else!" Maybe you've got a steel rod that keeps breaking, and the actual solution is to make a slightly bigger rod out of titanium. But if that actually works, it just means the engineering wasn't done right in the first place. This is how engineering disasters happen.
No, if that actually works, it means the engineering was done right - the part fills the requirements and is cost effective. They probably also engineered it so the weakest part is cheaper to replace, which means you get to think about that when doing a power upgrade.
Imagine something the size of amazon, google or ebay. There, a 10% performance boost in software could result in saving a million dollars in yearly operation / admin costs.
More than that at amazon (specifics are proprietary). The interesting thing there is that individual teams own their area front to back - this means that a slow service is the devs' problem and shows up on weekly reviews. The cool thing there is that a lot of the provisioning stuff is fully automated, so throwing more hardware at something takes all of a minute in a webtool (plus a few hours for the host spinup). It's bad to under/over provision, but recovering from a lot of mistakes is easy (unless there isn't enough hardware on hand). Sysadmin stuff is split into OS/hardware maintenance and group specific operational support, although a lot of teams do that for themselves - putting out prod fires sucks, but so long as it's limited to stuff that you could have prevented, it does serve a purpose.
In fact I've seen several orgs where the cost of a "Virtual Server" is almost as much as a physical one because the cost of all this servicing it is so high.
That's because they're doing it wrong - don't these people realize that server deployment can be reduced to a web-based wizard and a backend workflow?
Still sure you're _only_ going to throw hardware at the issue when business wants the application online for a couple of thousand people?
Who said that? This advice is for people with a brain - you have an immediate need, and assuming a weblike app, throwing boxes at the problem is low risk and fast. It assumes that you know something about your app and how it scales and why. If you don't, then you're SOL anyway.
Personally, when your DB server is pegged for all reasonable values of hardware, I would do the following: add caching (and refactor strategically to make it work better), split the DB into chunks, rearchitect into services (maybe), and rework the DB schema to eliminate hot spots/allow horizontal partitions. In order of increasing work. The service splitting part is handy with hot spots because you can then do horizontal partitions without telling your clients about it.
Slashdot Mirror
I have somewhat lower requirements, so my options are a) tarballs copied somewhere on another server and b) a SATA DDS3/4/72 drive and some $8 DDS tables. One tape is quite sufficient to my needs, and backup tapes are a lot sturdier than hard disks.
Backing up a live database can be a bit tricky
That's why most RDBMSes have some level of support for generating live snapshots and keeping them stable for a while. Get a DB backup at midnight and replicate rewrite logs somewhere else and you'll lose very little data when someone thermites your server.
well, this is part time - do you really need that much face time?
Yeah, and a browser isn't necessarily going to benefit from them. Being MS, I would hazard that the main reason IE7 doesn't support win2k is that MS wants to push people towards XP/vista.
why would a browser care about wireless enhancements?
Cue-cat isn't a copyrighted thing, it's a physical good, and it wasn't redistributed, it was sold - no copying involved. How would you even do that?
What's interesting is that the $80k damages figure was basically the entire cost of production, and assumed that he took the only copy for himself. That takes balls...
this is an emergency - why are you planning to run dryers off the generator? If your power dies, you can stop laundry service or hang dry inside; seriously, all you need is lights, heat, fridge, and some left over for electronics.
No, I was discussing that whole premature optimization aphorism, which you distorted in order to claim that it was faulty. I'm sorry your code has a crappy design - that's what prototypes, iteration, and capacity planning are for, to show you what your design needs to do before you spend too much time on in.
Fuck the children
George, is that you?
You can't optimize something until it's been built. If you address performance requirements before building, that's called design. I think you're confused about what optimization actually is.
Yeah, as long as it's for the childrun...
Next year, you need to handle double the load.
That's next year - we need to work right now, and spending the $50k gives us a year to fix the problem.
You have to consider that the author is writing for his particular niche - server-hosted apps written by US devs. He's also saying that throwing hardware at a problem is often the most cost effective solution. I don't see why people take issue with that.
No, the old saw is perfectly apt - would anyone in their right mind optimize before measuring what's slow?
I have forced air (spit!), so if I grab a bunch to play with clustering solutions, it's a wash. I'd do heat pump or gas, but it's an apartment/condo. If I had a proper house, I'd get some surplus rackmount boxes and stick them in the basement.
Hey, good luck on that, but as long as a house in seattle costs $500k and rent is $1200+, I'll be demanding a salary that can support that kind of thing. Or do you think only the few deserve to live in houses they own? Oh, and a good indian programmer is probably already working here.
Have you ever talked to an engineer who said, "yeah, just double the power and that won't affect anything else!" Maybe you've got a steel rod that keeps breaking, and the actual solution is to make a slightly bigger rod out of titanium. But if that actually works, it just means the engineering wasn't done right in the first place. This is how engineering disasters happen.
No, if that actually works, it means the engineering was done right - the part fills the requirements and is cost effective. They probably also engineered it so the weakest part is cheaper to replace, which means you get to think about that when doing a power upgrade.
It's winter - I'll take 12 :). Actually, I'd love to know where to grab them if they're anywhere near seattle.
Imagine something the size of amazon, google or ebay. There, a 10% performance boost in software could result in saving a million dollars in yearly operation / admin costs.
More than that at amazon (specifics are proprietary). The interesting thing there is that individual teams own their area front to back - this means that a slow service is the devs' problem and shows up on weekly reviews. The cool thing there is that a lot of the provisioning stuff is fully automated, so throwing more hardware at something takes all of a minute in a webtool (plus a few hours for the host spinup). It's bad to under/over provision, but recovering from a lot of mistakes is easy (unless there isn't enough hardware on hand). Sysadmin stuff is split into OS/hardware maintenance and group specific operational support, although a lot of teams do that for themselves - putting out prod fires sucks, but so long as it's limited to stuff that you could have prevented, it does serve a purpose.
In fact I've seen several orgs where the cost of a "Virtual Server" is almost as much as a physical one because the cost of all this servicing it is so high.
That's because they're doing it wrong - don't these people realize that server deployment can be reduced to a web-based wizard and a backend workflow?
So 2^2 == 10, eh?
In base 4 I'm fine!
Does that include the time to test the circuits and redesign where necessary? Dropping the tolerances like that requires a lot of testing.
Still sure you're _only_ going to throw hardware at the issue when business wants the application online for a couple of thousand people?
Who said that? This advice is for people with a brain - you have an immediate need, and assuming a weblike app, throwing boxes at the problem is low risk and fast. It assumes that you know something about your app and how it scales and why. If you don't, then you're SOL anyway.
Personally, when your DB server is pegged for all reasonable values of hardware, I would do the following: add caching (and refactor strategically to make it work better), split the DB into chunks, rearchitect into services (maybe), and rework the DB schema to eliminate hot spots/allow horizontal partitions. In order of increasing work. The service splitting part is handy with hot spots because you can then do horizontal partitions without telling your clients about it.