Archive for the ‘ Administration ’ Category

apache – How can I change from prefork to worker MPM on CentOS

I’m running CentOS 64 bit, and jsut found out I am running prefork MPM on my dual quad xeon. I was told worker will give me lower memory usage, and higher performance, since I run a very high traffic website.

If this is true, how do I do it?

Edit: /etc/sysconfig/httpd



Restart, voila!

After restarting httpd, I ran “ps -ef | grep -i http” and got this:

[root@localhost httpd]# ps -ef | grep -i http
root     16334 17289  0 10:44 pts/1    00:00:00 grep -i http
root     30536     1  0 10:00 ?        00:00:00 /usr/sbin/httpd.worker
apache   30539 30536  0 10:00 ?        00:00:00 /usr/sbin/httpd.worker
apache   30541 30536  0 10:00 ?        00:00:02 /usr/sbin/httpd.worker
[root@localhost httpd]# 


If I switch the /etc/sysconfig/httpd back to the default, the ps output is like this:

[root@localhost httpd]# ps -ef | grep -i http
root     16447     1  0 10:47 ?        00:00:00 /usr/sbin/httpd
apache   16448 16447  0 10:47 ?        00:00:00 /usr/sbin/httpd
apache   16449 16447  0 10:47 ?        00:00:00 /usr/sbin/httpd
apache   16450 16447  0 10:47 ?        00:00:00 /usr/sbin/httpd
apache   16451 16447  0 10:47 ?        00:00:00 /usr/sbin/httpd
apache   16453 16447  0 10:47 ?        00:00:00 /usr/sbin/httpd
apache   16454 16447  0 10:47 ?        00:00:00 /usr/sbin/httpd
apache   16455 16447  0 10:47 ?        00:00:00 /usr/sbin/httpd
apache   16456 16447  0 10:47 ?        00:00:00 /usr/sbin/httpd
root     16458 17289  0 10:47 pts/1    00:00:00 grep -i http
[root@localhost httpd]# 

via apache – How can I change from prefork to worker MPM on CentOS 64bit? – Server Fault.

A Practical Guide to Varnish – Why Varnish Matters

A Practical Guide to Varnish – Why Varnish Matters

What is Varnish?

Varnish is an open source, high performance http accelerator that sits in front of a web stack and caches pages.  This caching layer is very configurable and can be used for both static and dynamic content.

One great thing about Varnish is that it can improve the performance of your website without requiring any code changes.  If you haven’t heard of Varnish (or have heard of it, but haven’t used it), please read on.  Adding Varnish to your stack can be completely noninvasive, but if you tweak your stack to play along with some of varnish’s more advanced features, you’ll be able to increase performance by orders of magnitude.

Some of the high profile companies using Varnish include: TwitterFacebookHeroku and LinkedIn.

Our Use Case

One of Factual’s first high profile projects was Newsweek’s “America’s Best High Schools: The List”. After realizing that we had only a few weeks to increase our throughput by tenfold, we looked into a few options. We decided to go with Varnish because it was noninvasive, extremely fast and battlefield tested by other companies. The result yielded a system that performed 15 times faster and a successful launch that hit the front page of  Varnish now plays a major role in our stack and we’re looking to implement more performance tweaks designed with Varnish in mind.

A Simple Use Case

The easiest and safest way to add Varnish to your stack is to serve and cache static content.  Aside from using a CDN, Varnish is probably the next best thing that you can use for free.  However, dynamic content is where you can squeeze real performance out of your stack if you know where and how to use it.  This guide will only scratch the surface on how Varnish can drastically improve performance.  Advanced features such as edge side includes and header manipulation allow you to leverage Varnish for even higher throughput.  Hopefully, we’ll get to more of these advanced features in future blog posts, but for now, we’ll just give you an introduction.

CouchDB – New Features in Replication

CouchOne – Blog – What’s new in Apache CouchDB 0.11 — Part Three: New Features in Replication.

Afficher l'image en taille réelle

Without a doubt, replication is CouchDB’s coolest feature. It allows you to synchronise any two databases, local or remote. There is no role-distinction between databases, no master-slave limitations, everybody is a master (if you want master-slave, simply don’t write to one master and thus make it a slave).

This allows you to build a replication infrastructure that fits your application and deployment needs best: two offices with an ocean in between, no problem; large server cluster in one or more data centres, no problem. And anything in between really.

Replication is not new, it has been baked into CouchDB from the beginning. Today, I’ll show you some of the nifty features we added to the 0.11 replicator to make your life a little easier.

To recap, here is how you trigger replication from CouchDB running on your local machine to synchronise a local database with a remote database:

curl -X POST 
-d '{"source":"database", 

Note: The backslash means “keep reading the command on the next line” to make things more readable and so you can copy and paste the commands into your command line.

Update 05.12.2010: From CouchDB 1.0 on you need to send the correct content type, just add -H 'Content-Type: application/json' to the command line.

If you want to read up on CouchDB replication, check out the chapters Replication and Conflict Management from our book, CouchDB: The Definitive Guide.

Implicitly Create Target Database

This is a small yet useful tip. Prior to 0.11, if you wanted to replicate, the target database would have to exist. This can be a mild annoyance at times, so we added a replicator option to implicitly create target databases, if they don’t exist.

Using it is easy, here’s the curl command:

curl -X POST 
-d '{"source":"database",