I''ve liked the scgi runner ever since it came out. I like the way it''scontrolled, the way it''s clusterable, and the fact that it runs onwin32 platforms so easily. Now it''s May 2006, and the scgi runner hasn''t changed since October,and now we have mongrel. I keep seeing hints of clustering in mongrel,as well. I just downloaded the win32 installer for Apache 2.2.2 also,so I should be able to use the new proxy stuff as well. OK, now we''retalkin''. So, which is better? Which is more stable? Which is more scalable?Will mongrel be as cross-platform stable as scgi has proven to be?Which platform is more likely to handle 20+ million dynamic pages perday - mod_scgi + clustered scgi runners, or apache 2.2 proxy and afarm (pack?) of mongrels? --Cheers, Kevin
Hey Kevin, In general I try to steer people toward Mongrel for three reasons: 1) Mongrel is extensible. You can add your own handlers which is a major advancement over fastcgi and scgi. This lets you speed up actions which are too slow under rails by moving them out to Mongrel handlers, but it is more difficult. 2) SCGI hasn''t been worked on (by me) in a while, and will most likely get a big clean-up soon. I''ve got limited bandwidth for projects, and Mongrel is getting real attention (and _cash_ :-) so that''s where most of the innovation is going. I am going to keep SCGI alive since it''s pure Ruby and there might be folks who just can''t run Mongrel. 3) Mongrel is easier to deploy in most other environments. See, SCGI is great and all, but there''s like 3 web servers that support that protocol and there''s no decent load balancers, firewalls, proxies, etc. Mongrel is HTTP so it can be deployed on a cheese sandwich in the back of a truck (meaning anywhere). More answers below... On Wed, 2006-05-10 at 08:52 -0600, Kevin Williams wrote:> So, which is better?Right now I''d say Mongrel simply because it has better win32 support, is extensible with plugins and handlers, and it gets more attention from me.> Which is more stable?I''d say Mongrel is more stable because I do this "Iron Mongrel" thing where I give it regular code audits, attack it with attack tools and protocol fuzzing, and just generally try to destroy it. Here''s more on that: http://mongrel.rubyforge.org/security.html> Which is more scalable?First, let''s make sure we are clear: when I say "scalable" I mean "Which one can I expand easily to meet new demand." Hopefully you don''t mean "performance". Because that''d be really annoying. :-) Mongrel is more scalable because of just one word: HTTP. You can put it behind many professional load balancers, reverse proxies, web servers, and even run it standalone. There isn''t a performance difference, and with the proper conditional responses and native page caching support it''s actually faster than SCGI in many requests.> Will mongrel be as cross-platform stable as scgi has proven to be?No, this is why I''m still keep SCGI around. Since SCGI is pure Ruby it will be the last bastion for people who can''t compile extensions *or* can''t use an LGPL project (of course of those folks are thieves who take the work and don''t contribute back, but oh well). Mongrel has built on every platform except maybe AIX. And it runs the same on all of them, with win32 needing extra stuff because it doesn''t support daemon processes.> Which platform is more likely to handle 20+ million dynamic pages perday - mod_scgi + clustered scgi runners,That comes down to and estimated 231 requests/second and I''ve done that on Mongrel with a bit of hardware. What you''ll have to do with *any* Rails application is use httperf to measure different pages people will access. Then create a single machine that replicates your proposed deployment. Once you have this you need to use httperf to test that this proposed deployment is as fast as you had in your initial tests. Now that you''ve got thing worked out on the proposed deployment, you need to work to tune it to as fast as you can get it. This will take doing page caching, fragment caching, database query tuning, database object caching, and finally moving what you can out of Rails and into Mongrel. Once you''ve got the box as fast as you can get it, and you''ve played with the number of Mongrels that gives you the sweet spot, you then just need to buy the right amount of hardware and a good load balancer to meet your needs. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/
Zed, Thanks for the detailed answer! My only remaining concern in the claimthat Mongrel has better win32 support. Right now, today, I can''t usethe 1.8.4 Ruby installer due to issues with a native extension. Thisleaves me without Mongrel on win32. A pedantic technicality, for sure,but that''s my current state of affairs. It will be fixed shortly, sothis is only temporary anyway. Keep up the great work! If it weren''t for Mongrel and SCGI, I wouldn''thave much ammunition when evangelizing Rails to my ".NET Architect"friends - yes, they use words like "scale" and "enterprise", butthey''re my friends anyway. ;) Thanks again. Cheers, Kevin On 5/10/06, Zed Shaw <zedshaw at zedshaw.com> wrote:> Hey Kevin,>> In general I try to steer people toward Mongrel for three reasons:>> 1) Mongrel is extensible. You can add your own handlers which is a> major advancement over fastcgi and scgi. This lets you speed up actions> which are too slow under rails by moving them out to Mongrel handlers,> but it is more difficult.>> 2) SCGI hasn''t been worked on (by me) in a while, and will most likely> get a big clean-up soon. I''ve got limited bandwidth for projects, and> Mongrel is getting real attention (and _cash_ :-) so that''s where most> of the innovation is going. I am going to keep SCGI alive since it''s> pure Ruby and there might be folks who just can''t run Mongrel.>> 3) Mongrel is easier to deploy in most other environments. See, SCGI is> great and all, but there''s like 3 web servers that support that protocol> and there''s no decent load balancers, firewalls, proxies, etc. Mongrel> is HTTP so it can be deployed on a cheese sandwich in the back of a> truck (meaning anywhere).>> More answers below...>> On Wed, 2006-05-10 at 08:52 -0600, Kevin Williams wrote:>> > So, which is better?>> Right now I''d say Mongrel simply because it has better win32 support, is> extensible with plugins and handlers, and it gets more attention from> me.>> > Which is more stable?>> I''d say Mongrel is more stable because I do this "Iron Mongrel" thing> where I give it regular code audits, attack it with attack tools and> protocol fuzzing, and just generally try to destroy it. Here''s more on> that:>> http://mongrel.rubyforge.org/security.html>> > Which is more scalable?>> First, let''s make sure we are clear: when I say "scalable" I mean> "Which one can I expand easily to meet new demand." Hopefully you don''t> mean "performance". Because that''d be really annoying. :-)>> Mongrel is more scalable because of just one word: HTTP. You can put> it behind many professional load balancers, reverse proxies, web> servers, and even run it standalone. There isn''t a performance> difference, and with the proper conditional responses and native page> caching support it''s actually faster than SCGI in many requests.>> > Will mongrel be as cross-platform stable as scgi has proven to be?>> No, this is why I''m still keep SCGI around. Since SCGI is pure Ruby it> will be the last bastion for people who can''t compile extensions *or*> can''t use an LGPL project (of course of those folks are thieves who take> the work and don''t contribute back, but oh well).>> Mongrel has built on every platform except maybe AIX. And it runs the> same on all of them, with win32 needing extra stuff because it doesn''t> support daemon processes.>> > Which platform is more likely to handle 20+ million dynamic pages perday - mod_scgi + clustered scgi runners,>> That comes down to and estimated 231 requests/second and I''ve done that> on Mongrel with a bit of hardware.>> What you''ll have to do with *any* Rails application is use httperf to> measure different pages people will access. Then create a single> machine that replicates your proposed deployment. Once you have this> you need to use httperf to test that this proposed deployment is as fast> as you had in your initial tests.>> Now that you''ve got thing worked out on the proposed deployment, you> need to work to tune it to as fast as you can get it. This will take> doing page caching, fragment caching, database query tuning, database> object caching, and finally moving what you can out of Rails and into> Mongrel.>> Once you''ve got the box as fast as you can get it, and you''ve played> with the number of Mongrels that gives you the sweet spot, you then just> need to buy the right amount of hardware and a good load balancer to> meet your needs.>>> --> Zed A. Shaw> http://www.zedshaw.com/> http://mongrel.rubyforge.org/>>> _______________________________________________> Mongrel-users mailing list> Mongrel-users at rubyforge.org> http://rubyforge.org/mailman/listinfo/mongrel-users>
On 5/10/06, Kevin Williams <kevwil at gmail.com> wrote:> Zed, > Thanks for the detailed answer! My only remaining concern in the claimthat Mongrel has better win32 support. Right now, today, I can''t usethe 1.8.4 Ruby installer due to issues with a native extension. Thisleaves me without Mongrel on win32. A pedantic technicality, for sure,but that''s my current state of affairs. It will be fixed shortly, sothis is only temporary anyway.Hello Kevin, Maybe I''m out the loop, but could you tell me (info or links) with details about the native extensions problems with 1.8.4? (my guess you''re talking about Curt Hibbs One-Click-Installer). So far, the mongrel win32 gem was compiled with VC 7.1, which proven to be compatible with the VC6 ruby-win32 builds made officially. As I don''t use the installer from Curt, couldn''t talk about it. Your feedback is very welcome, more in this rewrite state of the win32 side. Later, Luis
The extension problem is the mysql extension doesn''t build on thecurrent 1.8.4 One Click Installer when using the same process from the1.8.2 gem build (http://rubyforge.org/projects/mysql-win). I''m workingwith Curt and a few others to figure out why. I wasn''t referring tothe Mongrel extension. On 5/10/06, Luis Lavena <luislavena at gmail.com> wrote:> On 5/10/06, Kevin Williams <kevwil at gmail.com> wrote:> > Zed,> > Thanks for the detailed answer! My only remaining concern in the claimthat Mongrel has better win32 support. Right now, today, I can''t usethe 1.8.4 Ruby installer due to issues with a native extension. Thisleaves me without Mongrel on win32. A pedantic technicality, for sure,but that''s my current state of affairs. It will be fixed shortly, sothis is only temporary anyway.>> Hello Kevin,>> Maybe I''m out the loop, but could you tell me (info or links) with> details about the native extensions problems with 1.8.4? (my guess> you''re talking about Curt Hibbs One-Click-Installer).>> So far, the mongrel win32 gem was compiled with VC 7.1, which proven> to be compatible with the VC6 ruby-win32 builds made officially.>> As I don''t use the installer from Curt, couldn''t talk about it.>> Your feedback is very welcome, more in this rewrite state of the win32 side.>> Later,>> Luis>> _______________________________________________> Mongrel-users mailing list> Mongrel-users at rubyforge.org> http://rubyforge.org/mailman/listinfo/mongrel-users> --Cheers, Kevin "Picking fights with people smarter than youis great - you always end up learning something."- jcooney.net
On 5/10/06, Kevin Williams <kevwil at gmail.com> wrote:> The extension problem is the mysql extension doesn''t build on thecurrent 1.8.4 One Click Installer when using the same process from the1.8.2 gem build (http://rubyforge.org/projects/mysql-win). I''m workingwith Curt and a few others to figure out why. I wasn''t referring tothe Mongrel extension.Kevin, I used the plain ruby-mswin32, even the new stable snapshot. Based on your problems, I do the following: * checkout out mysql-win trunk (guess is where the code you and Curt are working on). * added to includes mysql-5.0.21-win32\include * added to lib mysql-5.0.21-win32\lib\opt (Because I don''t use mysql, download the 39MB no installer available on their site). * next I do was go to the ext/ folder of mysql-win (rake compile rejected generate the makefile) Anyway, inside ext/, run:>ruby extconf.rbchecking for mysql.h... yes checking for mysql_query() in libmysql.lib... yes checking for mysql_ssl_set()... no creating Makefile>nmakeMicrosoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. C:\Ruby\bin\ruby -e "puts ''EXPORTS'', ''Init_mysql''" > mysql-i386-mswin32.def cl -nologo -MD -Zi -O2b2xg- -G6 -I. -IC:/Ruby/lib/ruby/1.8/i386-mswin32 -IC:/Ruby/lib/ruby/1.8/i386-mswin32 -I. -DHAVE_MYSQL_H -c -Tcmysql.c mysql.c d:\programming\sources\ruby\extensions\mysql-win\ext\mysql.c(1703) : warning C4716: ''time_initialize'' : must return a value cl -nologo -LD -Femysql.so mysql.obj msvcrt-ruby18.lib libmysql.lib oldnames.lib user32.lib advapi32.lib wsock32.lib -link -incremental:no -debug -opt:ref -opt:icf -dll -libpath:"C:/Ruby/lib" -def:mysql-i386-mswin32.def -implib:mysql-i386-mswin32.lib -pdb:mysql-i386-mswin32.pdb Creating library mysql-i386-mswin32.lib and object mysql-i386-mswin32.exp ==== * Next I needed to modify the require line in the test file. from: require "./mysql.o" to: require "./mysql.so" That typo is important, there is not .o file in win32, and in linux are object files, not shared objects (or dll as win32). * Run the test.rb agains my local MySQL - 5.0.20-community Attached are the failures reported against empty test database. My build environment is: cl: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. lib: Microsoft (R) Library Manager Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. nmake: Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. Platform SDK: Windows Server 2003 SP1 SDK Release Hope this information is helpful. Any hel I could provide, just mail me. Regards, Luis -------------- next part -------------- Loaded suite test Started ..................F......................................FFF......F.................F...............F......... Finished in 1.993 seconds. 1) Failure: test_sqlstate(TC_Mysql2) [test.rb:154]: <"00000"> expected but was <"HY000">. 2) Failure: test_fetch_bigint(TC_MysqlStmt2) [test.rb:799]: <[-1]> expected but was <[9223372036854775807]>. 3) Failure: test_fetch_bigint_unsigned(TC_MysqlStmt2) [test.rb:812]: <[-1]> expected but was <[0]>. 4) Failure: test_fetch_binary(TC_MysqlStmt2) [test.rb:1009]: <["abc"]> expected but was <["abc\000\000\000\000\000\000\000"]>. 5) Failure: test_fetch_double(TC_MysqlStmt2) [test.rb:860]: <-1.79769313486232e+308> expected but was <-1.79769313486232e+308>. 6) Failure: test_fetch_timestamp(TC_MysqlStmt2) [test.rb:950]: <[#<Mysql::Time:2037-12-31 23:59:59>]> expected but was <[#<Mysql::Time:0000-00-00 00:00:00>]>. 7) Failure: test_sqlstate(TC_MysqlStmt2) [test.rb:1280]: <""> expected but was <"00000">. 110 tests, 340 assertions, 7 failures, 0 errors
As a note, I''ll like to add: Using Dependency Walker, both MSVCRT-RUBY18.dll and the built mysql.so links against MSVCRT.DLL, which is default version 7.0.2600.2180 on XP. For the failures reported, as I don''t use mysql, couldn''t test further. Later, Luis PS: I know is not the right list, but as the discussion was started here, I must add the comments. Besides, I don''t know where else I could post it ;-)
OK, I got it build on 1.8.4 finally. Turns out it was the spaces in args for the mkmf dir_config command. Iconverted the paths to the old 8.3 format and it built just fine. Ialso got the mysql_ssl_set check to pass. I tried the change to test.rb, but it wouldn''t work for me. I don''tunderstand why ''./mysql.o'' would work when no file by that nameexists, but whatever, I guess. So now I can use Mongrel on win32 - hooray! Thanks for all the pointers guys. On 5/10/06, Luis Lavena <luislavena at gmail.com> wrote:> As a note, I''ll like to add:>> Using Dependency Walker, both MSVCRT-RUBY18.dll and the built mysql.so> links against MSVCRT.DLL, which is default version 7.0.2600.2180 on> XP.>> For the failures reported, as I don''t use mysql, couldn''t test further.>> Later,>> Luis>> PS: I know is not the right list, but as the discussion was started> here, I must add the comments. Besides, I don''t know where else I> could post it ;-)>> _______________________________________________> Mongrel-users mailing list> Mongrel-users at rubyforge.org> http://rubyforge.org/mailman/listinfo/mongrel-users> -- Cheers, Kevin