Either stop the httpd service (and also disable on boot) OR move apache to another port (ie 81,etc...) and start nginx on 80.

so lorax are you saying that I would then have 2 slices? I'd like to not incur the add'l cost of a second slice, not that it's expensive, but would prefer not to.

So there is no easy way to dump apache, eh? I guess I'm just trying to keep a tidy slice and not have any thing on there that I'm not using. But if there is a compelling reason to have both, I'd be interested in knowing why.

What is being left out here is dealing with PHP, which is actually a huge factor in all of this.

Nginx doesn't have any kind of module for dealing with PHP natively the way Apache does via mod_php. This gives you essentially two choices: either run PHP via FastCGI or have Nginx proxy PHP requests to Apache (and let Nginx handle the rest). Each has its benefits and drawbacks which you can easily research in detail, however I've found it generally a better choice to proxy PHP scripts to Apache.

"But wait!" you cry. "Isn't the point here to get away from Apache?"

Well, the point is to run a more efficient server. When configured to solely serve PHP pages (by disabling most of Apache's modules), Apache becomes quite efficient. And the major benefit of Apache over FastCGI for PHP is that it can scale needed script processes on demand, whereas FastCGI must have a number of processes set beforehand.

Also, it's really, really easy to set Nginx to proxy scripts to Apache. You start Apache on a separate port (8080 is a common one), add some lines to your Nginx config, maybe setup an Apache virtual host, and you're good to go.

Serving PHP with FastCGI, in my experience, is quite the opposite. Among other things, you need to write a FastCGI-PHP init script. Or find one. And, really, the overall process is still very poorly documented.

Either way, you'll need to look into either of these options if you're going to run Wordpress and Nginx.

you DO NOT want to proxy requests from nginx to apache. what would be the point of going to all this trouble. I personally wouldn't be too worried about 'scaling' of fastcgi.
Have 4 spawned child processes (one for each cpu core) and call it good. If you feel the need to increase at some point you can always change it. Its one like in a single config file and it restarts almost instantly. You could do it on a live site in about 10 seconds or less.

proxying php requests to apache is actually very smart. The point being to avoid having apache load every apache module in order to handle each request. Disabling everything except for Mod_php leaves you with a process that takes just about as much memory as fastcgi would, but which requires less manual configuration and can scale automatically without needing to be edited.

Honestly for normal traffic numbers it won't really matter. Even if you get dugg, fastcgi and apache will both be able to handle it, though fastcgi may need to spawn more child processes than apache for huge peaks, taking up more memory. Whereas apache's mod_php can scale up better.

Along with mod_php, there's another high-scaling option for proxying - php fpm. The fpm module would need to be compiled into your php. It's basically a native module for php, kind of like mod_php is a native module for apache. It's got a lot of promise as the best of both worlds. It's rather new right now not as mature as apache mod_php.

am I just changing my virtual host in my apache2.conf file from *:80 to *:8080 to change where apache runs? If yes, do I then just run nginx and set up on 80?

If so, I won't rebuild slice and just make these changes. I uninstalled apache, but then reinstalled and my .conf file is still the same and all seems to be working the same as before.

What you'll do is change apache to listen on port 8080. Deactivate all unnecessary apache modules that have nothing to do with serving php. Then install nginx and have it listen on port 80. You'll need to customize the nginx config file (or the nginx virtual host file) to add the instruction to proxy to apache if the file's a php file. Here's an example of that instruction from one of my nginx virtual hosts:

location ~ .*\.php$ {
proxy_pass http://127.0.0.1:8080;

proxy_redirect off;

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

client_max_body_size 10m;
client_body_buffer_size 128k;

proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;

proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}

Posted By: afewtipsI would just like to suggest that you confirm that Apache is the problem.
Reduce the number of apache clients and reduce the open session time.
Also make sure that MySql is optimized for small memory usage.
I am running Plone and had big swap problems until I started optimizing the space usage for apache and Zope.

My 2 cents (of which China owns .4 cents)

what process on the mysql side should I be taking a look at? Again, this is just going to be a wordpress blog and a future forum set up. About 12k-15k pageviews a day right now on the blog.

Truthiness, you may want to read this thread.

I have tried the following way in my slice. The blog(WP) is really slow once is has been served by nginx as the front and apache as the end. I have no idea about this. MAY it need more confirm. Finally, I have to run the blog under nginx via fcgi:)

Posted By: roshambo

You'll want to edit the following files to have Apache listen in on port 8080:

in /etc/apache2/ports.conf:

NameVirtualHost *:8080 Listen 8080

And then in your virtual host files (/etc/apache2/sites-available/)

<VirtualHost *:8080>

Then add something like this to your Nginx config's 'server' area:

location ~ \.php$ {     proxy_pass http://127.0.0.1:8080;     proxy_redirect off;      proxy_set_header Host $http_host;     proxy_set_header X-Real-IP $remote_addr;     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;      client_max_body_size 10m;     client_body_buffer_size 128k;      proxy_connect_timeout 90;     proxy_send_timeout 90;     proxy_read_timeout 90;      proxy_buffer_size 4k;     proxy_buffers 4 32k;     proxy_busy_buffers_size 64k;     proxy_temp_file_write_size 64k; }