That's the beauty of the web. At a basic level, it's stateless. Web frameworks don't have any concept of communicating with other clients. The highest level they'll work at is the individual session. You only see complexities worse than O(N) when clients communicate with each other, and that communication must be an entirely application-specified thing. The web framework and language have nothing to do with this communication between clients, and so have nothing to do with scalability writ large.
Effect is used as a verb when there's no direct object. When used as a verb you can replace it with "bring about" and see if it makes sense. So in this case, "The Twitter team has been making a concerted effort to bring about better communication with their community at large." So, effect is the right spelling.
You mean with a direct object, right? When saying "Bob effects X", X is the direct object.
I'm not a physicist, but I'm still fascinated by astronomical phenomena like this. Can anyone tell me what the effects of ultra-strong magnetic fields would be on a living creature? I know we can levitate frogs with powerful magnets, but nothing strange happens to the frog itself. Can we withstand a magnetic field of any strength?
There's no mixed namespace support after munging XHTML into HTML 4 either.
If you have an XHTML workflow, there are three options.
Serve XHTML as application/xhtml+xml
Serve XHTML as text/html
Munge the XHTML into HTML 4 and serve that as text/html
Option 1 is the best choice, but it's a non-starter today. All browsers today will operate correctly with option 2. Option 3 introduces needless complexity and introduces barriers to later switching to option 1. Option 2 is simply the best we can do today.
Ruby is not Twitter's problem. The algorithm Twitter uses is the problem.
When I started irately writing this post, I wrote it in a tone that would have gotten me modded into oblivion. But then I realized that ignorance, not idiocy, drives the particular myth I'm debunking. let me educate, not flame, those of you who haven't formally studied computer science.
It's become fashionable to blame Ruby for Twitter's problems, but that's wrong. The particular choice of language doesn't matter a bit when you talk about scalability, no matter what the language or the problem.
First, sending a twitter message is an algorithm. An algorithm is just a recipe for doing something to some data. Although most computer science literature deals with more abstract and general algorithms, like those for sorting and searching, the same principles applies to even the most mundane processes, like what rm foo does to a file system, or how a database engine runs an INSERT.
One way we can talk about algorithms is to use something called Big-O Notion, which describes the relationship between how much stuff an algorithm processes and how long it takes to run.*
It's easier to see things with examples. Say we have an algorithm and we give it three sets of data, D1 and D2, and D3, each twice as large as the last, so that D2 is twice as large as D1, and D3 is four times as large as D1.
If we call the algorithm O(1), it will take the same amount of time to process D1, D2, and D3. If we instead say it's O(N), D2 will take twice as long to run as D1, and D3 will take four times as long.
If N represents the number of users for a web application, and we want to double N, twice as many users, we'd need twice as many web servers if the bottleneck algorithms are O(N). If the database is the bottleneck, we'd need a twice-beefier database server, or some partitioning.
Things start to get interesting with O(N^2). In that case, D2 takes four times longer to run than D1, and D3 takes four times longer than D2, which sixteen times longer than D1.
That means that if we want to support twice as many users, we need four times as many web servers, or more likely, a four-times beefier database server.
It can get a lot worse than O(N^2) too, especially if you're not paying attention to complexity. For example, many graph (think social networking) algorithms can easily become O(2^N), which is a lot worse than N to a constant power.
When you try to scale a poorly-designed algorithm (pretty much anything worse than O(N)), you start running out of cores, rack space, electricity, and atoms in the universe.
One useful bit about big-O notation is that it lets us ignore piddly details that don't matter. Say we had an O(2N) version of the O(N) algorithm. Sure, the O(2) algorithm might take twice as long to run, but it can still handle double the data with double the capacity or double the time. Even if it's O(10N), you don't start boiling the oceans to cool your data center when you want to increase your visit capacity a thousandfold.
This observation is why the choice of language doesn't matter. If a language implementation is slow, all it does is add a constant factor to any algorithms written in that language. A Python application might be ten times slower than one written in C, but its big-O complexity will be the same.
At the worst, that means you'll need ten times as many servers as with the C web application. The increase in development efficiency writing in Python (or Ruby on Rails, or Lisp, or anything else) might make the trade-off worth it. You can deal with a constant factor slowdown.
If on the other hand, you code a wicked fast implementation of an O(N^3) algorithm in C, no amount of hardware will save you. You'll hit a number of users beyond which your servers slow to a crawl and you lose blagosphereic karma. Even if you double your capacity, or buy a four-times-beefier database server, that
I disagree. You're being a purist, ignoring real problems, and not considering benefits remaining even after serving XHTML as text/html. XHTML isn't just useful for the client: it's useful for the server. Serving XHTML as HTML might strip the client-side benefits, but it leaves the server-side ones intact, and I'd argue that being able to use XML processing tools and editors in development is a bigger boon that the client parsing the page with a real XML parser.
The fact is, today, browsers don't support XHTML served as application/xhtml+xml as well as they do text/html. Only the latest beta of Firefox supports incremental rendering of XHTML, for example. And as much as we would rather these go away, people still like to use loathsome constructs like document.write, namespace-unaware Javascript DOM methods, ALL CAPS CSS selectors, and inline script elements with constructs that look like XML comments.
On the other hand, browsers universally and correctly understand XHTML documents served as HTML, as long as they're serialized with XHTML compatibility guidelines in mind. As long as these documents have the correct doctype, browsers still render them in full standards mode. There is no downside to serving XHTML as HTML.
Yes, even with compatibility guidelines in mind for serialization, XHTML violates some aspects of the HTML standard. But browsers universally understand these deviations from the standard, so practically speaking, there is no problem.
So our two options are using HTML 4 and serving it as HTML 4, or using XHTML 1.0 and serving it as HTML 4. At least the latter gives us the ability to work with an XML toolchain on the server side, and when the web evolves to the point where we can start serving XML as XML, it's easier to do that than to munge those crufty old HTML documents.
XHTML should be served as text/html anyway. You don't lose anything in your workflow -- validating editors will still work, XSLT will still work, and so on -- but your users get incremental rendering and a better-tested parser.
And how much did you have to sacrifice to achieve that feat? Any why did you bother? You're only going to live to be about 72. Did you really want to waste all that time tweaking when you could have simply coded a standard version, and conditionally included some IE workarounds?
"The PHP side"? This is a huge pet peeve of mine. PHP is not the only server-side web option, and talking about it as if it were only perpetuates that mediocre language's popularity. There's a whole world out there! Why limit yourself to clanky, rusty old PHP?
Nifty. Aside from being almost impossible to find, keyboards using Cherry keyswitches sound like just the thing. I can't find the G-1800LUMUS in Cherry's price list though. Does it use the "linear", "soft", or "click" tactile feel keyswitches?
I love my IBM model M (made 1993-05-21), but it's too loud to use at work. Right now, I'm using an old Dell rubber-membrane keyboard. I hate typing on it. Any suggestions on a keyboard with good tactile feedback but less of the BOFH clickyness?
(Unrelated note: the key sound of a Model M is the worst possible thing to hear when hung over. Something about the pitch makes every key a knife twisting in the brain.)
Re:Doesn't even have to be live life...
on
The Phoenix Has Landed
·
· Score: 2, Informative
A "cheap" CCD might produce something approximating what the eye would see under typical Earth lighting conditions, but not under Martial conditions. Haven't you ever taken a photograph indoors and been disappointed at the poor color reproduction?
It still only uses an RTG though. I'd love to see a bona fide nuclear reactor on a mission. Nuclear-electric propulsion seems promising, as does the old project orion stuff.
We're running a no-frills OpenBSD load balancer at work. Right now, it's running Pound (the quickest thing we could get up once traffic spiked a few weeks ago), but we're considering other approaches too. haproxy's load balancing knobs look interesting. It looks like you can configure it so the maximum number of clients scales with the current load. The problem is that there's no feedback system.
Some kind of loadavg-based, or even response-time, feedback mechanism would be great! Pound has that (I believe), but since Pound requires downtime for every configuration change, we want to move away from it ASAP.
Indeed. Why is it any better to concentrate power in corporations than in government though? At least government is nominally accountable to the people. That's why I favor strong government regulation of business. The DMCA came about because the balance of power is too heavily weighted, via lobbyists, toward corporations.
Enemies of atheism, alternative sexuality, and so on usually belong to one of two types: 1) low-information people who are told gay atheists are wicked, and who believe it, and 2) those who have these tendencies themselves and are engaged in a bout of psychological projection (like many religious leaders.)
A transparent society would help the first group realize that the people they're persecuting are just like them. Persecution requires dehumanization, and dehumanization requires disinformation.
Members of the second group would be exposed well before they rose to power in the first place.
There is no kind of knowledge that science cannot asymptotically approach. We will be wrong at times, but at least in a bounded, deterministic way. Mysticism is merely panding to oneself. You cannot find answers there any more than list_t sort(void) can sort an arbitrary list. With no input from the external world, what use can the "places" mysticism take be?
I feel the same way. We ran rant all we want, but in the end, programming is going to get done by the cheapest, least-skilled people available. So we need to make the path of least resistance the correct path.
One quick and dirty idea I had for PHP was the following: Imagine a new string-like datatype, the query string. Syntactically, it works like a double-quoted string, but it's delimited by, let's say, [ and ]. Database query functions would only accept this new query-string type.
Concatenating a query string type with a regular string produces a query string type, but with the regular string quoted. String substitutions into a query string (using PHP's $ operator) would quote the strings first.
Thank you for your fascinating post. I find myself wondering though, why you are a "hardcore libertarian" despite your solid grasp of the economics. Clearly, a very high top tax rate, strong corporate regulation, and an extensive public welfare system lead to an equitable society. What is the downside, and why would you oppose these kinds of regulations?
Slashdot Mirror
That's the beauty of the web. At a basic level, it's stateless. Web frameworks don't have any concept of communicating with other clients. The highest level they'll work at is the individual session. You only see complexities worse than O(N) when clients communicate with each other, and that communication must be an entirely application-specified thing. The web framework and language have nothing to do with this communication between clients, and so have nothing to do with scalability writ large.
You mean with a direct object, right? When saying "Bob effects X", X is the direct object.
I'm not a physicist, but I'm still fascinated by astronomical phenomena like this. Can anyone tell me what the effects of ultra-strong magnetic fields would be on a living creature? I know we can levitate frogs with powerful magnets, but nothing strange happens to the frog itself. Can we withstand a magnetic field of any strength?
If you have an XHTML workflow, there are three options.
Option 1 is the best choice, but it's a non-starter today. All browsers today will operate correctly with option 2. Option 3 introduces needless complexity and introduces barriers to later switching to option 1. Option 2 is simply the best we can do today.
Ruby is not Twitter's problem. The algorithm Twitter uses is the problem.
When I started irately writing this post, I wrote it in a tone that would have gotten me modded into oblivion. But then I realized that ignorance, not idiocy, drives the particular myth I'm debunking. let me educate, not flame, those of you who haven't formally studied computer science.
It's become fashionable to blame Ruby for Twitter's problems, but that's wrong. The particular choice of language doesn't matter a bit when you talk about scalability, no matter what the language or the problem.
First, sending a twitter message is an algorithm. An algorithm is just a recipe for doing something to some data. Although most computer science literature deals with more abstract and general algorithms, like those for sorting and searching, the same principles applies to even the most mundane processes, like what rm foo does to a file system, or how a database engine runs an INSERT.
One way we can talk about algorithms is to use something called Big-O Notion, which describes the relationship between how much stuff an algorithm processes and how long it takes to run.*
It's easier to see things with examples. Say we have an algorithm and we give it three sets of data, D1 and D2, and D3, each twice as large as the last, so that D2 is twice as large as D1, and D3 is four times as large as D1.
If we call the algorithm O(1), it will take the same amount of time to process D1, D2, and D3. If we instead say it's O(N), D2 will take twice as long to run as D1, and D3 will take four times as long.
If N represents the number of users for a web application, and we want to double N, twice as many users, we'd need twice as many web servers if the bottleneck algorithms are O(N). If the database is the bottleneck, we'd need a twice-beefier database server, or some partitioning.
Things start to get interesting with O(N^2). In that case, D2 takes four times longer to run than D1, and D3 takes four times longer than D2, which sixteen times longer than D1.
That means that if we want to support twice as many users, we need four times as many web servers, or more likely, a four-times beefier database server.
It can get a lot worse than O(N^2) too, especially if you're not paying attention to complexity. For example, many graph (think social networking) algorithms can easily become O(2^N), which is a lot worse than N to a constant power.
When you try to scale a poorly-designed algorithm (pretty much anything worse than O(N)), you start running out of cores, rack space, electricity, and atoms in the universe.
One useful bit about big-O notation is that it lets us ignore piddly details that don't matter. Say we had an O(2N) version of the O(N) algorithm. Sure, the O(2) algorithm might take twice as long to run, but it can still handle double the data with double the capacity or double the time. Even if it's O(10N), you don't start boiling the oceans to cool your data center when you want to increase your visit capacity a thousandfold.
This observation is why the choice of language doesn't matter. If a language implementation is slow, all it does is add a constant factor to any algorithms written in that language. A Python application might be ten times slower than one written in C, but its big-O complexity will be the same.
At the worst, that means you'll need ten times as many servers as with the C web application. The increase in development efficiency writing in Python (or Ruby on Rails, or Lisp, or anything else) might make the trade-off worth it. You can deal with a constant factor slowdown.
If on the other hand, you code a wicked fast implementation of an O(N^3) algorithm in C, no amount of hardware will save you. You'll hit a number of users beyond which your servers slow to a crawl and you lose blagosphereic karma. Even if you double your capacity, or buy a four-times-beefier database server, that
I disagree. You're being a purist, ignoring real problems, and not considering benefits remaining even after serving XHTML as text/html. XHTML isn't just useful for the client: it's useful for the server. Serving XHTML as HTML might strip the client-side benefits, but it leaves the server-side ones intact, and I'd argue that being able to use XML processing tools and editors in development is a bigger boon that the client parsing the page with a real XML parser.
The fact is, today, browsers don't support XHTML served as application/xhtml+xml as well as they do text/html. Only the latest beta of Firefox supports incremental rendering of XHTML, for example. And as much as we would rather these go away, people still like to use loathsome constructs like document.write, namespace-unaware Javascript DOM methods, ALL CAPS CSS selectors, and inline script elements with constructs that look like XML comments.
On the other hand, browsers universally and correctly understand XHTML documents served as HTML, as long as they're serialized with XHTML compatibility guidelines in mind. As long as these documents have the correct doctype, browsers still render them in full standards mode. There is no downside to serving XHTML as HTML.
Yes, even with compatibility guidelines in mind for serialization, XHTML violates some aspects of the HTML standard. But browsers universally understand these deviations from the standard, so practically speaking, there is no problem.
So our two options are using HTML 4 and serving it as HTML 4, or using XHTML 1.0 and serving it as HTML 4. At least the latter gives us the ability to work with an XML toolchain on the server side, and when the web evolves to the point where we can start serving XML as XML, it's easier to do that than to munge those crufty old HTML documents.
XHTML should be served as text/html anyway. You don't lose anything in your workflow -- validating editors will still work, XSLT will still work, and so on -- but your users get incremental rendering and a better-tested parser.
And how much did you have to sacrifice to achieve that feat? Any why did you bother? You're only going to live to be about 72. Did you really want to waste all that time tweaking when you could have simply coded a standard version, and conditionally included some IE workarounds?
"The PHP side"? This is a huge pet peeve of mine. PHP is not the only server-side web option, and talking about it as if it were only perpetuates that mediocre language's popularity. There's a whole world out there! Why limit yourself to clanky, rusty old PHP?
Nifty. Aside from being almost impossible to find, keyboards using Cherry keyswitches sound like just the thing. I can't find the G-1800LUMUS in Cherry's price list though. Does it use the "linear", "soft", or "click" tactile feel keyswitches?
I love my IBM model M (made 1993-05-21), but it's too loud to use at work. Right now, I'm using an old Dell rubber-membrane keyboard. I hate typing on it. Any suggestions on a keyboard with good tactile feedback but less of the BOFH clickyness?
(Unrelated note: the key sound of a Model M is the worst possible thing to hear when hung over. Something about the pitch makes every key a knife twisting in the brain.)
By the way, a similar technique was used by Sergei Mikhailovich Prokudin-Gorskii to produce wonderful, early color photographs of the Russian Empire during World War I.
A "cheap" CCD might produce something approximating what the eye would see under typical Earth lighting conditions, but not under Martial conditions. Haven't you ever taken a photograph indoors and been disappointed at the poor color reproduction?
It still only uses an RTG though. I'd love to see a bona fide nuclear reactor on a mission. Nuclear-electric propulsion seems promising, as does the old project orion stuff.
You forgot the rest of that sentence: "...except for all the others that have been tried."
Slightly different sense, yes?
keepalived/relayd still has no feedback-based weighting mechanism.
We're running a no-frills OpenBSD load balancer at work. Right now, it's running Pound (the quickest thing we could get up once traffic spiked a few weeks ago), but we're considering other approaches too. haproxy's load balancing knobs look interesting. It looks like you can configure it so the maximum number of clients scales with the current load. The problem is that there's no feedback system.
Some kind of loadavg-based, or even response-time, feedback mechanism would be great! Pound has that (I believe), but since Pound requires downtime for every configuration change, we want to move away from it ASAP.
Indeed. Why is it any better to concentrate power in corporations than in government though? At least government is nominally accountable to the people. That's why I favor strong government regulation of business. The DMCA came about because the balance of power is too heavily weighted, via lobbyists, toward corporations.
Enemies of atheism, alternative sexuality, and so on usually belong to one of two types: 1) low-information people who are told gay atheists are wicked, and who believe it, and 2) those who have these tendencies themselves and are engaged in a bout of psychological projection (like many religious leaders.)
A transparent society would help the first group realize that the people they're persecuting are just like them. Persecution requires dehumanization, and dehumanization requires disinformation.
Members of the second group would be exposed well before they rose to power in the first place.
There are bigger problems with conventional science fiction faster-than-light travel: namely, the problem of FTL travel implying time travel. As much as I'd love to see FTL work, I think we're limited to slower-than-light travel, as in Clarke's Songs of Distant Earth/a) (probably my favorite hard science fiction novel.)
Ergo, anyone who cannot reproduce the experience is not practicing meditation intensely enough. Your statement is unfalsifiable.
There is no kind of knowledge that science cannot asymptotically approach. We will be wrong at times, but at least in a bounded, deterministic way. Mysticism is merely panding to oneself. You cannot find answers there any more than list_t sort(void) can sort an arbitrary list. With no input from the external world, what use can the "places" mysticism take be?
I feel the same way. We ran rant all we want, but in the end, programming is going to get done by the cheapest, least-skilled people available. So we need to make the path of least resistance the correct path.
One quick and dirty idea I had for PHP was the following: Imagine a new string-like datatype, the query string. Syntactically, it works like a double-quoted string, but it's delimited by, let's say, [ and ]. Database query functions would only accept this new query-string type.
Concatenating a query string type with a regular string produces a query string type, but with the regular string quoted. String substitutions into a query string (using PHP's $ operator) would quote the strings first.
The ballot must be anonymous. "Show me your voting receipt or you're fired."
Thank you for your fascinating post. I find myself wondering though, why you are a "hardcore libertarian" despite your solid grasp of the economics. Clearly, a very high top tax rate, strong corporate regulation, and an extensive public welfare system lead to an equitable society. What is the downside, and why would you oppose these kinds of regulations?