After going through that sizing guide, I'd add another vCPU for every 4-8 Perspective clients (of pretty much any kind), a GB of gateway RAM for every 4-8 light-duty Perspective clients, and 2-4GB of gateway RAM for every heavy-duty Perspective client.
"Light duty" would be single page Perspective apps running in Workstation, or Mobile, or single-tab browser sessions, displaying dashboards with real-time tags, up to an hour (-ish) of real-time trends, and pre-computed statistics for longer time periods.
"Heavy duty" would be any Perspective app typically opened in multiple browser tabs simultaneous, where one or more tabs can request historical data for multiple pens over long time periods (days/weeks/months/more), where any given pen is likely to have 10,000+ actual stored values over the requested period (before aggregation), or can request complicated statistical calculations for long time periods where precomputed stats aren't available.
If you have time to trial your application, you can monitor gateway CPU and memory usage while your application and its client applications stress the gateway. You want to end up with a memory usage sawtooth pattern that, under peak loads, drops below 50% for each big GC event, and stays below 90% almost all the time. CPU utilization should be such that, for "N" vCPUs, utilization stays below ~ (10 + 90 × (N-2)) / N %.
Ignition is rather latency sensitive. The above formula is based on the idea that a couple vCPUs should be mostly idle for quick dispatch to handle incoming packets or other events.
All of the above are just guidelines. Ignition is so flexible that it can be used for exotic algorithms that need more resources. It is also so flexible that poor programming and design can cause excess CPU and RAM usage. 