I think the approach here should depend on the nature and timing of the traffic:
If you are expecting a curve increase with traffic spread throughout the day then 70000 hits/day works out at just less than 1 hit per second, and with a page processing time of around 5ms this should be no trouble at all.
If instead you are expecting a spike increase with the potential of those 70000 hits all within a period of an hour for example, then this works out at around 20 per second, which may or may not be an issue for you depending on a whole variety of things.
When scaling up, increasing CPU will only get you so far in terms of performance, but for capacity you should consider scenarios such as being able to respond to requests simultaneously through the use of load balancing and multiple VPS instances.
If your website can be adapted to work with solutions such as Amazon Web Services or Google Cloud you could simply fire up additional instances or use auto-scaling as required for capacity and just pay as you go for bandwidth/diskspace used etc.
You mentioned using CDN for static resouces, however you could also split your site into two, and use different hosting environments/providers for each:
Your main domain
www.example.com with the pages that the public see that rarely change, could be hosted either (a) with two or more shared hosting providers, ideally ones that offer generous or unlimited bandwidth, and setup an address (
A) DNS record to each host; or (b) on Amazon Web Services, using a stack of S3 for static files, EC2 for your dynamic processing (PHP/ASP etc), RDS for your MySQL databases, ELB for your auto-scaling, CloudFront for CDN/acceleration etc.
secure.example.com (perhaps with an SSL certificate?) that needs access to your database for when people are accessing pages tailored for them, eg. login areas, order/payment processing, subscription service areas etc, could be kept on your existing hosting setup. By separating the two you should have more resources available to serve these higher importance requests.
In this way if you had problems with one of the above the other would still work fine. Solutions like this used to cost a fortune and require a lot of expertise but these days it can be accomplished on a minimal budget by one person who is happy to experiment and learn, all the knowledge required can be found in the Amazon or Google documentation, or if you chose to use multiple shared hosts you wouldn't require any additional knowledge (though this may cost more as pricing is typically fixed).
While it can be considered good practice to test how your site copes under pressure with stress testing, you should be very wary of doing this if you do not own the infrastructure and if it is not soley used for operating your website since otherwise it could impact on other customers services, breach the terms of your hosting contract, and leave you liable to prosecution for causing what could be considered a denial-of-service attack by the service provider if they have not authorised it in advance. Instead of stress testing the 'live' hosted environment, try to replicate the setup in a virtual machine on your PC and see how it copes while stress testing it 'offline'.