Determining the ideal server size to handle 4M page views per month

I have worked on a site that had a beefy server with 64 gb of RAM, and the site was still performing poorly. If the correct caching strategy is not in place, I don't think it would matter how strong the box is.

Other than the authenticated users who post classified ads, it seems like most of your traffic are from anonymous users. You can use a CDN like Cloudflare to absorb the bulk of the anonymous traffic.

For dealing with authenticated user traffic, I had success added a slave db to handle most of the db reads.

Here's a link with some more information.
http://redcrackle.com/blog/how-use-drupal-7-mysql-master-slave-setup

@agiss DO not try to save on CPU. Also do not buy 2.x Ghz series with multiple cores.

You do need as fast as possible CPU (it has positive side-effect on Drupal sites)

Having external DB is good but it will affect query performance for sure.
Specially with VIEWS. VIEWS are hungry for MySQL Bandwidth.

Regular server under my team management has avg 25mb/sec in peak time and it is not a full load for the server.

With such load, there is up to 20Mb/sec MySQL bandwidth.

If you have external MySQL even in a local network, it will generate huge bandwidth, so you will need fast switch and ethernet card for 1G (not 100M).

Also do not buy SOFT RAID - they are using CPU for doing RAID job and on power loss, there is high risk on DATA Failure.

PS. check demo site: http://demo.malleus.vps-private.net

There is debug info at the bottom:
Page execution time was 92.04 ms. Executed 135 queries in 15.44 milliseconds.

It's working on the server where multiple sites generated up to 25Mb/sec in peak time.
Peak time happen 14 hours ago. Right now it's only 5Mb/sec

I do 10M pageviews per month @ max 3k concurrent users on a digital ocean $40 / month droplet which I've optimized quite a bit.

Long story short, just about anything modern should be able to handle that workload.

Update to PHP 7.1. That will give you roughly a 4x improvement over PHP 5.4.

MySQL is the bottleneck for Drupal. Use MySQL 5.7 (or most recent Maria DB/Percona), you should see some big improvements in terms of concurrency vs 5.5. Ram is important for MySQL, knowing how big your database is in GB would be nice to know but with ram being so cheap might as well load it up pretty good; start at 32GB and go from there. Put the DB on a SSD (SM863 or better) as well for faster writes.

The last thing to consider is the cache layer. This is usually what causes Drupal to melt. Core's is junk under heavy load. Memcache/Redis is always a good option, that's just one more thing that you'll have to manage though. You can use MySQL as the cache layer if you use it differently; there are 2 modules that do this well: https://www.drupal.org/project/lcache and https://www.drupal.org/project/apdqc. I'm using apdqc and for us it just works (granted I wrote it so it better work). I'm hoping to use the lcache db schema in the future and try to merge the 2 together as async writes are really nice.

Now that your server isn't going to melt down I'd focus heavily on the frontend. The frontend is where some huge performance gains can be found. For this http://drupal.org/project/advagg/ is my recommendation. I like to test with the network at 2G edge speeds. Take https://www.webpagetest.org/result/170420_DP_1G91/ as a quick example from Gor; start render is 7.8s. Here's an example from a heavy site https://www.webpagetest.org/result/170420_CK_1GA5/ start render is 5.7s even though it's downloading 720kb vs 88kb. That's the magic of optimizing for the frontend.