All,
Does anyone have a suggestion on what size of VM should one purchase?
I'm currently using B2MS. When I try to view historical data. It bogs down and restarts.
Thanks,
C
Have you worked through this yet?
You tagged this with Perspective. Perspective does data manipulation for UI display in the gateway. The recommendations in that sizing guide are utterly insufficient for any serious use of Perspective clients for historical review of tag history.
From that document:
† Results can vary based on design choices.
My gut check on that document's recommendations is that it is appropriate only for Vision Clients, which perform chart data preparation and display using Client resources, not gateway resources. (Yes, tag history itself is queried on the gateway in both cases, but it is immediately reclaimable after transmission to a Vision Client, but must be held in the gateway along with all of its visual permutations and JSONification in the Perspective case.)
Those recommendations do not look like they've been updated since Perspective was released. I recommend you add multiple GB of gateway RAM for every Perspective (concurrent) client that is allowed to query large historical time spans.
1 Like
pturmel,
Thanks again for the reply. I currently have two vCPUs and eight Ram (GiB).
Do you have a suggestion on how much I should increase the ram?
Thanks,
C
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. 
11 Likes