You are approaching the limit of what we personally have supported in a single AtoM instance, so you're in a bit of uncharted territory at present. For now, it will be important to make sure that your AtoM site is sufficiently provisioned with a lot of memory, CPUs, and disk space etc.
Additionally, you could begin using a 2-site deployment if you are not already. See:
Basically, this is using one site as a public-facing read-only site, and a separate AtoM installation as your internal staff edit site, with a replication script used to pass updates between them. In addition to increasing security, this can allow you to scale the resources for each site independently as appropriate, and to add an aggressive cache engine like Varnish
or similar to the public read-only site.
We do try to optimize with each release, so make sure you are keeping up with the latest major versions as well. AtoM is built using an old PHP framework, and there may still be places where you will encounter bottlenecks - you'll have to let us know how things go as you continue using your site!
Finally, we are aware of some community AtoM sites that have achieved very good scalability results. It was not public-facing, but thanks to many local code customizations and optimizations, at one point the National Archives of South Africa were successfully running a single AtoM site with over 8 million records! If you'd like to learn more, you could try posting in the relevant regional group - see: