“60,000 to 70,000 traffic at a time in a day” needs to be put in context to determine what resources are actually necessary to handle the specific type of content and how it’s being generated. If it’s static HTML content that’s probably an easy number to hit, but if it’s a WordPress install (and a poorly configured one at that) then clearly there is work to be done optimizing the plugins and caching of the site itself before you even start trying to optimize the Apache/MySQL/PHP stack.
I’ve helped to run websites serving several million unique visitors with over 30 million page views per day, and 300 million ad impressions per day being handled from an in-house ad server running on our own hardware, where it took over 50 dedicated servers to handle the 30 million page views, but only 1 server to handle the 300 million ad views as the workloads were entirely different.
I remember telling someone once that I’d gotten that particular piece of ad software to handle that many impressions on a rubbish server (it was an X3440 with 4GB of ram from memory) without breaking a sweat just by carefully optimizing the web server, PHP and caching configuration, etc.
After being told that was “impossible” by other people using the same software, it was almost comical when another person chimed in on the same thread to say “oh yeah that was easy. take a quick look at this specific function and make a tiny tweak to optimize it, and it’ll handle over a billion impressions easy on the same hardware”.
The point being, that without context of the actual workload any “general recommendation” is going to be a stab in the dark at best and a “bigger server” or “more ram” or “faster cores” might be completely unnecessary, or worse, a waste of time and money if the real problem has nothing to do with those things.
I can only suggest to try what I mentioned in my other reply and to dig in to the server to find out which constraint is causing the bottleneck when it’s actually occurring, resolve that first, and then keep doing it over and over until either it works or you have no choice but to throw more hardware (and money) at it because you know that is actually what is necessaryto resolve it.