Scaling a drupal site to handle 1000 authenticated reqests per second

Our aim is to handle 1000 authenticated requests per second.

Peak or average?

But authcache doesn't help when you are inserting nodes to the site.

This is not exactly a problem with authcache but with the overzealous cache-clearing strategy implemented in Drupal core. See the "Integrate with Cache Expiration module" chapter in the Authcache 2 tuning guide for an explanation of the problem, as well as a solution.

Memory used is around 6GB , rest 10GB is free.

That's a lot of free memory.

If it were me, I'd be running DB and web on separate VMs. That will allow your webservers to scale horizontally without your DB servers, and if you're leveraging caching tools properly you won't need to scale DB near as fast as web.

For HA/redundancy, you might want to consider running your DB in a Galera cluster. I'm sure MariaDB supports it, I'm just not that intimate with MariaDB (we're a Percona XtraDB shop).

For a MySQL configuration, you can get a pretty good baseline from https://tools.percona.com/wizard whether you're using vanilla, Percona, Maria, or practically any other MySQL drop-in replacement. What I've found through experience is that you might want to leave 15% or so of memory headroom for bursts with very inefficient queries if you're not running swap. You'll still need to fine-tune for your application if you want to squeeze every ounce of performance out of it, but the generated configuration from that site is already good enough to question the value of fine-tuning over throwing more hardware at it. By the way, with applications like Drupal that do several writes on every page request, you're sometimes better off to not use the query cache because your potential gains in the query cache are outweighed by the additional processing to replace those one-time queries in the cache. As always, test and test.

For PHP-FPM, use a static number of children. It won't spend extra CPU time spawning new children like it does under ondemand. And the longer your children can last (more requests before killing and respawning), the less respawning, though that has to be balanced against memory issues (the longer children last, the more junk one-time-use or leaked memory gets taken up).

Now the really big question is... have you tried edge side includes? Basically, with ESI, Varnish caches the parts of pages that never change plus blocks that tell it "call Drupal for the stuff that goes here". For example, on an ecommerce site the homepage would rarely change except for "hello ", current cart total, and "suggested for you". The rest of the page could be held in Varnish while those three features are served via edge side includes. Varnish quickly assembles the version of the page to serve for that user, and PHP doesn't have to build the entire page for every user just because three things happen to be unique.

What version of MySQL are you using? I would suggest going to at least 5.5.8. During the early stages of 5.5 a lot was of improvements went into the flushing part of the code, and they really nailed it in 5.5.8.

For architecture, I would highly recommend moving the database to it's own server. That way you can upgrade the hardware that you really need to for a database server, especially your drives (adding to the RAID or moving to SSD). If anything a separate database server makes it a lot easier to isolate bottlenecks, as you now have two dedicated servers, each with its own purpose.

Your requirment is "Our aim is to handle 1000 authenticated requests per second." And "site that can handle around 200 node inserts in one second." here you are still playing with Mysql ?

Here i advice to go with MongoDB or elasticsearch it will fullfill your need.

Is there any way to remove revisions of node and fields in drupal 7.That will reduce a lot of insert queries while creating a node right?
In our site there is no need to maintain revisions.

I read the following discussion but didnt get a proper solution for this.
https://drupal.org/node/289466

I created a module as mentioned in the comment
https://drupal.org/node/289466#comment-6408330
but still it creates revision when a node is created

How much of the site can be cached on a global or per-role basis? If there are a lot of per-role items you could use Varnish and add roles to vcl_hash and pull the per-user stuff in with AJAX / auth_cache.