5 ms·

Especially given the fact that all of those MagLev claims went up in smoke...

by fiaz 18y ago

icey 18y ago
I don't understand what this has to do with MagLev. (And how did it go up in smoke? According to this http://maglev.gemstone.com/status/index.html http://maglev.gemstone.com/status/index.html it seems like it's still being worked on.)
- petercooper 18y ago
  I see it as related in a vaporware vs nonvaporware context. Rubyists have put up with quite a bit of vaporware lately, so it's remarkable that Phusion continue to deliver with Passenger without blowing smoke. (I'd also put JRuby in this small bucket.)
- fiaz 18y ago
  The point I was trying to make is that performance is the biggest issue with Ruby, and that is a hard issue to deny. MagLev was introduced with the promise of delivering this much needed performance. In relation to the comment to which I responded, I think it is a big boost to the Ruby community (especially the Rails community) that Passenger and Nginx are playing nicely with each other. Perhaps I shouldn't have been so bombastic in my statement that the MagLev claims have "gone up in smoke"...that's just my response to the fact that they have demonstrated some pretty amazing stuff but are a little short on delivery. To be clear Phusion's release today not only promises on a performance boost for Rails, but it also delivers it. Everybody is 100% right in pointing out that technically speaking, MagLev and Passenger/Nginx are totally separate technologies to solve separate problems, but the goals are the same in my view (delivering better performance for Ruby apps). So I don't think drawing an allusion to the MagLev promises of increased performance for Ruby is unwarranted in relation to what it would mean to the Ruby community at large.
  - gamache 18y ago
    For me, the big win of Passenger is freeing myself from manual administration of Rails apps. Any performance gain is secondary to the fact that I can drink beer while I rest assured my apps are being served.
    - fiaz 18y ago
      I totally agree with this sentiment...actually I've already decided to use Apache/Passenger for an app I'm releasing (hopefully soon for all to review). Today's announcement is really icing on the cake. My reasoning prior to today's announcement? The convenience of the deploy. The fact that I don't have to dive into Ebb/Thin/Mongrel and figure that out (probably easy for 99% of the people on this thread) means more time to think about other things. It's also exciting from the perspective that I'm interested in seeing what the Ebb/Thin/Mongrel teams are going to do. Competition is great!
      - eob 18y ago
        I'm with you man -- I consider myself a pretty good coder, but I'm a really crummy sysadmin. Trying to figure out how to configure Mongrel correctly has always been the worst part of Rails development for me, so Passenger is a welcome relief.
  - icey 18y ago
    I didn't think you were being bombastic; I just don't keep up to date with the goings-on of Ruby, so I thought I might have missed something. I do think it may be a bit premature to call MagLev vaporware though; it was only announced last year, no? Anyways, thank you for following up, it did help illustrate your point for me.
hboon 18y ago
Isn't that too early to conclude? And they are meant for different purposes anyway.
gnaritas 18y ago
MagLev is a Gemstone object database server, it has nothing to do with this. When it's done, I'm sure the combo will be Nginx + Maglev instead of Nginx + (phusion passenger + mysql). I've been playing with Gemstone and Seaside lately, it's freaking blazing fast and persistence is automatic, no mapping code at all. You put objects somewhere and they just stay there. No mapping at all beats the crap out of mappings + migrations. Gemstone is going to make one hell of a web app platform. Especially since you can just add more boxes to the db cluster for scaling it. Only one server can write, but reads are distributed automatically across all servers in the cluster.
- jules 18y ago
  How do they make Gemstone so fast? They have to track every assignment to every persistent object, right? How does Gemstone handle data that doesn't fit in memory?
  - gnaritas 18y ago
    > How do they make Gemstone so fast? Gemstone is like a smart memcached + relational db. They call it a shared page cache, but it's basically like memcached but not just a cache and with brains. A transaction commits through the cache to disk and the same object format is used by every layer removing the need to constantly re-serialize. The client talks to the cache, the cache talks to the back end store when it decides it needs to page something in. As for change tracking, I'm fairly certain there's a write barrier at the vm level, change anything and the barrier is broken causing the object to added to a commit list. As for larger than memory queries, no different than a relational store, you work in batches paging in data as necessary. If you're talking about a single transaction that modifies more than will fit in ram, I have no idea, I've never had to do something like that.
- hboon 18y ago
  There still is (and needs) the concept of migrations in Gemstone.
  - gnaritas 18y ago

Especially given the fact that all of those MagLev claims went up in smoke...

by fiaz 18y ago

Especially given the fact that all of those MagLev claims went up in smoke...

icey 18y ago

I don't understand what this has to do with MagLev. (And how did it go up in smoke? According to this http://maglev.gemstone.com/status/index.html http://maglev.gemstone.com/status/index.html it seems like it's still being worked on.)

petercooper 18y ago
I see it as related in a vaporware vs nonvaporware context. Rubyists have put up with quite a bit of vaporware lately, so it's remarkable that Phusion continue to deliver with Passenger without blowing smoke. (I'd also put JRuby in this small bucket.)
fiaz 18y ago
The point I was trying to make is that performance is the biggest issue with Ruby, and that is a hard issue to deny. MagLev was introduced with the promise of delivering this much needed performance. In relation to the comment to which I responded, I think it is a big boost to the Ruby community (especially the Rails community) that Passenger and Nginx are playing nicely with each other. Perhaps I shouldn't have been so bombastic in my statement that the MagLev claims have "gone up in smoke"...that's just my response to the fact that they have demonstrated some pretty amazing stuff but are a little short on delivery. To be clear Phusion's release today not only promises on a performance boost for Rails, but it also delivers it. Everybody is 100% right in pointing out that technically speaking, MagLev and Passenger/Nginx are totally separate technologies to solve separate problems, but the goals are the same in my view (delivering better performance for Ruby apps). So I don't think drawing an allusion to the MagLev promises of increased performance for Ruby is unwarranted in relation to what it would mean to the Ruby community at large.
- gamache 18y ago
  For me, the big win of Passenger is freeing myself from manual administration of Rails apps. Any performance gain is secondary to the fact that I can drink beer while I rest assured my apps are being served.
  - fiaz 18y ago
    I totally agree with this sentiment...actually I've already decided to use Apache/Passenger for an app I'm releasing (hopefully soon for all to review). Today's announcement is really icing on the cake. My reasoning prior to today's announcement? The convenience of the deploy. The fact that I don't have to dive into Ebb/Thin/Mongrel and figure that out (probably easy for 99% of the people on this thread) means more time to think about other things. It's also exciting from the perspective that I'm interested in seeing what the Ebb/Thin/Mongrel teams are going to do. Competition is great!
    - eob 18y ago
      I'm with you man -- I consider myself a pretty good coder, but I'm a really crummy sysadmin. Trying to figure out how to configure Mongrel correctly has always been the worst part of Rails development for me, so Passenger is a welcome relief.
- icey 18y ago
  I didn't think you were being bombastic; I just don't keep up to date with the goings-on of Ruby, so I thought I might have missed something. I do think it may be a bit premature to call MagLev vaporware though; it was only announced last year, no? Anyways, thank you for following up, it did help illustrate your point for me.

hboon 18y ago

Isn't that too early to conclude? And they are meant for different purposes anyway.

gnaritas 18y ago

MagLev is a Gemstone object database server, it has nothing to do with this. When it's done, I'm sure the combo will be Nginx + Maglev instead of Nginx + (phusion passenger + mysql). I've been playing with Gemstone and Seaside lately, it's freaking blazing fast and persistence is automatic, no mapping code at all. You put objects somewhere and they just stay there. No mapping at all beats the crap out of mappings + migrations. Gemstone is going to make one hell of a web app platform. Especially since you can just add more boxes to the db cluster for scaling it. Only one server can write, but reads are distributed automatically across all servers in the cluster.

jules 18y ago
How do they make Gemstone so fast? They have to track every assignment to every persistent object, right? How does Gemstone handle data that doesn't fit in memory?
- gnaritas 18y ago
  > How do they make Gemstone so fast? Gemstone is like a smart memcached + relational db. They call it a shared page cache, but it's basically like memcached but not just a cache and with brains. A transaction commits through the cache to disk and the same object format is used by every layer removing the need to constantly re-serialize. The client talks to the cache, the cache talks to the back end store when it decides it needs to page something in. As for change tracking, I'm fairly certain there's a write barrier at the vm level, change anything and the barrier is broken causing the object to added to a commit list. As for larger than memory queries, no different than a relational store, you work in batches paging in data as necessary. If you're talking about a single transaction that modifies more than will fit in ram, I have no idea, I've never had to do something like that.
hboon 18y ago
There still is (and needs) the concept of migrations in Gemstone.
- gnaritas 18y ago