Hello, On 3 Jan 2008, at 17:45, Evan Weaver wrote:
> Building on the last messages about Fastthread, can we get a detailed > survey of the different ways people are deploying their applications? > It will help with near-future Mongrel development. We have a few machines with different setups depending on when they were deployed - some stuff from 2005 is still on Apache2/FastCGI, which is slightly upsetting, but the most recent apps are as follows, and new ones will be similar, though perhaps with the addition of swiftiply. > Please include the following things: > > * Framework, if any (Camping, Merb, Rails, Nitro, Ramaze, IOWA, > Rack...) Rails, currently 1.2.3. Looking at Merb right now. > * Mongrel version 1.1.3 > * Mongrel handlers used (rails, dirhandler, camping, cgiwrapper...) rails > * How many mongrel routes and handlers per route registered (if you > don't know, it's probably <= 2) So probably <= 2 ;-) > * Any Mongrel plugins used (mongrel_upload_progress, mongrel_gzip, > mongrel_cow_cluster, mongrel_experimental...) None > * Mongrel runners used (mongrel_rails, mongrel::cluster, > mongrel_service, RV, others... please be *very specific* about which > options of the runner you use. For example, some people use > mongrel::cluster but only for the --clean functionality, not for the > clustering). mongrel::cluster for managing all mongrels. > * Number of mongrels per server per app This is still moot for us really; we're trying to work out the best profile per app, as we do a lot of short-lived campaign-based sites. We had an app get whacked a few weeks ago with 16 mongrels running behind nginx, and the process load was getting really high. Initial thought was to up the number of mongrels so they could cut through the queue quicker, but of course all this did was increase memory usage significantly, meaning with 32 mongrels starting to eat up to 230MB of RAM each, the system started thrashing pretty quickly. So we killed them and cut it down to 8 and things actually seemed a lot smoother, but by that time the load had dropped significantly, so it's hard to tell. In summary, we'll most likely start out with 8 and see how it goes. > * Monitoring system (runit, monit, god...) Ahem ... just getting going with monit > * Proxy or software loadbalancer, if any (apache mod_proxy_balancer, > nginx, pen...) latest nginx, 0.5.xx branch > * HW loadbalancer, if any (Netscaler...) n/a > * Caching strategy (memcached fragments, memcached object, squid, > rails page cache, rails page fragments, ESI) memcached objects, rails page cache as appropriate. > * Whether you serve media assets via mongrel itself, as opposed to > through a webserver Any flat files go out direct through nginx, doesn't seem any point in loading mongrel with this when nginx is sooo fast. > * Operating system including distribution or version (OS X 10.4.10, > Ubuntu/Linux 7.10, WinXP SP2, OpenBSD 4.1...) CentOS 5 > * Architecture, via 'uname -a' preferably (x86, x86_64, Sparc, PPC, > Arm (ha), JRuby) Linux xxx.xxx.xxx 2.6.9-42.ELsmp #1 SMP Sat Aug 12 09:39:11 CDT 2006 i686 i686 i386 GNU/Linux > * CPU count dual-core xeon 3.0ghz Database is on an identical separate machine in the instance I'm getting stats from, might be on the same host for other apps. > * Ruby version including custom distribution patches, > (1.8.6p110+threadhooks, 1.8.5, JRuby 1.1b1, Rubinius trunk... also > note where you got it, in case it isn't clear, for example, OS X 10.5 > built-in, Ubuntu apt, Instant Rails, direct compile from source) ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-linux] - compiled from source. After reading the recent threads this is going to move up to a later patchlevel! > * Rubygems (yes/no, version) yes, recently upgraded from 0.94 to 1.0.1 > Please mention anything else about your system that's kind of weird, > and anything that's been particularly troublesome regarding mongrel > deployment. To be honest since mongrel_cluster came out it's been relatively trouble-free. Well, compared to Apache ;-) Starting and stopping can be a bit temperamental when instances have died or been killed outside mongrel_cluster, but I guess that's to be expected, and as I understand it that's a cluster issue rather than a mongrel issue per se. The only real issue is memory usage. When we see 230MB mongrels as above when most stuff is being served out of memcached, leaks spring to mind, but we've so far been unsucessful in establishing whether it's in our code, a plug-in, the framework, whether it's related to the unpatched ruby, etc ... > PS. You can get some of the Ruby information via the 'tattle' gem: > > $ gem install tattle --ignore-dependencies > $ tattle report user_key, prefix, /poke/software/server/install/ruby-1.8.6 ruby_version, 1.8.6 host_vendor, pc ruby_install_name, ruby build, i686-pc-linux-gnu target_cpu, i686 arch, i686-linux rubygems_version, 1.0.1 SHELL, /bin/sh host_os, linux-gnu report_time, Fri Jan 04 09:48:29 +0000 2008 host_cpu, i686 LIBRUBY, libruby-static.a LIBRUBY_SO, libruby.so.1.8.6 target, i686-pc-linux-gnu Incidentally the site that got hammered is http://www.goodthingsshouldneverend.co.uk/ It's supposed to be a "never-ending web page" - imagine my delight when I heard that brief for the first time! Cheers guys, keep up the great work. Igor -- Igor Clark // POKE // 10 Redchurch Street // E2 7DD // +44 (0)20 7749 5355 // www.pokelondon.com _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
