Questions[ruby-on-rails](server)

We are running a Ruby on Rails web app under Unicorn. Our app is not strictly CPU bound (we have a dual Xeon E5645 system w/12 cores and a peak load average value is around 6). We started with 40 Unicorn workers initially but application memory footprint increased over time. So, now we have to lower the number of worker processes. I thought that the standard (number of CPU cores + 1) formula applies to Unicorn too but my colleague tried to convince me we should reserve more Unicorn instances per CPU and provided this link. Yet, I am not exactly sure why do we need to spend so much memory on idle Unicorn processes.

My question is: what is the reason to have more than one Unicorn instance per CPU core? Is it due to some architectural peculiarity of Unicorn? I am aware that busy Unicorn processes can't accept new connections (we are using UNIX domain sockets to communicate to Unicorn instances BTW) but I thought backlog was introduced exactly to address this. Is it possible to overcome this 2 to 8 Unicorn instances per CPU rule anyhow?

I've got an Apache question here.

For my entire career as a developer, I've been restarting Apache like this:

sudo /etc/init.d/apache2 restart

I just today deployed my first Rails application, but I was having trouble getting Apache to restart on the host machine. When I tried it that way, Apache would try to restart, but would ultimately hang.

This, however, worked fine:

sudo apachectl restart

What are the differences between these two techniques? I had assumed that the latter was, at best, "syntactic sugar" for the first, but that must not be the case, given that the latter worked while the former did not.

If it's relevant (and I suspect it may be), this Rails application uses Phusion Passenger. My prior development experience (whereby the former method works fine) is mostly with PHP. I'm pretty new to Rails.

The server in question is runs Ubuntu 11.04 (Natty).

I have a signup page on a subdomain like: https://signup.example.com

It should only be accessible via HTTPS but I'm worried people might somehow stumble upon it via HTTP and get a 404.

My html/server block in nginx looks like this:

html {
  server {
    listen 443;
    server_name signup.example.com;

    ssl                        on;
    ssl_certificate        /path/to/my/cert;
    ssl_certificate_key  /path/to/my/key;

    ssl_session_timeout 30m;

    location / {
      root /path/to/my/rails/app/public;
      index index.html;
        passenger_enabled on;
    }
  }
}

What can I add so that people who go to http://signup.example.com get redirected to https://signup.example.com ? (FYI I know there are Rails plugins that can force SSL but was hoping to avoid that)

This is a canonical question about avoiding outgoing mail being classified as spam.
Also related:

• Fighting Spam - What can I do as an: Email Administrator, Domain Owner, or User?
• What are SPF records, and how do I configure them?

I'm wondering how to prevent my emails from my site being marked as spam? I'm using sendmail.

I'm trying to send emails through my ruby-on-rails application. The mails are all written in swedish (if that does make a difference?). I don't know why they keep getting marked as spam.

Are there any things that I can do to minimize the risk?

What would be a reasonable and logical directory into which to deploy my production Rails apps on a Linux system?

Some candidates...

/var/rails  <= There's a /var/www so this would be consistent with that 
               pattern. But I.T. guys have complained about stuff in /var 
               before.

/home/my_home_dir/rails  <= OK, not /var, but I'm not the only developer. 
                            Seems like it really ought to be a systemwide
                            location.

/home/rails  <= I don't know. That just seems weird.

/rails  <= Seems even weirder.

What is the least astonishing, most normal thing to do here?

(Background info -- a Rails app is a bunch of server side code written in Ruby along with a public dir containing JavaScript, CSS, and maybe a little HTML. The public dir is mapped to an Apache vhost. Apache handles the Ruby code through a module called Passenger or mod_rails.)

Thanks for the help, all. I think I'm going to go with /opt/deployed_rails_apps. (I like long, expository directory names, and tab completion.) /var/... is also a good place, but I've gotten stern grumbling from I.T. when I tried to deploy stuff there. If it were my own machine I might go with /var or /srv.