Slashdot Mirror
Twitter Leads Social Networks In Downtime
illectro writes "A study on site availability by monitoring service Pingdom shows that in 2008 Twitter greeted users with the 'Fail Whale' for more than 84 hours, almost twice as much as any other site. At the other end of the scale imeem and Xanga managed less than 4 hours of downtime for 99.95% uptime. Myspace, Facebook and Classmates.com were the only other sites studied which managed to stay up more than 99.9% of the time."
So go out and get some sunshine or something.
And yet it had 0% impact on my life. So who really cares.
Go facebook! 'Stealing' my data, 99.9% of the time! (Yes, I do have a facebook account)
Bored at work? Play Game!
I find it kind of strange that a site as incredibly simple as Twitter had so much downtime. Granted, they probably don't have the multiple dedicated redundant datacenters to their name like MySpace and Facebook do... but still, they're only serving little tidbits of text.
Yep, but
whitter.com
twerple.com
and drivel.com
got a hell of traffic during those hours
If he's the Walrus then can I be a penguin please?
If Twitter was the worst, with 84 hours downtime, one year is 8765.81277 hours, which means that Twitter was down .958268243% of the time. Not .9 (90%), but .009 (nine tenths of one percent). IOW, it has an uptime of 99.05%. Sure, that's not great compared to 99.95%, but it was down less than 1 in every 100 times you tried to reach it. I'm pretty sure Yahoo! doesn't manage that, and I know Microsoft's download servers don't manage that...
And here I am worrying about whether I should see my doctor after 4 hours of uptime.
This guy's the limit!
Unless you want to know if Stephen Fry is baking a cake or having a tea with his friends
WHO CARES? I mean really. A total waste of electrons, always has been, always will be.
Not News, much less News for Nerds. More like news for TURDS. See how it rhymes?
I clicked the story expecting to see users waste more hours on twitter than other social networks. That would've been more interesting. The story above is... just plain boring.
as a result, but apparently you can't divide by zero.
I've made a number of technological choices accommodating downtime precisely as a motivator to get out and do something real.
Much as I'd love the always-connected nature of an iPhone, I settle for the iPod Touch precisely because it's not always connected - if I can't get WiFi service, that's a good thing. Blogging is fine, but the rapid update demands of Facebook are more than is worth spending my limited lifespan on. I'm increasingly disliking digital videography, preferring to live the moment than get wrapped up in trying to record it (only to most likely not "relive it" later). Twitter is down? good - go talk to someone in person.
Can we get a "-1 Wrong" moderation option?
I think many of us recognize the potential power of twitter-like thingies. With this in mind I recently joined. It is beyond disappointing.
- the site itself is barren, with basically no features - it is just like a '98 site in a bad way (not in a "Google-like" minimalist way)
- can't get updates by SMS in Europe. OK, fair game, it isn't free. But you should be able to at least post by SMS, right? Somehow although they do offer local numbers (very nice) I wasn't able to actually verify any phone so can't update by SMS
- they had updates by Instant Messenger as official feature for a while but couldn't make it work (why?! at least it should be practically free for them unlike SMS)
- there are some 3rd party solutions to update by IM but none work (plus you have to trust the 3rd party)
- same as above for updates by email
So, yes, nice idea but poor execution.
Twitter takes no effort to make scale and keep up. There's NOTHING complex about it.
High availability is expensive to attain. How much do you expect them to be investing to perfect this free service for you?
How do you break this down? Are they just pinging twitter.com and waiting for timeouts on html returned?
I ask, because lots of twitter is their distribution via their APIs. How many of those other moblog sites have http GETs to non-html documents? Check for yourself: http://apiwiki.twitter.com/
I wonder how many statuses were updated from facebook.com or pulled there from a twitter API poll. It would be nice if a site like facebook could post their timeouts on their user status polls they do from their site. That might give people more of an idea of the complete twitter uptime.
Imeem sucks! It's like myspace but with worse code if you could imagine that. I would have expected them to be the lowest. If you actually count the amount of time some of their features didn't work, it's about 50% uptime.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
Parent was, indeed, the first person to post "First!" — for what that's worth.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
I'm now posting on /. about Twitter.
I live such a full life.
This is not all that meaningful unless you also completely correlate the uptime info with the number of users/requests/whatnot the site does.
The report doesn't explore that sufficiently enough for me. I can make an app that has 100% uptime if it has one request an hour. Downtime is largely caused (directly or indirectly) by load, so in most cases downtime usually increases as user load (defined as user interaction and amounts of user data, and the actions of those users on that data) increases.
Painting with a broad brush you could say, yes, Xanga has the best uptime but they also probably have the lowest user load as well whereas twitter probably has one of the highest (current) user loads and thus lowest downtime.
Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
Maybe there is, somewhere in the world, guy who pays lots of $$$ to ISPs to 404 Twitter site as often as possible. If this is the case, that guy is really rich and his brain works in similar way as mine.
839*929
schadenfreude - taking delight in others' misfortune. Guilt doesn't enter into it, AC.
You better watch out, there may be dogs about . .
I mean wtf? This has been dubunked so many times.
After this announcement someone wrote a plugin for rails that handled multiple databases.
And you know, we had this huge ruby on rails application that never really took off. I would had really loved to have those performance issues they were describing.
I no longer use Myspace (Thank god!) but it seemed like every time I tried to do something, I was redirected to an error page assuring me that their support staff would be notified...
Sure, Myspace was able to display html in my browser, but it seems a bit far fetched to consider that "uptime".
Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.
That is probably true. However, I would count that as an advantage -- better to deal with them sooner than later.
At this point in time there's no facility in Rails to talk to more than one database at a time.
There are many, many ways to talk to more than one database in Rails. In fact, it is possible to swap out the entire database layer of Rails and use another ORM, or no ORM at all. On the bleeding edge -- and Twitter might actually be a good candidate for this -- people have wired up Rails to CouchDB, which provides trivially scalable multimaster replication, and which, being HTTP, can be thrown behind any old load balancer -- which brings this back to a "just throw hardware at it" problem.
All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise.
Some of them do -- a good example would be Symbol.to_proc.
However, Merb proves that this is not actually a Ruby problem, it is a Rails problem. And Rails and Merb are merging some point in the near future.
It's also worth mentioning that there shouldn't be doubt in anybody's mind at this point that Ruby itself is slow. [...] I think it's worth being frank that this isn't one of those relativistic language issues. Ruby is slow.
Somewhat true -- after all, Ruby 1.9.1 did double the performance of the language.
But, relative to what?
Turns out that, at least compared to other languages and frameworks (like PHP), Ruby is not slow.
It's also worth mentioning that while all of the Twitter alternatives may have enjoyed better uptime, they haven't had nearly the amount of traffic that Twitter does. We don't really know if they can scale -- but even supposing they can, Twitter was there first. And while they complain about those nice features being slow, they probably owe their success to those features for getting their product out the door faster than their competitors.
It's also worth mentioning that this interview is almost two years old. Rails changes a lot in two years. In fact, Twitter were early adopters -- two years before that interview, Rails had only just shared commit rights. Two years before that, it didn't exist at all.
It might be worth asking what version of Rails Twitter is using, and if they've noticed a change since then.
Don't thank God, thank a doctor!
Facebook and MySpace both have hours and hours of being simply unusable. You its just server maintenance, sometimes they even say as much. You can technically log into them but it turns into a brick from there. Can that honestly be called 99.5% Uptime?
does this mean metalhed77 wants to punch Alex Payne in the face?
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
Twitter is on par with Brangelina type stories. Find something more newsworthy to fill dead space with(!!) This is so frustrating.
moox. for a new generation.
The Twitter people have stated publicly that their technical problems are NOT due to Rails. You folks can claim that it is all you want, but that doesn't change the facts.
The problem isn't people obsessed with Rails... the problem here is people who just don't like it, for whatever reasons of their own. Well, your reasons *ARE* your own. Please keep them to yourselves unless you can start coming up with facts rather than unfounded insults.
Quote from Twitter representative: "I strongly believe that the best tool for the job is the best tool for the job. Rails is the best web application framework around for rapid prototyping and, as aforementioned, building CRUD-style applications. I would choose Rails again for such a project."
Twitter stated that they simply did not plan ahead for the popularity of their service. Period. That is not the fault of the platform they use.
The social non-networking site I use, isolatr.com, is never down, and has never failed to bring me zero annoying "friends". I highly recommend it.
Actually, compared to PHP, it is slow. Alot of people benchmark PHP incorrectly. Everyone who knows anything about PHP knows it was built to be an Apache module and never to be used as a command line utility because it doesn't have a daemon; it doesn't run in the background like other languages, it starts up and shuts down after running each script.
This is why if you don't benchmark it as an Apache module (where it IS running as a daemon), it loses a second or two in the benchmark while it starts up its engine. Nuby developers love to quote this stat but are clueless in the fact that what they are quoting is completely wrong. If you were to benchmark the other languages the same way, you would have to shut their daemons off so the startup of their engines are taken into consideration with the benchmark as well.
This is my sig. There are many like it but this one is mine.
While I don't use twitter, it's downtime is bad enough (or people are obsessed enough) that not only is there IsTwitterDown.com but also IsIsTwitterDownDown.com
What are the best Twitter apps for the iPhone? What app do you use and why?
these were what some people were saying in slashdot back a while ago about twitter, ruby and whatnot.
Read radical news here
Don't like Twitter's downtime? roll your own and do better.
(But honestly, I still don't see what all the hype about Twitter is. It's just a mashup between instant messaging and RSS from what I can tell, not sure why there needs to be a "service" wrapped around it.)
One of the most amusing error messages ever 3 Where the hell did it come from? Why is it flying with birds? What the fuck is this shit? Who knows! It's fail whale!
Support my political activism on Patreon.
We know Twitters architectural history, but anyone have a summary of the three big sites with the higher uptime? (Server-side of course). Commonalities would mean a lot I'd think.
Sorry, I'm old and lazy or else I'd look it up myself.
...are people who died from Twitter Recursive Downtime Syndrome (TRDS). More or less when Twitter goes down, they want to tweet about Twitter being down, when they realized how that makes them feel they want to tweet that, after about the third or fourth round of that, well it isn't pretty.
When I have a kid, I want to put him in one of those strollers for twins and then run around the mall looking frantic.
Actually, compared to PHP, it is slow. Alot of people benchmark PHP incorrectly. Everyone who knows anything about PHP knows it was built to be an Apache module and never to be used as a command line utility because it doesn't have a daemon
Then you might be surprised by the benchmark I actually linked to. This was a measure in requests per second of a full Web application, not of something silly like fibbonacci.
Nuby developers love to quote this stat but are clueless in the fact that what they are quoting is completely wrong.
Once again: Look at the actual statistic I'm quoting. Are you suggesting this was CakePHP, run as a web app, benchmarked with a web benchmark, yet somehow run as a commandline app?
Don't thank God, thank a doctor!
Join multiple sites. So when Twitter goes down, you can gripe on Facebook about it, and when FB goes down, you can tweet away.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
If twitter is used for more of this: http://twitter.com/brokep/status/1218354272 then it will make all our lives better!
Prosp long and liver.
plus a little bad luck and architecture trouble would do it. Unless of course you're thinking of Twitter as being a single apache/mysql pair.
Quack, quack.
Sure, that's not great compared to 99.95%, but it was down less than 1 in every 100 times you tried to reach it.
Ahh, the old "99% is good enough" argument. Occasionally 99% is actually good enough but you have to be VERY careful with that argument. It is extremely easy to come up with examples where 99% is absolutely miserable performance. All you need is a large number of transactions or severe consequences for a failure. The former definitely applies here and possibly the latter too once money gets involved.
For example if 99% were good enough reliability for air traffic controllers, each year 640,000 flights would be at serious risk during takeoff and landings. Granted, no lives are at risk with Twitter but it illustrates my point that 99% can be terrible performance. Trust me when I say you do NOT want your bank thinking 99% is good enough.
Downtime of 3.5 days per year is pathetic for a company with serious e-commerce ambitions. There really is no excuse since the technology to ensure high availability is widely available and well understood. If Twitter were some tiny little startup with two guys in a garage doing the programming I might be more forgiving but they aren't anymore. They've gotten millions of dollars in financing and ought to be able to afford some real equipment and talent. If/when they start getting serious money and paying customers involved they had better raise their game.
I've never used CakePHP before, but every benchmark I find on it suggests that it's horribly slower (10-100x slower, if not more) than stock PHP. For example, over here they get 37.46 requests/s for a hello world CakePHP page on a 3 GHz Intel machine with 512M RAM. I gave a plain PHP hello world page a try on a 1.3 GHz Pentium-M laptop with 512M RAM (a substantially slower machine) with the same ab parameters and I get 1254.75 requests/s. In other words, the substantially slower machine gave 33x better performance with stock PHP than the substantially faster machine gave with CakePHP.
So yes, maybe RoR has comparable performance to CakePHP, but who cares? CakePHP is painfully slow and I don't know anyone or anything that actually uses it. Wake me up with RoR (or Ruby) is faster than stock PHP.
Game! - Where the stick is mightier than the sword!
Facebook screws around their site live so often that it is not even sensible to assume that their site is running properly if you can point your browser to it.
In a 4 month stint as a maintenance programmer for one of the apps on there, it has become impossible to tell when I introduced a bug onto the app, or Facebook is actually crapping out.
I would laugh if once we factor that in, it suffers more outages than Twitter.
No, the problem is that your claims contradict what just about everybody who uses Ruby regularly knows. First, Ruby is not "a database interface" at all. However, there are MANY database interfaces that are available for Ruby. Take your pick. Are you trying to say they are ALL bad? Nonsense.
Ruby interfaces with C libraries as easily as Python. In fact, most "database interfaces" as you put it for Ruby are written in C. As they should be.
There are also many different caching schemes available to Ruby -- and Rails -- programs.
See, this crap actually isn't "obvious" at all... it is false. What is glaringly obvious is that you don't know crap about Ruby.
"No wireless. Less space than a Nomad. Lame." - October 23, 2001
Read my blog.
So myspace hardly ever goes down. They still to this day have issues of not having enough resources for the amount of traffic they get (may be part of the reason that most people I know have all but ditched myspace and went to facebook). Look, if there Are so many people on your site every single night that some people get DOS, and those who do get in cannot do anything, while they have the brilliance to take down resources during peak hours to install untested site updates, then what difference does it make if the site is up? It's still unusable.
Truthfully, I am also surprised to hear xanga is still around. I mean what is the point of a social networking site if none of your friends are on it?
But twitter was down.
If you can read this, it means that I bothered to log in.
Who the fuck cares? Twitter isn't a new social/Internet paradigm, it's not anything more than needy people spewing into the void, hoping that others care enough to listen.
Guess what? We don't.
How vast is their data model?
create table user;
create table message;
done. (don't forget the commit if you're on PostgreSQL!)
Rails?
Really?
Samuel H. Christmas....I'm sure I'm over-simplifying this, but what benefit to they gain from using Rails on such a simple app? There can't be more than 30 unique pages on the entire site!
Chainsaw to sharpen a pencil
Shotgun to kill a mosquito
Rails to implement Twitter
Choose the correct tool for the job!
> better to deal with them sooner than later.
Well said sir. Scaling is not about language opcode execution speed. Apps don't scale by eliminating a few JMPs and BEQs here and there. Instead, they scale by coming up with good _architectures_. Caching, partitioning, sharding, queuing, backgrounding... all that stuff. Given a good enough architect you could probably write EBay in Bash.
The Army reading list
Coincidently, Twitter is going to have some scheduled downtime tonight. I'm already upset about it. My tweeting addiction makes it hard to stop.
Not that those things are irrelevant, just that initially, they are less important.
Certainly, it's possible eBay could save a lot of money on hardware by rewriting the site in a faster language (or even in C) if they started in Bash. It's also possible they would start looking at other optimizations -- all those little hacks you avoid during development could suddenly mean thousands of dollars saved.
But you won't know which hacks are worth thousands of dollars, and which ones will cause thousands of dollars in debugging headaches for no real gain, without profiling. And it's kind of difficult to profile before you have a working site.
Don't thank God, thank a doctor!
they get 37.46 requests/s for a hello world CakePHP page on a 3 GHz Intel machine with 512M RAM. I gave a plain PHP hello world page a try on a 1.3 GHz Pentium-M laptop
How much does either of those have to do with the real world? That's why I linked to a benchmark of a real (though simple) app, that actually reads and writes to a database...
I mean, I'm sure I can beat your scores with a static page.
What matters is, when you actually start to build out your application's logic, how much do you have to rewrite yourself that you could have borrowed from something like Cake? Are you sure you're doing it more efficiently than Cake would be?
By the time you've built your own router, controllers, models, and ORM, you may find your app is slower than a Cake (or Rails) app. That is -- by the time your app is doing more interesting things than "Hello World".
Wake me up with RoR (or Ruby) is faster than stock PHP.
Wake up, then, and follow the link I pasted, way up in this thread. If you really don't need a heavyweight MVC architecture, you can use the bare Merb router, or a bare-metal Rack app. Sinatra might even be a good balance.
Rails vs Cake is a fair comparison, as both are frameworks. Rack against PHP would be much closer.
Now, your turn. Why should I care about stock PHP? Why would I want to go back to not using a framework? Show me a PHP framework that's as fast as Rails, and I might be interested -- except, of course, Ruby is still a nicer language to work with.
Don't thank God, thank a doctor!
.... for an hour, right now.
They have tons to do with the real world. It means that, as a baseline, the machine in that benchmark will never run a CakePHP application faster than ~37 requests/s, which is pretty bloody slow.
Will a full fledged PHP app be slower than a hello world CakePHP app? Not even close, at least in my experience. For example, Game! runs in excess of 100 requests/s on the very modest hardware I mentioned above, and would likely be well over 300 requests/s on the 3 GHz machine in the benchmark I linked (assuming it's a single core, double that for a dual core), and it is most certainly more than hello world. It is, of course, written in stock PHP, not CakePHP.
The point of my post is that comparing to CakePHP is a lousy comparison, because a) CakePHP is a pretty minor player in the PHP world, and b) CakePHP is hideously slow. Honestly, I don't know how they managed to make CakePHP so slow, it's not even hard to write fast PHP code.
Oh, and here's the benchmark I was looking for earlier. Here we see CakePHP more than an order of magnitude slower than CodeIgniter, though IMO they're all too slow to consider. CakePHP in particular serves a dismal 7 requests/s, which (at least to me) isn't even acceptable for a single user.
The topic of framework vs no framework is another flamewar altogether, which I won't go into here.
Game! - Where the stick is mightier than the sword!
The point of my post is that comparing to CakePHP is a lousy comparison, because a) CakePHP is a pretty minor player in the PHP world, and b) CakePHP is hideously slow.
Point b, I could have made about Rails -- and it's still not as slow as you would think.
Since I can't get people to actually watch the presentation, let me quote from it:
331 requests per second in a raw PHP app. Static HTML was 1327 rps.
Cake was barely 8, with acceleration.
Ruby, with a single mongrel, was 85 rps. With Passenger and Enterprise Ruby, 96 rps. So already, Rails is close enough that, worst case, you would have to run it on two machines instead of one.
Merb, with templates, was over a thousand rps, looks like over twelve hundred from the graph. I believe this was a different machine than the above, but I don't believe it was four times faster. It is the same machine, though, which is used for the rest of this comment.
There is also a comparison of static vs just the Merb router -- obviously, static is faster, but not by a huge amount. Then there's the controller versus php's echo -- almost exactly the same. And of course, the template -- already a very MVC-ish design -- is already better, by quite a lot, than CodeIgniter, and not much slower than php's echo.
Sinatra was almost two thousand rps -- slightly faster than a Merb controller.
No matter how you look at these benchmarks, the worst you can say is, "Rails is slow", and it's still not that slow. There is no way you can say "Ruby is slow", and there is certainly no way you can say that Merb is slow.
Oh, and Merb is going to be merged into Rails. Merb 2.0 is Rails 3.0.
The topic of framework vs no framework is another flamewar altogether, which I won't go into here.
Fair enough. I think you will agree, though, that it's much fairer to compare frameworks to frameworks, and no-framework to no-framework, than it is to compare a Ruby framework to raw PHP. (Even if the Merb happens to be almost as fast as raw PHP, and sometimes faster.)
Don't thank God, thank a doctor!
> all those little hacks you avoid during
> development could suddenly mean thousands of dollars saved
Yeah, that's the stuff I'm thinking of. "We won't generate this on the fly, we'll put it in a queue and process the queue every 5 seconds." "We won't immediately write this to all the servers, instead we'll rsync it up in a batch job." I wouldn't even call those "little hacks"... I'd say that those are architecture decisions that you make once you realize you need them. And, as you say, until you need that sort of thing it's a waste of time to code it up... wait until you're sure you have customers, then do all that.
The Army reading list
The problem is amateurism.
Twitter is supposed to be rewritten (already has?) using a technology that is tested and proven. A technology that is involved, daily, for example, in every single money wire-transfer, in every credit card transaction, in every "e-wallet" (MoneyBookers, PayPal, you-name-it) transfer, etc.
There are technologies, today, that not only scale and are extremely performant, but that also are bullet-proof when it comes to security.
One such technology is called Java, and there hasn't been a single buffer overrun in a compliant JVM (the specs simply prevents it).
The problem is that some people are too shortsighted to realize how big Java is.
But GMail, FedEx, eBay... And all the banks worldwide heavily use (and save a lot of money thanks to) Java.
Java haters can keep using their toy technology, whose user base you can count on your fingers, and produce bug-ridden, non-scalable apps that shall need to be rewritten in Java once scalability, reliability and security becomes the name of the game.
Heck, even Paul Graham's very fine Lisp written Viacom was rewritten in Java.
Btw Java haters, you probably have Java smartcards in your wallet and you have to accept that you're using Java daily in the Real World [TM], where payments Just Works [TM].
Get a grip guys, seriously...
84 hours is not as devastating as it can sound.
If Google was shut down for 3.5 days in 2008 it would have cost them $209 million in revenue. A few more days of that and it might become real money.
How many lives will be seriously inconvenienced (much less endangered) by its downtime?
Lives won't but investments will be endangered and that does "seriously inconvenience" people. I present our current economy as Exhibit A. You think Google or Amazon or Yahoo would be the economic powerhouses they are if they were down for half a week per year? Customers wouldn't trust the service, investors would be wary, slashdot would bash them and they would all be right to do so. An internet site can't get revenue when it is shut down. It's a 24/7 business and the guys who run Twitter need to behave like they understand that if they have any aspirations of turning it into a real business.
That benchmark is useless. You are comparing an apple to an orange. We were talking about RUBY not RUBY+RAILS vs PHP+CakePHP(bloat). And CakePHP is known to be one of the slowest frameworks for PHP. A real benchmark would at least compare the same code (Yes, like a Fibonnacci) to test how the LANGUAGE and not the FRAMEWORK benchmarks.
Come back when you understand how benchmarks work Nuby.
This is my sig. There are many like it but this one is mine.
We were talking about RUBY not RUBY+RAILS vs PHP+CakePHP(bloat).
In that case, you might be interested in the examples using the Merb router, which is actually comparable to static content. This was compared to raw PHP, both with echo and with templates.
A real benchmark would at least compare the same code (Yes, like a Fibonnacci) to test how the LANGUAGE and not the FRAMEWORK benchmarks.
A Fibonacci is irrelevant -- when was the last time you used a Fibonacci in a commercial app?
These benchmarks are testing a real app. If that app ends up being written differently in the different languages, I would suggest that this is not necessarily bias, but quite possibly that one language lends itself to cleaner and more efficient code.
Again: Have you actually looked at those benchmarks? Or are you more interested in calling me names than you are in actual facts?
Don't thank God, thank a doctor!
Then sadly, you understand little about benchmarks. I could benchmark Microsoft Office against a Hello World app written in Perl too. Does it mean anything? It means the same as the benchmarks you pointed to. Because too much is going on in the backend to know what precisely you are benchmarking. This is WHY benchmarks are done wtih things like the fibonacci sequence... duh.
Seriously, you'll learn this when you get out of high school.
This is my sig. There are many like it but this one is mine.
I could benchmark Microsoft Office against a Hello World app written in Perl too.
Which is why it was Merb Router vs Raw PHP. More like Hello World in Ruby vs Hello World in Perl.
Except, of course, benchmarking Hello World is as irrelevant as benchmarking fibonacci.
Because too much is going on in the backend to know what precisely you are benchmarking.
Except that this is the same stuff that will be going on in the backend in a real app.
In other words, these are benchmarks of stuff that matter.
Seriously, you'll learn this when you get out of high school.
Has it occurred to you that I might know this from practical experience, designing real applications?
Nah, couldn't be. Obviously, I must be a high school kid, who knows nothing about the subject -- I mean, I disagree with you, isn't that proof enough? I bow to your superior ad-hominem skills.
Look to your own sig.
Don't thank God, thank a doctor!
LisaNova says Twitter is down.
Twitter stated that they simply did not plan ahead for the popularity of their service. Period. That is not the fault of the platform they use.
Not knowing the future is pretty much the rule, not the exception. If the framework or the way they employed it can't hold up to unexpected changes then that's a problem. Twitter has been around for a while now. I suspect that they knew they were getting popular. I don't know the true story, but if they are having a lot of down time they are probably doing something wrong.
Tools are tools. Maybe a rapid prototyping environment doesn't yield the most maintainable or re-purposable code. Or maybe it's fine and they just made bad choices. Or maybe it was just bad luck :)
Like I said... you understand very little about benchmarks. Probably even less about development.
This is my sig. There are many like it but this one is mine.