The days of network being faster than disk are over.
Gig-E speed is about 30MB/s in the real world. This is with a crossover cable, machine to machine. I've tested and verified this over a number of platforms, including expensive server systems.
Cheap terabyte single disks these days can do 80MB/s.
The only reason to go with raid is for redundancy, or better handling of simultaneous connections.
That USED to be true. It's not the hard drive, all the layers that get put in between when you access a disk over the network. Modern hard drives can easily do 60MB/s sustained.
For instance, I have a couple raid6 arrays which clock in at about 250 MB/s and 150MB/s natively. If I hook that machine up directly to another machine's ethernet port I only get about 30MB/s sharing the device w/ iSCSI. SMB and NFS yield similar results. This is true even though I can get over 900Mbps using iperf.
Sharing disks over gig-e sucks when you actually need throughput. It's great for when you just need to expand a SAN and speed is secondary. I've heard that bonding two Gig-e cards doesn't realize much of an improvement FWIW, so I assume latency is part of the reason it's slower.
You can't put a whole country behind one public IP because of port starvation. All those people will need multiple ports for their connections, even some large organizations experience this problem!
IPv4/nat multiplexes multiple users through the port range, so 64k divided by 300 parallel connections results in ~200 customers per ISP based nat address (assuming each customer is only allowed to run one simultaneous instance of iTunes or similar apps).
Good point, that's why App Armor and VMs are critical.
However, you need to be prepared to say what stuff is worth all that extra work too. I don't have the time to isolate everything exactly as I'd like and maintain it, but that's where the art comes in I suppose. You have to triage security, I'd love to analyze tripwire logs every day (well not really) but I just don't have the time to do it for anything but a few key systems.
Now, if he's just running a LAMP stack, he probably won't get owned that fast, if at all. I would recommend he signs up to his OS's security mailing list, and to the mailing lists for any apps he runs that are exposed to the net.
Also, firewalls are overrated to a certain extent, most services can be set to only listen on 127.0.0.1 exclusively if necessary. This is especially true in a LAMP stack. I mean, if the attacker already has the ability to turn on a service that wasn't there before you're already PWNed. The real benefit of a firewall is restricting IP ranges, connection rates and the like.
Re:Windows does not fork
on
Chrome Vs. IE 8
·
· Score: 2, Interesting
It looks like it would be a huge PITA to get it to work like fork on unix. It sounds like even if you can get windows to fork, microsoft seems hell bent on you not doing it, otherwise why would it be so hard?
It sounds like on Win32 you don't get the automatic memory efficiency of fork(), but rather you have to be explicit about all shared memory. It seems to me, with the easy of fork()'s CoW capabilities gone, it be easier to just use threads. Once again however, I'm not a windows programmer really.
Windows does not fork
on
Chrome Vs. IE 8
·
· Score: 3, Insightful
As I understand it, windows tends to use threads in lieu of forked processes. You can use multiple processes with any kind of IPC you want, but windows won't have anything to do with them sharing memory.
I am not an expert win32 programmer however, I do know for a fact fork() is not supported, and so far as I know this means there's no way to do copy on write either.
Docs are good for when you want to know how something works in a specific way. They SUCK for the big picture.
If you want to know how ping works, read man ping and the ICMP spec. If you want to know how networking works, you can't just read a bunch of man pages.
Longer form works are necessary because they include real world experiences and tactics. The documentation for this stuff usually resides in books. The good news is, lots of these books are published free online. In fact, a lot of the online docs for programming languages are published books that are also free online.
Waterboarding might not be a walk in the park, but it's been applied to three people who were known to be high-level terrorists. We got information from them.
The problem is that torture is only torture. Numerous studies show that answers given under that kind of duress are useless.
So let me get this straight, the share holders want google to allow backscatter spam?
allow backscatter spam
???
profit!
Finally, a voice of reason in this thread. I can't imagine why anyone would think this is part of some diabolical plot. I fuck up at my job sometimes, so does google, why does it have to be a conspiracy when it's a big company?
I forget who said "Never attribute to malice that which can be adequately explained by stupidity." but I think that applies here.
One small problem is that ruby is not copy-on-write friendly, forked processes dirty up pages and lose the memory savings, there's a bunch of posts over at: http://izumi.plan99.net/blog/ explaining the issue, he also has a few patched to ruby to fix this. I don't know if YARV or Rubinius are going to fix this in release versions in the future.
Threads workaround
on
Advanced Rails
·
· Score: 2, Informative
It aint pretty, but you can work around the lack of multi-threading with file uploads just fine using merb as a companion to rails. You can share all ORM stuff with Merb and you'll be fine. Not as pretty, but doable. Also, I don't see why a multi-process model is harder to administrate than a multi-threaded one.
Yes, it takes more effort to set up, but that also makes it really easy to scale since the component parts of a Rails deployment (Load Balancer / Web Server / App Server / DB Server) are each very scalable as isolated parts.
I'm envisioning a sensible sort of preload program in gentoo right now:
*Preloading commonly used data, libraries, and binaries... gcc OK make OK libc-dev OK... *snip*... emerge OK kernel-src OK *Preload done, 3827K of USE Flags, 2TB of source code, and one compiler, and firefox to surf forums.gentoo.org for better use flags while you compile loaded into main memory
First off, I think you read the quoted text in the article AS the article since Jeff Atwood doesn't really talk about rails much at all in his actual comments. I think you actually agree with his point. He even says that since the problems they're having are mostly centered around the their DB the programming language probably doesn't even matter.
I was just responding to you closing with "It's the programmer that creates slow, unreadable code, not the language." That's a fairly useless statement to make if you have to qualify it so much. What you meant to say was that sometimes using the fastest algorithm means using a slower language due to development time constraints, and that sometimes, this can produce a faster application, even when using a slower language. That's a far cry from saying that bad programming is the only speed constraint, because really, that's what that statement says. Sure, if you read some of the preceding paragraphs you would realize there were qualifications to that, but the qualifications are so huge that the statement loses all value.
Really though, this is just quibbling over language. I simply think you were playing fast and loose with language, trying to take a nuanced point and turn it into a sexy soundbite, even when it didn't really fit the bill. I think we agree on the substance of this issue, I just take issue with your saying things which even you don't agree with.
Lastly, about the benchmarks, I don't want to get into a language holy war, but the gist of what Jeff Atwood says is still true: "...interpreted languages are so slow that if you have to ask how much performance you're giving up, you can't afford it...".
Yeah, and it's fixed now. Getting rails running when it was brand spankin new was damn hard. Deployment sucked. This is entirely true. But today that's just not the case. The balanced mongrel cluster I run at my office has never gone except for reboots. Thanks for writing mongrel zed! Problem solved!
To get an idea of what's wrong with Zed, who is an awesome programmer with an obvious ego problem, check out his project Utu. I'll save you the trouble of clicking and just post the first line on the site "The Internet needs more hate. Much more." While the tech is fascinating, it's pretty disturbing when you read the vitriolic reasoning underpinning it and realize how much effort he's put into this.
I found Zed's post yesterday by the way, and consciously decided NOT to post it to Slashdot even though I knew I'd see it here within a couple days because it's NOT NEWSWORTHY. As many people have noted above, him getting pissed off about the people he's worked with. He's obviously not comfortable unless he's doing something different like when he talks about Ragel State Machines and gleefully demonstrates that Rick Olsen doesn't understand Ragel after a quick intro to it (it's in the middle of the document). Zed's a bright guy, but a lot of these people, like Rick Olsen have contributed TONS of high quality code to the community.
Are we really supposed to believe, that this incredibly smart programmer latched onto a technology that is a piece of crap and stayed there for as long as he did without thinking it had merit? His best argument against rails, about DHH having to restart his site 400 times a day is now a non-issue thanks to the software he wrote to fix it. And that portion of the software really had little to do with rails per-se, but rather how rails interfaces with Apache (FastCGI had tons of issues). All it proves is that DHH and the rails core at the time did a shitty job integrating the framework into the web-server, nothing more.
Really, this is just a tragedy, Zed's a smart, incredibly talented person, who just can't handle people, and wound up in some bad situations. It's a loss for the Rails community, but the problem isn't rails, it's Zed.
This story is nothing new. What's really needed is a clarification of terms.
I have RSI (Repetitive Stress Injuries) and my carpal tunnel is just fine. It's the other nerves, tendons, and muscles of my hands which ache and cause the severe pain. If you try and explain this to people they just say 'Carpal Tunnel Syndrome' unless they're a doctor. Computer use DOES cause RSI which is the real problem, and a really painful and dangerous thing. Other tasks, sewing for instance, can also cause RSI. The phenomenon is not new.
How the carpal tunnel got so famous I don't know, but the term has stuck.
PHP is comparable to Ruby or ModRuby. Ruby on Rails is a framework.
Of course there's no scaling issues with these languages because they're just programming languages. Things like load balancing are something YOU have to take into account as you build your website and manually handle. You can architect things anyway you want, so if stuff fails it's your fault. This means DB transactions, sessions, templating, etc. are all things you have to handle. The language can't be at fault for these things.
Ruby on Rails is slower for many things because it saves you upfront development time and makes refactoring and adding features a breeze. For many people this is perfectly fine. I write intranet apps for my company in RoR all the time, and it's great. We do not handle many users, but we DO care about getting functionality fast.
Also, for some ridiculous reason people seem to think that RoR does not scale because an out of the box RoR stack may not scale perfectly (like Twitter). RoR may be slower than a tuned PHP script in some cases, but it scales horizontally just fine.
Lots of people may think Twitter and say RoR doesn't scale. But what they don't know is that twitter didn't scale because their DB didn't scale to handle that many writes. You can always throw more boxen at rails and get a larger pool of Rails processes to distribute the load to. You can throw Memcached at it to speed up queries as well, but at the time the whole Twitter complaint happened Rails only supported one database connection. This was fixed soon after. The fact is though, that once you have a service with so many reads and writes like twitter, out of the box ANYTHING is going to suck. Rails, however, gained the necessary functionality (Magic Multiconnections) and allows for all the custom tweaks, performancing tuning, and caching you'll need.
To be fair, he said a 60 machine cluster would be 10x overkill.
That being said, this argument's apples and oranges. It really depends on what applications you're running, which is totally missing from this discussion.
What a coincidence:) Well, thanks for pointing it out. I've read a number of articles on putting together rails stacks and yours is the first to suggest forking. Next time I deploy a new app I just may try some of the stuff you've suggested.
By the way, great work on the blog, I like how comprehensive your posts are.
Good point wrt copy on write. The most common methods of deploying rails (with mongrel_cluster) do not use fork() but I just found this article on doing so if anyone's interested in it. http://izumi.plan99.net/blog/?p=19
I would like to say for the record, that I didn't say that FastCGI ran apps inside apache, I don't know where you got that from.
Slashdot Mirror
The days of network being faster than disk are over.
Gig-E speed is about 30MB/s in the real world. This is with a crossover cable, machine to machine. I've tested and verified this over a number of platforms, including expensive server systems.
Cheap terabyte single disks these days can do 80MB/s.
The only reason to go with raid is for redundancy, or better handling of simultaneous connections.
Read this for a more in depth analysis: http://www.codinghorror.com/blog/archives/000339.html
That USED to be true. It's not the hard drive, all the layers that get put in between when you access a disk over the network. Modern hard drives can easily do 60MB/s sustained.
For instance, I have a couple raid6 arrays which clock in at about 250 MB/s and 150MB/s natively. If I hook that machine up directly to another machine's ethernet port I only get about 30MB/s sharing the device w/ iSCSI. SMB and NFS yield similar results. This is true even though I can get over 900Mbps using iperf.
Sharing disks over gig-e sucks when you actually need throughput. It's great for when you just need to expand a SAN and speed is secondary. I've heard that bonding two Gig-e cards doesn't realize much of an improvement FWIW, so I assume latency is part of the reason it's slower.
Maybe some people just have a problem wasting money?
Oops, the link is www.ipv6.org.tw/summit2008/doc/1-2-2.pdf
You can't put a whole country behind one public IP because of port starvation. All those people will need multiple ports for their connections, even some large organizations experience this problem!
According to this :
Good point, that's why App Armor and VMs are critical.
However, you need to be prepared to say what stuff is worth all that extra work too. I don't have the time to isolate everything exactly as I'd like and maintain it, but that's where the art comes in I suppose. You have to triage security, I'd love to analyze tripwire logs every day (well not really) but I just don't have the time to do it for anything but a few key systems.
Now, if he's just running a LAMP stack, he probably won't get owned that fast, if at all. I would recommend he signs up to his OS's security mailing list, and to the mailing lists for any apps he runs that are exposed to the net.
Also, firewalls are overrated to a certain extent, most services can be set to only listen on 127.0.0.1 exclusively if necessary. This is especially true in a LAMP stack. I mean, if the attacker already has the ability to turn on a service that wasn't there before you're already PWNed. The real benefit of a firewall is restricting IP ranges, connection rates and the like.
Cool, but according to this discussion: http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.kernel/2008-04/msg00272.html
It looks like it would be a huge PITA to get it to work like fork on unix. It sounds like even if you can get windows to fork, microsoft seems hell bent on you not doing it, otherwise why would it be so hard?
It sounds like on Win32 you don't get the automatic memory efficiency of fork(), but rather you have to be explicit about all shared memory. It seems to me, with the easy of fork()'s CoW capabilities gone, it be easier to just use threads. Once again however, I'm not a windows programmer really.
As I understand it, windows tends to use threads in lieu of forked processes. You can use multiple processes with any kind of IPC you want, but windows won't have anything to do with them sharing memory.
I am not an expert win32 programmer however, I do know for a fact fork() is not supported, and so far as I know this means there's no way to do copy on write either.
Docs are good for when you want to know how something works in a specific way. They SUCK for the big picture.
If you want to know how ping works, read man ping and the ICMP spec. If you want to know how networking works, you can't just read a bunch of man pages.
Longer form works are necessary because they include real world experiences and tactics. The documentation for this stuff usually resides in books. The good news is, lots of these books are published free online. In fact, a lot of the online docs for programming languages are published books that are also free online.
Waterboarding might not be a walk in the park, but it's been applied to three people who were known to be high-level terrorists. We got information from them.
The problem is that torture is only torture. Numerous studies show that answers given under that kind of duress are useless.
- allow backscatter spam
- ???
- profit!
Finally, a voice of reason in this thread. I can't imagine why anyone would think this is part of some diabolical plot. I fuck up at my job sometimes, so does google, why does it have to be a conspiracy when it's a big company?I forget who said "Never attribute to malice that which can be adequately explained by stupidity." but I think that applies here.
One small problem is that ruby is not copy-on-write friendly, forked processes dirty up pages and lose the memory savings, there's a bunch of posts over at: http://izumi.plan99.net/blog/ explaining the issue, he also has a few patched to ruby to fix this. I don't know if YARV or Rubinius are going to fix this in release versions in the future.
It aint pretty, but you can work around the lack of multi-threading with file uploads just fine using merb as a companion to rails. You can share all ORM stuff with Merb and you'll be fine. Not as pretty, but doable. Also, I don't see why a multi-process model is harder to administrate than a multi-threaded one.
Yes, it takes more effort to set up, but that also makes it really easy to scale since the component parts of a Rails deployment (Load Balancer / Web Server / App Server / DB Server) are each very scalable as isolated parts.
I'm envisioning a sensible sort of preload program in gentoo right now:
... *snip* ...
*Preloading commonly used data, libraries, and binaries...
gcc OK
make OK
libc-dev OK
emerge OK
kernel-src OK
*Preload done, 3827K of USE Flags, 2TB of source code, and one compiler, and firefox to surf forums.gentoo.org for better use flags while you compile loaded into main memory
First off, I think you read the quoted text in the article AS the article since Jeff Atwood doesn't really talk about rails much at all in his actual comments. I think you actually agree with his point. He even says that since the problems they're having are mostly centered around the their DB the programming language probably doesn't even matter.
I was just responding to you closing with "It's the programmer that creates slow, unreadable code, not the language." That's a fairly useless statement to make if you have to qualify it so much. What you meant to say was that sometimes using the fastest algorithm means using a slower language due to development time constraints, and that sometimes, this can produce a faster application, even when using a slower language. That's a far cry from saying that bad programming is the only speed constraint, because really, that's what that statement says. Sure, if you read some of the preceding paragraphs you would realize there were qualifications to that, but the qualifications are so huge that the statement loses all value.
Really though, this is just quibbling over language. I simply think you were playing fast and loose with language, trying to take a nuanced point and turn it into a sexy soundbite, even when it didn't really fit the bill. I think we agree on the substance of this issue, I just take issue with your saying things which even you don't agree with.
Lastly, about the benchmarks, I don't want to get into a language holy war, but the gist of what Jeff Atwood says is still true: "...interpreted languages are so slow that if you have to ask how much performance you're giving up, you can't afford it...".
Sorry, but language still makes a difference.
http://www.codinghorror.com/blog/archives/000838.html
C++ Compiled 1:1
Visual Basic Compiled 1:1
C# Compiled 1:1
Java Byte code 1.5:1
PHP Interpreted > 100:1
Python Interpreted > 100:1
Yeah, and it's fixed now. Getting rails running when it was brand spankin new was damn hard. Deployment sucked. This is entirely true. But today that's just not the case. The balanced mongrel cluster I run at my office has never gone except for reboots. Thanks for writing mongrel zed! Problem solved!
To get an idea of what's wrong with Zed, who is an awesome programmer with an obvious ego problem, check out his project Utu. I'll save you the trouble of clicking and just post the first line on the site "The Internet needs more hate. Much more." While the tech is fascinating, it's pretty disturbing when you read the vitriolic reasoning underpinning it and realize how much effort he's put into this.
I found Zed's post yesterday by the way, and consciously decided NOT to post it to Slashdot even though I knew I'd see it here within a couple days because it's NOT NEWSWORTHY. As many people have noted above, him getting pissed off about the people he's worked with. He's obviously not comfortable unless he's doing something different like when he talks about Ragel State Machines and gleefully demonstrates that Rick Olsen doesn't understand Ragel after a quick intro to it (it's in the middle of the document). Zed's a bright guy, but a lot of these people, like Rick Olsen have contributed TONS of high quality code to the community.
Are we really supposed to believe, that this incredibly smart programmer latched onto a technology that is a piece of crap and stayed there for as long as he did without thinking it had merit? His best argument against rails, about DHH having to restart his site 400 times a day is now a non-issue thanks to the software he wrote to fix it. And that portion of the software really had little to do with rails per-se, but rather how rails interfaces with Apache (FastCGI had tons of issues). All it proves is that DHH and the rails core at the time did a shitty job integrating the framework into the web-server, nothing more.
Really, this is just a tragedy, Zed's a smart, incredibly talented person, who just can't handle people, and wound up in some bad situations. It's a loss for the Rails community, but the problem isn't rails, it's Zed.
This story is nothing new. What's really needed is a clarification of terms.
I have RSI (Repetitive Stress Injuries) and my carpal tunnel is just fine. It's the other nerves, tendons, and muscles of my hands which ache and cause the severe pain. If you try and explain this to people they just say 'Carpal Tunnel Syndrome' unless they're a doctor. Computer use DOES cause RSI which is the real problem, and a really painful and dangerous thing. Other tasks, sewing for instance, can also cause RSI. The phenomenon is not new.
How the carpal tunnel got so famous I don't know, but the term has stuck.
You're totally off base but so is this article.
PHP is comparable to Ruby or ModRuby. Ruby on Rails is a framework.
Of course there's no scaling issues with these languages because they're just programming languages. Things like load balancing are something YOU have to take into account as you build your website and manually handle. You can architect things anyway you want, so if stuff fails it's your fault. This means DB transactions, sessions, templating, etc. are all things you have to handle. The language can't be at fault for these things.
Ruby on Rails is slower for many things because it saves you upfront development time and makes refactoring and adding features a breeze. For many people this is perfectly fine. I write intranet apps for my company in RoR all the time, and it's great. We do not handle many users, but we DO care about getting functionality fast.
Also, for some ridiculous reason people seem to think that RoR does not scale because an out of the box RoR stack may not scale perfectly (like Twitter). RoR may be slower than a tuned PHP script in some cases, but it scales horizontally just fine.
Lots of people may think Twitter and say RoR doesn't scale. But what they don't know is that twitter didn't scale because their DB didn't scale to handle that many writes. You can always throw more boxen at rails and get a larger pool of Rails processes to distribute the load to. You can throw Memcached at it to speed up queries as well, but at the time the whole Twitter complaint happened Rails only supported one database connection. This was fixed soon after. The fact is though, that once you have a service with so many reads and writes like twitter, out of the box ANYTHING is going to suck. Rails, however, gained the necessary functionality (Magic Multiconnections) and allows for all the custom tweaks, performancing tuning, and caching you'll need.
Why worry? If you've got enough time to post stories to Slashdot you're clearly very efficient.
To be fair, he said a 60 machine cluster would be 10x overkill.
That being said, this argument's apples and oranges. It really depends on what applications you're running, which is totally missing from this discussion.
What a coincidence :) Well, thanks for pointing it out. I've read a number of articles on putting together rails stacks and yours is the first to suggest forking. Next time I deploy a new app I just may try some of the stuff you've suggested.
By the way, great work on the blog, I like how comprehensive your posts are.
Good point wrt copy on write. The most common methods of deploying rails (with mongrel_cluster) do not use fork() but I just found this article on doing so if anyone's interested in it. http://izumi.plan99.net/blog/?p=19
I would like to say for the record, that I didn't say that FastCGI ran apps inside apache, I don't know where you got that from.