Search

Hey Community, We greatly appreciate all your feedback on the InterSystems Interoperability Contest! Please take a short survey and answer a few questions to help us improve our contests. 👉 Quick survey: Interoperability Contest Survey 2022 Feel free to share your feedback in the comments of this post as well!

Hey Community! Here are the bonuses for participants' articles that take part in InterSystems Tech Article Contest: Python Edition: Article Topic (5) Video (3) Discussion (1) Translation (1) New member (3) Total points Working with Globals in Embedded Python + + + + 10 Accessing Management Portal System Dashboard information and display cache table data on the web page with the help of embedded python + + 6 IRIS Climate Change application that shows how temperature is increasing worldwide as a proof of global warming + + 6 Time zone conversion utility using embedded python + + + 9 IRIS Embedded Python with Azure Service Bus (ASB) use case + + 8 Create Stored Procedures using Embedded Python + 5 Getting known with Django + + 6 Getting known with Django part 2 + 5 Introduction to Web Scraping with Python - lets Extract some Job Data + + + 9 Dealing with large content in Python Native API + + + 9 Concept for Human Face Detection and Understand their Feeling Using Python + + 4 Getting known with Django part 3 + 5 Bonuses are subject to change upon the update. Please claim your bonuses here in the comments below! Hi @Anastasia.Dyubaylo Thanks for sharing the points.Both of the articles "Accessing Management Portal System Dashboard information and display cache table data on the web page with the help of embedded python" and "IRIS Climate Change application that shows how temperature is increasing worldwide as a proof of global warming" are using "Embedded Python", wondering why Topic points are not awarded?Looking forward Thanks Added to your article ;) Thanks for noticing @Muhammad.Waseem! Thanks @Anastasia.Dyubaylo

Hi Community! We’re so glad to announce that InterSystems FHIR startup incubator — Caelestinus held its first virtual Demo Day on June 29th! 16 startups have showed off their products and solutions built with InterSystems FHIR Server, or IRIS for Health or Health Connect to an audience of about 15 investors & partners. The Demo Day is the result of a four-month journey — the equator of the incubator, in which startups have explored InterSystems tech, validated their ideas and presented it on the first Demo Day. In case you missed it, enjoy watching it on InterSystems Developers YouTube: 📣 The First Demo Day of InterSystems FHIR Startup Incubator — Caelestinus Here is the list of presenters with pitch decks of the startups. 🤩 We're very proud of progress that startups made in such a short time! Enjoy watching and stay tuned!

This week I am going to look at CPU, one of the primary hardware food groups :) A customer asked me to advise on the following scenario; Their production servers are approaching end of life and its time for a hardware refresh. They are also thinking of consolidating servers by virtualising and want to right-size capacity either bare-metal or virtualized. Today we will look at CPU, in later posts I will explain the approach for right-sizing other key food groups - memory and IO. So the questions are: - How do you translate application requirements on a processor from more than five years ago to todays processors? - Which of the current processors are suitable? - How does virtualization effect CPU capacity planning? Added June 2017: For a deeper dive into the specifics of VMware CPU considerations and planning and some common questions and problems, please also see this post: [Virtualizing large databases - VMware cpu capacity planning](https://community.intersystems.com/post/virtualizing-large-databases-vmware-cpu-capacity-planning) [A list of other posts in this series is here](https://community.intersystems.com/post/capacity-planning-and-performance-series-index) # Comparing CPU performance using spec.org benchmarks To translate CPU usage between processor types for applications built using InterSystems data platforms (Caché, Ensemble, HealthShare) you can use SPECint benchmarks as a reliable back of the envelope calculator for scaling between processors. The [http://www.spec.org](http://www.spec.org) web site has trusted results of a standardised set of benchmarks that are run by hardware vendors. Specifically SPECint is a way to compare processors between processor models from the same vendors and between different vendors (e.g. Dell, HP, Lenovo, and Intel, AMD, IBM POWER and SPARC). You can use SPECint to understand the expected CPU requirements for your application when hardware is to be upgraded or if your application will be deployed on a range of different customer hardware and you need to set a baseline for a sizing metric, for example peak transactions per CPU core for Intel Xeon E5-2680 (or whatever processor you choose). There are several benchmarks used on the SPECint web site, however the **SPECint_rate_base2006** results are the best for Caché and have been confirmed over many years looking at customer data and in our own benchmarks. As an example in this post we will compare the difference between the customers Dell PowerEdge server running Intel Xeon 5570 processors and a current Dell server running Intel Xeon E5-2680 V3 processors. The same methodology can be applied when Intel Xeon V4 server processors are generally available (expected soon as I write this in early 2016). ## Example: Comparing processors Search the spec.org database for the __SPECint2006_Rates__ for processor name, for example __E5-2680 V3__, further refine your search results if your target server make and model is known (e.g Dell R730), otherwise use a popular vendor, I find Dell or HP models are good baselines of a standard server, there is not usually much variance between processors on different vendor hardware. > At the end of this post I walk through a step by step example of searching for results using the spec.org web site… Lets assume you have searched spec.org and have found the existing server and a possible new server as follows: Existing: Dell PowerEdge R710 with Xeon 5570 2.93 GHz: 8 cores, 2 chips, 4 cores/chip, 2 threads/core: __SPECint_rate_base2006 = 251__ New: PowerEdge R730 with Intel Xeon E5-2680 v3, 2.50 GHz: 24 cores, 2 chips, 12 cores/chip, 2 threads/core: __SPECint_rate_base2006 = 1030__ Not surprisingly the newer 24-core server has more than 4x increase in SPECint_rate_base2006 benchmark throughput of the older 8-core server even though the newer server has a lower clock speed. Note the examples are two-processor servers that have both processor sockets populated. ### Why is SPECint_rate_base2006 used for Caché? The spec.org web site has explanations of the various benchmarks, but the summary is the **SPECint_rate2006** benchmark is a complete system-level benchmark uses all CPUs with hyper threading. Two metrics are reported for a particular SPECint_rate2006 benchmark, _base_ and _peak_. Base is a conservative benchmark, peak is aggressive. For capacity planning use __SPECint_rate_base2006__ results. ## Does four times the SPECint_rate_base2006 mean four times the capacity for users or transactions? Its possible that if all 24 cores were used the application throughput could scale to four times the capability of the old server. However several factors can cause this milage to vary. SPECint will get you in the ballpark for sizing and throughput that should be possible, but there are a few caveats. While SPECint gives a good comparison between the two servers in the example above it is not a guarantee that the E5-2680 V3 server will have 75% more capacity for peak concurrent users or peak transaction throughput as the older Xeon 5570 based server. Other factors come into play such as whether the other hardware components in our food groups are upgraded, for example is the new or existing storage capable of servicing the increase in throughput (I will have an in-depth post on storage soon). Based on my experience benchmarking Caché and looking at customers performance data __Caché is capable of linear scaling to extremely high throughput rates on a single server__ as compute resources (CPU cores) are added, even more so with the year on year improvements in Caché. Put another way I see linear scaling of maximum application throughput, for example application transactions or reflected in Caché glorefs as CPU cores are added. However if there are application bottlenecks they can start to appear at higher transaction rates and impact liner scaling. In later posts I will look at where you can look for symptoms of application bottlenecks. One of the best things you can do to improve application performance capability is to upgrade Caché to the latest version. > **Note:** For Caché, Windows 2008 servers with more than 64 logical cores are not supported. For example, a 40 core server must have hyper threading disabled. For Windows 2012 up to 640 logical processors are supported. There is no limits on Linux. ## How many cores does the application need? Applications vary and you know your own applications profile, but the common approach I use when capacity planning CPU for a server (or Virtual Machine) is from diligent system monitoring understanding that a certain number of CPU cores of a certain 'standard' processor can sustain a peak transaction rate of _n_ transactions per minute. These may be episodes, or encounters, lab tests, or whatever makes sense in your world. The point is that the throughput of the standard processor is be based on metrics you have collected on your current system or a customers systems. If you know your peak CPU resource use today on a known processor with _n_ cores, you can translate to the number of cores required on a newer or different processor for the same transaction rate using the SPECint results. With expected linear scaling 2 x _n_ transactions per minute roughly translates to 2 x the number of cores are required. ## Selecting a processor As you see from the spec.org web site or looking at your preferred vendor offerings there are many processor choices. The customer in this example is happy with Intel, so if I stick with recommending current Intel servers then one approach is to look for 'bang for buck' - or SPECint_rate_base2006 per dollar and per core. For example the following chart plots Dell commodity servers - your price milage will vary, but this illustrates the point there are sweet spots in price and higher core counts suitable for consolidation of servers using virtualization. I created the chart by pricing a production quality server, for example Dell R730, and then looking at different processor options.  Based on the data in the chart and experience at customers sites the E5-2680 V3 processor shows good performance and a good price point per SPECint or per core. Other factors come into play as well, for example if you are looking at server processors for virtualized deployment it may be cheaper to increase the core count per processor at increased cost but with the effect of lowering the total number of host servers required to support all your VMs, therefore saving on software (e.g. VMware or Operating Systems) that licence per processor socket. You will also have to balance number of hosts against your High Availability (HA) requirements. I will revisit VMware and HA in later posts. For example a VMware HA cluster made up of three 24-core host servers provides good availability and significant processing power (core count) allowing flexible configurations of production and non-production VMs. Remember VMware HA is sized at N+1 servers, so three 24-core servers equates to a total 48-cores available for your VMs. ## Cores vs GHz - Whats best for Caché? Given a choice between faster CPU cores versus more CPU cores you should consider the following: - If your application has a lot of cache.exe threads/processes required then more cores will allow more of these to run at exactly the same time. - If your application has fewer processes you want each to run as fast as possible. Another way to look at this is that if you have a client/server application with many processes, say one (or more) per concurrent user you want more available cores. For browser based applications using CSP where users are bundled into fewer very busy CSP server processes your application would benefit from potentially fewer but faster cores. In an ideal world both application types would benefit from many fast cores assuming there is no resource contention when multiple cache.exe processes are running in all those cores simultaneously. As I noted above, but worth repeating, every Caché release has improvements in CPU resource use, so upgrading applications to the latest versions of Caché can really benefit from more available cores. Another key consideration is maximising cores per host when using virtualization. Individual VMs may not have high core counts but taken together you must strike a balance between number of hosts needed for availability and minimising the number of hosts for management and cost consideration by increasing core counts. ## VMware virtualization and CPU VMware virtualization works well for Caché when used with current server and storage components. By following the same rules as the physical capacity planning there is no significant performance impact using VMware virtualization on properly configured storage, network and servers. Virtulaization support is much better in later model Intel Xeon processors, specifically you should only consider virtualization on Intel Xeon 5500 (Nehalem) and later — so Intel Xeon 5500, 5600, 7500, E7-series and E5-series. --- # Example: Hardware refresh - calculating minimum CPU requirements Putting together the tips and procedures above if we consider our example is a server upgrade of a workload running on Dell PowerEdge R710 with 8-cores (two 4-core Xeon 5570 processors). By plotting the current CPU utilization on the primary production server at the customer we see that the server is peaking at less than 80% during the busiest part of the day. The run queue is not under pressure. IO and application is also good so there are no bottlenecks artificially surpassing suppressing CPU.  > **Rule of thumb**: Start by sizing systems for maximum 80% CPU utilization at end of hardware life taking into account expected growth (e.g. an increase in users/transactions). This allows for unexpected growth, unusual events or unexpected spikes in activity. To make calculations clearer I let us assume no growth in throughput is expected over the life of the new hardware: The per core scaling can be calculated as: (251/8) : (1030/24) or 26% increase in throughput per core. 80% CPU using **8-cores** on the old server equates to roughly 80% CPU using **6-cores** on the new E5-2680 V3 processors. So the same number of transactions could be supported on six cores. The customer has a few choices, they can purchase new bare-metal servers which meet the minimum CPU requirement of six E5-2680 V3 or equivalent CPU cores, or move forward with their plans to virtualize their production workload on VMware. Virtulaizing makes sense to take advantage of server consolidation, flexibility and high availability. Because we have worked out the CPU requirements the customer can move forward with confidence to right-size production VMs on VMware. As a sidebar buying current servers with low core counts is either difficult to source or expensive, which makes virtualization an even more attractive option. Virtualising is also an advantage if significant growth is expected. CPU requirements can be calculated based on growth in the first few years. With constant monitoring a valid strategy is to add additional resources only as needed ahead of requiring them. --- # CPU and virtualization considerations As we have seen production Caché systems are sized based on benchmarks and measurements at live customer sites. It is also valid to size VMware virtual CPU (vCPU) requirements from bare-metal monitoring. Virtualization using shared storage adds very little CPU overhead compared to bare-metal**. For production systems use a strategy of initially sizing the system the same as bare-metal CPU cores. __**Note:__ For VMware VSAN deployments you must add a host level CPU buffer of 10% for VSAN processing. The following key rules should be considered for virtual CPU allocation: __Recommendation:__ Do not allocate more vCPUs than safely needed for performance. - Although large numbers of vCPUs can be allocated to a virtual machine, best practice is to not allocate more vCPUs than are needed as there can be a (usually small) performance overhead for managing unused vCPUs. The key here is to monitor your systems regularly to ensure VMs are right-sized. __Recommendation:__ Production systems, especially database servers, initially size for 1 physical CPU = 1 virtual CPU. - Production servers, especially database servers are expected to be highly utalized. If you need six physical cores, size for six virtual cores. Also see the note on hyper threading below. ## Oversubscription Oversubscription refers to various methods by which more resources than are available on the physical host can be assigned to the virtual servers that are supported by that host. In general, it is possible to consolidate servers by oversubscribing processing, memory and storage resources in virtual machines. Oversubscription of the host is still possible when running production Caché databases, however for initial sizing of _production_ systems assume is that the vCPU has full core dedication. For example; if you have a 24-core (2x 12-core) E5-2680 V3 server – size for a total of up to 24 vCPU capacity knowing there may be available headroom for consolidation. This configuration assumes hyper-threading is enabled at the host level. Once you have spent time monitoring the application, operating system and VMware performance during peak processing times you can decide if higher consolidation is possible. If you are mixing non-production VMs a rule of thumb for system sizing to calculate total CPU cores I often use is to _initially_ size non-Production at 2:1 Physical to Virtual CPUs. However this is definitely an area where milage may vary and monitoring will be needed to help you with capacity planning. If you have doubts or no experience you can separate production VMs from non-production VMs at the host level or by using vSphere configuration until workloads are understood. VMware vRealize Operations and other third-party tools have the facility to monitor systems over time and suggest consolidation or alert that more resources are required for VMs. In a future post I will talk about more tools available for monitoring. The bottom line is that in our customers example they can be confident that their 6 vCPU production VM will work well, of course assuming other primary food group components such as IO and storage have capacity ;) ## Hyperthreading and capacity planning A good starting point for sizing VMs based on known rules for physical servers is to calculate physical server CPU requirements for the target per processor with hyper-threading enabled then simply make the translation: > one physical CPU (includes hyperthreading) = one vCPU (includes hyperthreading). A common misconception is that hyper-threading somehow doubles vCPU capacity. This is NOT true for physical servers or for logical vCPUs. As a rule of thumb hyperthreading on a bare-metal server may give a 30% additional performance capacity over the same server without hyperthreading. The same 30% rule applies to virtulized servers. ## Licensing and vCPUs In vSphere you can configure a VM to have a certain number of sockets or cores. For example, if you have a dual-processor VM, it can be configured so it has two CPU sockets, or that it has a single socket with two CPU cores. From an execution standpoint it does not make much of a difference because the hypervisor will ultimately decide whether the VM executes on one or two physical sockets. However, specifying that the dual-CPU VM really has two cores instead of two sockets could make a difference for non-Caché software licenses. --- # Summary In this post I outlined how you can compare processors between vendors, servers or models using SPECint benchmark results. Also how to capacity plan and choose processors based on performance and architecture whether virtualized is used or not. These are deep subjects, and its easy to head of into the weeds…however the same as the other posts, please comment or ask questions if you do want to head off different directions. — # EXAMPLE Searching for SPECint_rate2006 results. #### The following figure shows selecting the SPECint_rate2006 results.  ---- #### Use the search screen narrow results. #### Note that you can also to dump all records to a ~20MB .csv file for local processing, for example with Excel. #### The results of the search show the Dell R730.   --- #### Selecting HTML to give the full benchmark result.  --- You can see the following results for servers with the processors in our example. Dell PowerEdge R710 with 2.93 GHz: 8 cores, 2 chips, 4 cores/chip, 2 threads/core Xeon 5570: __SPECint_rate_base2006 = 251__ PowerEdge R730 (Intel Xeon E5-2680 v3, 2.50 GHz) 24 cores, 2 chips, 12 cores/chip, 2 threads/core Xeon E5-2680 v3: __SPECint_rate_base2006 = 1030__ I really appreciate all the work you have done on this post.But for me, it is beyond me.Perhaps a more meaningful summary for those who wish to stay out of the weeds? Ok, here is the simpler route:1. if you have performance problems then run pButtons, call WRC, they will get "performance team" involved and explain you what you see :);2. if you have budget for new HW then see item #1 above and ask WRC for advice. Thank you Murray. These are great article series The problem with all such analyses is always the same. They fail to account for the single most important factor for real world applications, and that is memory bandwidth.Code written for benchmarks has the flaw that it is precisely "written for benchmarks". It is no replacement for real life code which accesses memory in ways that such custom code cannot even begin to emulate.Consider virtualization for a moment. Let's take the x86 world. Let's take Intel's VT-x, or AMD's AMD-V. If you look at the wikipedia entry for such techniques, the core goal of those technologies is _not_ to make machine code run faster (this is the "easy part"), but to reduce the time it takes for programs in virtualized environments to access memory.Running code is "easy". Accessing memory is hard... And accessing memory is the key.----For completeness, I'll just add this: I am mostly a Java developer, and I know that the most glaring flaw of Java is its poor locality of reference -- accessing any `X` in a `List<X>` is very likely to trigger a page fault/load/TLB update cycle for this particular `X` to be available. As a result, when performance comes into play, I do not look as much into the frequency of the CPU as I look into the L{1,2,3} cache sizes and the memory bus width and speed. In the long run, the latter three are the deciding factors as far as I'm concerned. Hi Francis,You are absolutely right that memory access performance is vital, however this is not only bandwidth but also latency. With most new systems employing NUMA based architectures, both memory speed and bandwidth have a major impact. This requirement continues to grow as well as because more and more processor cores are crammed into a single socket allowing for more and more concurrently running processes and threads. In additional NUMA node inter-memory accesses plays a major role. I agree that clock speed alone is not a clear indicator of being "the fastest", since clock speeds haven't changed all that much over the years once getting into the 2-3Ghz+ range, but rather items such as overall processor and memory architectures (eg. Intel QPI), on-board instruction sets, memory latency, memory channels and bandwidth, and also on-chip pipeline L2/L3 cache sizes and speeds all play a role.What this article is demonstrating is not particularly CPU sizing specifics for any given application, but rather mentioning one of (not the only) useful tools comparing a given processor to another. We all agree there is no substitute for real-world application benchmarking, and what we have found through benchmarking real-world application based on Caché that SPECint (and SPECint_rate) numbers usually provides a safe relative correlation or comparison from processor model to processor model. Now things become more complicated when applications might not be optimally written and impose unwanted bottlenecks such as excessive database block contentions, lock contention, etc... from the application. Those items tend to negatively impact scalability on the higher end and would prohibit linear or predictable scaling.This article is to serve as the starting point for just one of the components in the "hardware food group". So the real proof or evidence is gained from doing proper benchmarking of your application because that encapsulated all components working together. Kind regards... Thanks for the comments Francis, I think Mark sums up what I was aiming for. The first round of posts is to introduce the major system components that affect performance, and you are right memory has a big role to play along with CPU and IO. There has to be a balance - to keep stretching the analogy good nutrition and peak performance is the result of a balanced diet. Certainly badly sized or configured memory will cause performance problems for any application, and with Java applications this is obviously a big concern. My next post is about capacity planning memory, so hopefully this will be useful - although I will be focusing more on the intersection with Caché. As Mark pointed out NUMA can also have influence performance, but there are strategies to plan for and mitigate the impact of NUMA which I will talk about in my Global Summit presentations, and which I will also cover in this series of posts.Another aim in this series is to help customers who are monitoring their systems to understand what metrics are important and from that use the pointers in these posts to start to unpack whats going on with their application and why - and whether action needs to be taken. The best benchmark is monitoring and analysing your own live systems. Murray, Can you explain how you do these calculations: The per core scaling can be calculated as: (251/8) : (1030/24) or 26% increase in throughput per core.80% CPU using 8-cores on the old server equates to roughly 80% CPU using 6-cores on the new E5-2680 V3 processors. So the same number of transactions could be supported on six cores.I mean what did you do to match the 80% on the old server to 6 -cores in the new one. I got a little bit lost with the numbers or steps you do. Thanks Hi, back of the envelope logic is like this:For the old server you have 8 cores. Assuming the workload does not change:Each core on the new server is capable of about 25% more processing throughput. Or another way; each core of the old server is capable of of about 75% processing throughput of the new server. So roughly (8 *.75) old cores equates to about 6 cores on the new server.You will have to confirm how your application behaves, but if you are using the calculation to work out how much you can consolidate applications on a new virtualized server you can get a good idea what to expect. If it is virtualized you can also right-size after monitoring to fine tune if you have to. For a deeper dive into VMware CPU considerations and planning, please see the post:https://community.intersystems.com/post/virtualizing-large-databases-vmware-cpu-capacity-planning @Murray.Oldfield - thank you for the time you spent putting together these performance articles!

This post will show you an approach to size shared memory requirements for database applications running on InterSystems data platforms including global and routine buffers, gmheap, and locksize as well as some performance tips you should consider when configuring servers and when virtualizing Caché applications. As ever when I talk about Caché I mean all the data platform (Ensemble, HealthShare, iKnow and Caché). [A list of other posts in this series is here](https://community.intersystems.com/post/capacity-planning-and-performance-series-index) When I first started working with Caché most customer operating systems were 32-bit and memory for a Caché application was limited and expensive. Commonly deployed Intel servers had only a few cores and the only way to scale up was go with big iron servers or use ECP to scale out horizontally. Now even basic production grade servers have multiple processors, dozens of cores and minimum memory is 128 or 256 GB with the possibility of TB. For most database installations ECP is forgotten and we can now scale application transaction rates massively on a single server. A key feature of Caché is the way we use data in shared memory usually referred to as database cache or global buffers. The short story is that if you can right size and allocate 'more' memory to global buffers you will usually improve system performance - data in memory is much faster to access than data on disk. Back in the day, when 32-bit systems ruled, the answer to the question _how much memory should I allocate to global buffers?_ Was a simply - _as much as possible!_ There wasn't that much available anyway, so sums were done diligently to calculate OS requirements, the number of and size of OS and Caché processes and real memory used by each to find the remainder to allocate as large a global buffer as possible. ## The tide has turned If you are running your application on a current generation server you can allocate huge amounts of memory to a Caché instance and a laissez-faire attitude often aplies because memory is now "cheap" and plentiful. However the tide has turned again and pretty much all but the very largest systems I see deployed now are virtualized. So while 'monster' VMs can have large memory footprints if needed the focus still comes back to right sizing systems. To make the most of server consolidation capacity planning is required that makes best use of available host memory. # What uses memory? Generally there are four main consumers of memory on a Caché database server: * Operating System, including filesystem cache. * If installed, other non-Caché applications. * Caché processes. * Caché shared memory (includes global and routine buffers and GMHEAP). At a high level the amount of physical memory required is to simply add up the requirements of each of the items on the list. All of the above use real memory, but they can also use virtual memory, a key part of capacity planning is to size a system so that there is enough physical memory so paging does not occur or is minimized, or at least minimize or eliminate hard page faults where memory has to be brought back from disk. In this post I will focus on sizing Caché shared memory and some general rules for optimising memory performance. The operating system and kernel requirements vary by operating system, but will be several GB in most cases. File system cache varies and is will be whatever is available after the other items on the list take their allocation. Caché is mostly processes - if you look at the operating system statistics while your application is running you will see cache processes (e.g. cache or cache.exe). So a simple way to observe what your application memory requirements are is to look at the operating system metrics. For example with `vmstat` or `ps` on Linux or `Windows process explorer` and total the amount of real memory in use, extrapolating for growth and peak requirements. Be aware that some metrics report virtual memory which includes shared memory, so be careful to gather real memory requirements. ## Sizing Global buffers - A simplified way For a high transaction database one of the capacity planning goals is to size global buffers so that as much of the application database working set is in memory as possible. This will minimise read IOPS and generally make the application perform better. We also need to strike a balance so that other memory users such as operating system and Caché process are not paged out and and there is enough memory for filesystem cache. I showed an example of what can happen if reads from disk are excessive in [Part 2 of this series.](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-–-part-2) In that case high reads were caused by a bad report or query, but the same effect can be seen if global buffers are too small forcing the application to be constantly reading data blocks from disk. As a sidebar its also worth noting that the landscape for storage is always changing - storage is getting faster and faster with advances in SSDs but data in memory close to the running processes is still best. Of course every application is different so its important to say __"your milage may vary"__, but there are some general rules which will get you started on the road to capacity planning shared memory for your application. After that you can tune for your specific requirements. ### Where to start? Unfortunately there is no magic answer... but as I talked about in the previous posts a good practice is to size systems CPU capacity so that for a required peak transaction rate CPU will be approximately 80% utilized at peak processing times. Leaving 20% headroom for short term growth or unexpected spikes in activity. For example when I am sizing TrakCare systems I know CPU requirements for a known transaction rate from benchmarking and reviewing customer site metrics, and I can use a broad rule of thumb for Intel processor based servers: `Rule of thumb:` Physical memory is sized at _n_ GB per CPU core. - For TrakCare database servers _n_ is 8 GB. For smaller web servers its 4 GB. `Rule of thumb:` Allocate _n_% of memory to Caché global buffers. - For small to medium TrakCare systems _n_% is 60% leaving 40% of memory for operating system, filesystem cache and Caché processes. You may vary this, say to 50%, if you need a lot of filesystem cache or have a lot of processes. Or make it a higher % as you use very large memory configurations on large systems. - This rule of thumb assumes only one Caché instance on the server. So for example if the application needs 10 CPU cores then the VM would have 80 GB of memory, with 48 GB for global buffers and 32 GB for everything else. Memory sizing rules apply to physical or virtualized systems, so for TrakCare VMs the same 1 vCPU : 8 GB memory ratio applies. ### Tuning global buffers There are a few items to observe to see how effective your sizing is. You can observe free memory outside Caché with operating system tools. Set up as per your best calculations then observe memory usage over time, and if there is always free memory the system can be reconfigured to increase global buffers or to right-size a VM. Another key indicator of good global buffer sizing is to have read IOPS as low as possible - which means Caché cache efficiency will be high. You can observe the impact of different global buffer sizes on PhyRds and RdRatio with mgstat, an example of looking at these metrics is in [Part 2 of this series.](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-–-part-2) Unless you have your entire database in memory there will always be some reads from disk, the aim is simply to keep reads as low as possible. Remember your hardware food groups and getting the balance right - more memory for global buffers will lower read IOPS but possibly increase CPU utilization because your system can now do more work in a shorter time - but lowering IOPS is pretty much always a good thing - your users will be happier with faster response times. _See the section below for applying your requirements to __physical memory__ configuration._ For virtual servers plan _not_ to oversubscribe your production VMs memory _especially Caché shared memory_, also more on this below. Is your applications sweet spot 8GB of physical memory per CPU core? I can't say but see if a similar method works for your application. Whether its 4GB or 10GB per core. If you have found another method for sizing global buffers please leave a comment below. ### Monitoring Global Buffer usage The Caché utility `^GLOBUFF` displays statistics about what your global buffers are doing at any point in time. For example to display the top 25 by percentage: do display^GLOBUFF(25) For example output could look like this: Total buffers: 2560000 Buffers in use: 2559981 PPG buffers: 1121 (0.044%) Item Global Database Percentage (Count) 1 MyGlobal BUILD-MYDB1 29.283 (749651) 2 MyGlobal2 BUILD-MYDB2 23.925 (612478) 3 CacheTemp.xxData CACHETEMP 19.974 (511335) 4 RTx BUILD-MYDB2 10.364 (265309) 5 TMP.CachedObjectD CACHETEMP 2.268 (58073) 6 TMP CACHETEMP 2.152 (55102) 7 RFRED BUILD-RB 2.087 (53428) 8 PANOTFRED BUILD-MYDB2 1.993 (51024) 9 PAPi BUILD-MYDB2 1.770 (45310) 10 HIT BUILD-MYDB2 1.396 (35727) 11 AHOMER BUILD-MYDB1 1.287 (32946) 12 IN BUILD-DATA 0.803 (20550) 13 HIS BUILD-DATA 0.732 (18729) 14 FIRST BUILD-MYDB1 0.561 (14362) 15 GAMEi BUILD-DATA 0.264 (6748) 16 OF BUILD-DATA 0.161 (4111) 17 HISLast BUILD-FROGS 0.102 (2616) 18 %Season CACHE 0.101 (2588) 19 WooHoo BUILD-DATA 0.101 (2573) 20 BLAHi BUILD-GECKOS 0.091 (2329) 21 CTPCP BUILD-DATA 0.059 (1505) 22 BLAHi BUILD-DATA 0.049 (1259) 23 Unknown CACHETEMP 0.048 (1222) 24 COD BUILD-DATA 0.047 (1192) 25 TMP.CachedObjectI CACHETEMP 0.032 (808) This could be useful in several ways, for example to see how much of your working set is kept in memory. If you find this utility is useful please make a comment below to enlighten other community users on why it helped you. ## Sizing Routine Buffers Routines your application is running including compiled classes are stored in routine buffers. The goal of sizing shared memory for routine buffers is for all your routine code to be loaded and stay resident in routine buffers. Like global buffers it is expensive and inefficient to read routines off disk. The maximum size of routine buffers is 1023 MB. As a rule you want more routine buffers than you need as there is always a big performance gain to have routines cached. Routines buffers are made up of different sizes. By default Caché determines the number of buffers for each size, at install time the defaults for 2016.1 are 4, 16 and 64 KB. It is possible to change the allocation of memory for different sizes, however to start your capacity planning it is recommended to stay with Caché defaults unless you have a special reason for changing. For more information, see routines in the [Caché documentation](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RCPF_routines) “config” appendix of the Caché Parameter File Reference and Memory and Startup Settings in the “Configuring Caché” chapter of the Caché System Administration Guide. As your application runs routines are loaded off disk and stored in the smallest buffer the routine will fit. For example if a routine is 3 KB it will ideally be stored in a 4 KB buffer, if there are no 4 KB buffers available a larger one will be used. A routine larger than 32 KB will use as many 64 KB routine buffers as needed. ### Checking Routine Buffer Use #### mgstat metric RouLas One way to understand if the routine buffer is large enough is the mgstat metric RouLas (routine loads and saves). A RouLas is a fetch from or save to disk. A high number of routine loads/saves may show up as a performance problem, in that case you can improve the performance by increasing the number of routine buffers. #### cstat If you have increased routine buffers to the maximum of 1023 MB and still find high RouLas a more detailed examination is available so you can see what routines are in buffers and how much is used with `cstat` command. ccontrol stat cache -R1 This will produce a listing of routine metrics including a list of routine buffers and all the routines in cache. For example a partial listing of a default Caché install is: Number of rtn buf: 4 KB-> 9600, 16 KB-> 7200, 64 KB-> 2400, gmaxrouvec (cache rtns/proc): 4 KB-> 276, 16 KB-> 276, 64 KB-> 276, gmaxinitalrouvec: 4 KB-> 276, 16 KB-> 276, 64 KB-> 276, Dumping Routine Buffer Pool Currently Inuse hash buf size sys sfn inuse old type rcrc rtime rver rctentry rouname 22: 8937 4096 0 1 1 0 D 6adcb49e 56e34d34 53 dcc5d477 %CSP.UI.Portal.ECP.0 36: 9374 4096 0 1 1 0 M 5c384cae 56e34d88 13 908224b5 %SYSTEM.WorkMgr.1 37: 9375 4096 0 1 1 0 D a4d44485 56e34d88 22 91404e82 %SYSTEM.WorkMgr.0 44: 9455 4096 0 0 1 0 D 9976745d 56e34ca0 57 9699a880 SYS.Monitor.Health.x 2691:16802 16384 0 0 7 0 P da8d596f 56e34c80 27 383da785 START etc etc "rtns/proc" on the 2nd line above is saying that 276 routines can be cached at each buffer size as default. Using this information another approach to sizing routine buffers is to run your application and list the running routines with cstat -R1. You could then calculate the routine sizes in use, for example put this list in excel, sort by size and see exactly what routines are in use. If your are not using all buffers of each size then you have enough routine buffers, or if you are using all of each size then you need to increase routine buffers or can be more direct about configuring the number of each bucket size. ## Lock table size The locksiz configuration parameter is the size (in bytes) of memory allocated for managing locks for concurrency control to prevent different processes from changing a specific element of data at the same time. Internally, the in-memory lock table contains the current locks, along with information about the processes that hold those locks. Since memory used to allocate locks is taken from GMHEAP, you cannot use more memory for locks than exists in GMHEAP. If you increase the size of locksiz, increase the size of GMHEAP to match as per the formula in the GMHEAP section below. Information about application use of the lock table can be monitored using the system management portal (SMP), or more directly with the API: set x=##class(SYS.Lock).GetLockSpaceInfo(). This API returns three values: "Available Space, Usable Space, Used Space". Check Usable space and Used Space to roughly calculate suitable values (some lock space is reserved for lock structure). Further information is available in [Caché documentation.](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RCPF_locksiz) Note: If you edit the locksiz setting, changes take place immediately. ## GMHEAP The GMHEAP (the Generic Memory Heap) configuration parameter is defined as: Size (in kilobytes) of the generic memory heap for Caché. This is the allocation from which the Lock table, the NLS tables, and the PID table are also allocated. Note: Changing GMHEAP requires a Caché restart. To assist you in sizing for your application information about GMHEAP usage can be checked using the API: %SYSTEM.Config.SharedMemoryHeap This API also provides the ability to get available generic memory heap and recommended a GMHEAP parameters for configuration. For example, the `DisplayUsage` method displays all memory used by each of the system components and the amount of available heap memory. Further information is available in [Caché documentation](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RCPF_gmheap#RCPF_B172591). write $system.Config.SharedMemoryHeap.DisplayUsage() To get an idea of GMHEAP usage and recommendations at any point in time you can use the `RecommendedSize` method. However you will need to run this multiple times to build up a baseline and recommendations for your system. write $system.Config.SharedMemoryHeap.RecommendedSize() `Rule of thumb:` Once again your applications mileage will vary, but somewhere to start your sizing could be one of the following: (Minimum 128MB) or (64 MB * number of cores) or (2x locksiz) or whichever is larger. Remember GMHEAP must be sized to include the lock table.  # Large/Huge pages Mark Bolinsky wrote a great post explaining why turning on [Huge pages in Linux is a great performance booster.](https://community.intersystems.com/post/linux-transparent-hugepages-and-impact-caché) ## Danger! Windows Large Pages and Shared Memory Caché uses shared memory on all platforms and versions and its a great performance booster, including on Windows where it is always used, but there are particular issues unique to Windows you need to be aware of. When Caché starts, it allocates a single, large chunk of shared memory to be used for database cache (global buffers), routine cache (routine buffers), the shared memory heap, journal buffers, and other control structures. On Caché startup shared memory can be allocated using small or large pages. On Windows 2008 R2 and later Caché uses large pages by default, however if a system has been running for a long time, due to fragmentation contiguous memory may not be able to be allocated at Caché startup and Caché can instead start using small pages. Unexpectedly starting Caché with small pages can cause Caché to start with less shared memory than defined in configuration or __Caché may take a long time to start or fail to start.__ I have seen this happen on sites with a failover cluster where the backup server has not been used as a database server for a long time. `Tip:` One mitigation strategy is to periodically reboot the offline Windows cluster server. Another is to use Linux. # Physical Memory Physical memory is dictated by the best configuration for the processor. A bad memory configuration can have a significant performance impact. ## Intel Memory configuration best practice This information applies to __Intel__ processors only. Please confirm with vendors what rules apply to other processors. Factors that determine optimal DIMMs performance include: - DIMM type - DIMM rank - Clock speed - Position to the processor (closest/furthest) - Number of memory channels - Desired redundancy features. For example, on Nehalem and Westmere servers (Xeon 5500 and 5600) there are three memory channels per processor and memory should be installed in sets of three per processor. For current processors (for example E5-2600) there are four memory channels per processor, so memory should be installed in sets of four per processor. When there are unbalanced memory configurations — where memory is not installed in sets of three/four or memory DIMMS are different sizes, unbalanced memory can impose a 23% memory performance penalty. Remember that one of the features of Caché is in memory data processing so getting the best performance from memory is important. It is also worth noting that for maximum bandwidth servers should be configured for the fastest memory speed. For Xeon processors maximum memory performance is only supported at up to 2 DIMMs per channel, so the maximum memory configurations for common servers with 2 CPUs is dictated by factors including CPU frequency and DIMM size (8GB, 16GB, etc). `Rules of thumb:` - Use a balanced platform configuration: populate the same number of DIMMs for each channel and each socket - Use identical DIMM types throughout the platform: same size, speed, and number of ranks. - For physical servers round up total physical memory in a host server to the natural break points -- 64GB, 128GB and so on based on these Intel processor best practices. # VMware Virtualisation considerations I will follow up in future with another post with more guidelines for when Caché is virtualized. However the following key rule should be considered for memory allocation: `Rule:` Set VMware memory reservation on production systems. As we have seen above when Caché starts, it allocates a single, large chunk of shared memory to be used for global and routine buffers, GMHEAP, journal buffers, and other control structures. You want to avoid any swapping for shared memory so set your _production database VMs_ memory reservation to at least the size of Caché shared memory plus memory for Caché processes and operating system and kernel services. If in doubt reserve the full production database VMs memory. As a rule if you mix production and non-production servers on the same systems do not set memory reservations on non-production systems. Let non-production servers fight out whatever memory is left ;). VMware often calls VMs with more than 8 CPUs 'monster VMs'. High transaction Caché database servers are often monster VMs. There are other considerations for setting memory reservations on monster VMs, for example if a monster VM is to be migrated for maintenance or due to a High Availability triggered restart then the target host server must have sufficient free memory. There are stratagies to plan for this I will talk about them in a future post along with other memory considerations such as planning to make best use of NUMA. # Summary This is a start to capacity planning memory, a messy area - certainly not as clear cut as sizing CPU. If you have any questions or observations please leave a comment. As this entry is posted I am on my way to Global Summit 2016. If you are attending this year I will be talking about performance topics with two presentations, or I am happy to catch up with you in person in the developers area. Thank you for excellent articles, Murray.We use slightly different approach for memory planning.Our app mostly runs as a set of concurrent user sessions, one process per user. It's known that avg memory per process is 10Mb, we multiply it by 3*N_concurrent_users. The 1st multiplier (3) makes a gap for memory spikes. So, the result is a memory we leave for user processes.We try to leave for Routine Buffer cache as much memory as possible, upto 1Gb.The Global Buffer memory is usually calculated as a 30% of 3-years-old-database size for given kind of customer. Usually it comes to 24-64Gb global cache for medium to large size hospitals and provides thousands (or dozens of thousands) Rdratio. At whole, we usually get numbers that are close to your 60/40 proportion, while my globuff calculation method is not so presized as yours and I feel that I need a better calculation base for it. Thanks for adding your experience. Yes, your method for sizing per user process makes perfect sense, and that is how I did it when using client/server applications. I spend a lot of time now with a CSP (web) application which has less server processes per user so the calculations are different per user. The same with memory so plentiful now 1023 MB is often the default for routine buffer. But smaller sites or small VMs may be adjusted down. The 60/40 came about because of a need for sizing a new site, but I also like the idea of using a % for expected active data. In the end the best path is try and start in the ballpark with the rules we have... over time with constant monitoring adjust if/when needed. Thanks again. MO Currently, we are running 2010.2 and I am following this to review our performance. In doing so, I read above, "The maximum size of routine buffers is 1023 MBs."I was wondering if you could clarify what this means as I'm finding that the maximum is 65,535.Thanks in advance.

Preface: our small, but very ambitious company called “Black Mushroom Studio” came up with an idea for an e-commerce project and a mobile app that would let users pay for certain goods/services via a payment aggregator. What we had initially: an Android app skeleton that, of course, liked communicating via HTTP and JSON, and a payment system with an API – web services with SOAP content. Goal: make it all work together.The following factors influenced the choice of the technology stack: speed of development and ability to quickly react to changes. The product was supposed to be an instant success. While competitors were still producing estimates, we wanted to launch the product. While our competitors were looking for the right developers, we were supposed to be counting our first moneys. With this restricting factor in place, we still needed a serious approach to work, since it was all about investors’ money, and that is something that requires extra attention. We could spend a lot of time talking about the advantages and disadvantages of specific technologies from specific vendors and the benefits of open source products. Having analyzed several products (which alone is worth of a separate article), we concluded that InterSystems Ensemble was the best choice for our needs. Only one of our developers had practical experience of developing with Caché ObjectScript, but nobody knew Ensemble. However, we managed to implement the rather complex business logic of our product with Ensemble in just a couple of weeks. What helped us: 1. Ensemble is a comprehensive product combining a DBMS, an application server, an enterprise service bus, a BMP system and a technology for developing analytical BI applications. There is no need to learn several solutions and integrate them.2. Object-based storage model. If we want save an object to a database, we just save it to a database.3. A very simple method of integration with external/internal systems based on various protocols thanks to an extendable library of adaptors. Top-level solution A client sends a request with JSON content over the HTTP protocol to a server port. This port is listened to by Ensemble’s “black box”. The client gets a synchronous response after the end of processing. What’s inside Using Ensemble, we implemented a production (an integration solution in Ensemble) consisting of three parts: business services, business processes, business operations (from now on, I will be using these terms without the “business” prefix for ease of reading). A service in Ensemble is a component that allows you to receive requests over various protocols; a process is the applications’s logic; an operation is a component that lets you send outgoing requests to external systems. All interaction inside Ensemble is based on message queues. A message is an object of a class inherited from Ens.Message that makes it possible to use and transmit data from one part of a production to another. The service in our case uses an HTTP adaptor inherited from EnsLib.HTTP.InboundAdapter, receives a request sent by a client, converts it into a “message” and submits it to the process. The business process responds with a “message” containing processing results and converts it into a response for the client. Here is how it looks in our solution: Method OnProcessInput(pInput As %Library.AbstractStream, Output pOutput As %Stream.Object) As %Status { Set jsonstr = pInput.Read() // Let’s convert it into a message Set st = ##class(%ZEN.Auxiliary.jsonProvider).%ConvertJSONToObject(jsonstr,"invoices.Msg.Message",.tApplication) Throw:$$$ISERR(st) ##class(%Exception.StatusException).CreateFromStatus(st) // Some logic for filling messages with data, // characteristic of our queries // Let’s start a business process Set outApp=##class(invoices.Msg.Resp).%New() Set st =..SendRequestSync("Processing",tApplication,.outApp) Quit:$$$ISERR(st) st // Let’s convert the response to json Set json="" Do ##class(invoices.Utils).ObjectToJSON(outApp,,,"aeloqu",.json) // Let’s put json to the response Set pOutput=##class(%GlobalBinaryStream).%New() Do pOutput.SetAttribute("Content-Type","application/json") Do pOutput.Write(json) Quit st } A business process is an implementation of the business logic of our application. It contains a sequence of actions that need to be performed to send a response to the client. For example: save/update the client’s data, add a new traceable service, request a service status, pay for a service. Without an integrated platform, we’d have to write quite a lot of code. What we need to do in Ensemble: build a business process in a visual editor from different elements. Business processes are described in the Business Process Language (BPL) language. Elements include simple (and not very) allocations, data conversion, code calls, synchronous and asynchronous process and operation calls (more on this below). Data conversion is also very convenient and supports data mapping without having to write a line of code: As the result, we got the following instead of a pile of code at a certain stage: A few words about operations now. This entity allows us to send a request via some protocol to an external system. How we did it: used a built-in studio extension to import the WSDL provided by the payment system from Caché Studio WSDL: Let’s specify the location of the WSDL: Let’s tick the “Create an operation” box during import: As the result, we get ready code for making requests to and processing responses from our payment system. Let’s configure an operation in the portal and specify its class: Let’s now mount the SSL configuration (it should be created in advance through System Management Portal – System Administration – Security – SSL/TLS Configurations): Done! All we need to do now is to call the operation from a business process. In our case, we have two such operations: for the information part and the payment part. In the end, we didn’t have to write a single line of code for interacting with the payment system. That’s it, the integration is completed. However, there is also a separate process that is used for sending PUSH notifications using built-in Ensemble tools, a separate process for obtaining SFTP registries from the payment system for receipt generation, a process for generating PDF receipts, but they all deserve a separate article. As the result, we spent just a couple of weeks to implement all this (including the time needed to familiarize ourselves with the new technology). Of course, this InterSystems product is not perfect (nothing is perfect). While working on our implementations, we faced a lot of difficulties, and the lack of documentation for Ensemble didn't help at all. However, in our case, the technology proved to be efficient and worked very well for our purposes. Kudos to the company for supporting young and ambitious developers and their readiness to help. We definitely plan to release new products based on this technology. We have already launched an app based on this technology, and web version is under way. Links: Google Play , App Store Great explanation of how you used Ensemble. Thanks. Could you send me more information on what you'd like to see in the Ensemble documentation. I know there are lots of areas that need improvement, but it's a big product and getting more specific information would help set our priorities in improving the documentation. You could reply here or send me email directly at Joshua.goldman@intersystems.com.Thanks again Great example! Thanks for sharing! I love how simple and elegant your solution looks.

Learn to design, build, implement, and test a new custom business operation in an Ensemble production by taking this online learning course.This course will teach you how to determine when and why to create a custom business operation, design and create a custom business operation for a production, and add a new business operation to a production and configure settings.Learn More.

Hi Community!I'm pleased to announce that the winner of the Global Summit Free Registration Contest is... Dmitry Maslennikov!Final leaderboard is:To win the prize Dmitry published 3 posts and 13 comments in two weeks. Thanks to your votes for posts and comments Dmitry gathered maximum number of points.We award Dmitry with Free Registration promo code for InterSystems Global Summit 2016 and cover expenses for 4 night stay in Waldorf Astoria Arizona Biltmore.Welcome to InterSystems Global Summit 2016! Thanks a lot Congrats! Congratulations! I am looking forward to meeting you at the Global Summit.Stefan So first off, I think Dmitry deserved to win, but I do have a question.In this post, dated Feb 19th, I had 55 points. On the 26th I posted asking about it and my score was at 50. 4 days later and my final score is still 50 (after a lot more posts). What's the deal? edit: Just realized that posts to the Developer Community Feedback forum didn't count, which explains why my points didn't go up. But it still doesn't explain why they went down. :) Scott - I am sure Evgeny will provide some clarification here once he gets online. Thanks for your patience! Hi, Scott!You are right!The explanation is very simple - we had a bug in formula. Sorry about this.But the final leaderboard is quite right! We have points for: posting, commenting, votes in your posts and comments. And yes, we filter Announcements and Developer Community Feedback groups. Scott!Want to invite you to participate in the Second Developer Community Contest!Hope we will not show errors in leaderboard this time :)

Previously I showed you how to run pButtons to start collecting performance metrics that we are looking at in this series of posts. - [Part 1 - Getting started on the Journey, collecting metrics](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-1) - [Part 2 - Looking at the metrics we collected](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-2) ##Update: May 2020. _Since this post was written several years ago, we have moved from Caché to IRIS. See the comments for an updated link to the documentation for pButtons (Caché) and SystemPerformance (IRIS). Also, a note on how to update your systems to the latest versions of the performance tools._ pButtons is compatible with Caché version 5 and later and is included with recent distributions of InterSystems data platforms (HealthShare, Ensemble and Caché). This post reminds you that you should download and install the latest version of pButttons. The latest version is always available for download: _Update:_ **See the comments below for details** To check which version you have installed now, you can run the following: %SYS>write $$version^pButtons() Note 1: - The current version of pButtons will require a license unit; future distributions will address this requirement. - With this distribution of pButtons, versioning has changed. — The prior version of pButtons was 1.16c — This new distribution is version 5. Note 2: - pButtons version 5 also corrects a problem introduced with version 1.16a that could result in prolonged collection times. Version 1.16a was included with Caché 2015.1.0. If you have pButtons version 1.16a through 1.16c, you should download pButtons version 5 from the FTP site. More detailed information on pButtons is available in the files included with the download and in the online Caché documentation. @Murray.Oldfield Current version of documentation says regarding to the update https://cedocs.intersystems.com/latest/csp/docbook/Doc.View.cls?KEY=GCM_pbuttons#GCM_pButtons_runsmpThis utility may be updated between releases. The latest version is available on the WRC distribution site under Tools The xml indeed can be downloaded from WRC but no word neither about pButtons version not the way to install it. Should I simple import the xml into %SYS? Hi, yes you can import using the system management portal; System >Classes Then import into %SYS. Here is version information before; %SYS>write $$version^SystemPerformance() 14 After import, you can see the version information changed. Also note there was a conversion run. The custom profile I had created before the import existed after the update. %SYS>write $$version^SystemPerformance() $Id: //iris/2020.1.0/databases/sys/rtn/diagnostic/systemperformance.mac#1 $ %SYS>d ^SystemPerformance Re-creating command data for new ^SystemPerformance version. Old command data saved in ^IRIS.SystemPerformance("oldcmds"). Current log directory: /path/path/iris/mgr/ Available profiles: 1 12hours - 12 hour run sampling every 10 seconds 2 24hours - 24 hour run sampling every 10 seconds 3 30mins - 30 minute run sampling every 1 second 4 4hours - 4 hour run sampling every 5 seconds 5 5_mins_1_sec- 5 mins 1 sec 6 8hours - 8 hour run sampling every 10 seconds 7 test - A 5 minute TEST run sampling every 30 seconds Select profile number to run: 5 Collection of this sample data will be available in 420 seconds. The runid for this data is 20200518_094753_5_mins_1_sec. %SYS> You can also import from the command line; USER>zn "%SYS" %SYS>do $system.OBJ.Load("/path/SystemPerformance-IRIS-All-2020.1.0-All.xml","ck") Load started on 05/18/2020 10:02:13 Loading file /path/SystemPerformance-IRIS-All-2020.1.0-All.xml as xml Imported object code: SystemPerformance Load finished successfully. %SYS>

Hi! There is a question for Ensemble on Stackoverflow:I have the below dtl. In the foreach loop, I am just copying the same code in another part under anif condition. How can I avoid this redundancy? Can I reuse using sub transformation?Here is the dtl class file :https://docs.google.com/document/d/1snJXElyw13hAfb8Lmg5IaySc7md_DE8J40FB79hBaXU/edit?usp=sharingOriginal question. Hi, Nic!Thank you for your answer!Would you please put it on Stackoverflow too? http://stackoverflow.com/questions/36400699/how-to-avoid-writing-duplicate-code-in-dtl-intersystem-ensembleThank you in advance! Maybe I'm missing something, but it seems like you could have an OR condition to eliminate the code duplication if condition='ExcludeInactiveAllergiesAlerts="No" OR flag'="No"

# InterSystems Data Platforms and performance - Part 5 Monitoring with SNMP In previous posts I have shown how it is possible to collect historical performance metrics using pButtons. I go to pButtons first because I know it is installed with every Data Platforms instance (Ensemble, Caché, …). However there are other ways to collect, process and display Caché performance metrics in real time either for simple monitoring or more importantly for much more sophisticated operational analytics and capacity planning. One of the most common methods of data collection is to use SNMP (Simple Network Management Protocol). SNMP a standard way for Caché to provide management and monitoring information to a wide variety of management tools. The Caché online documentation includes details of the interface between Caché and SNMP. While SNMP should 'just work' with Caché there are some configuration tricks and traps. It took me quite a few false starts and help from other folks here at InterSystems to get Caché to talk to the Operating System SNMP master agent, so I have written this post so you can avoid the same pain. In this post I will walk through the set up and configuration of SNMP for Caché on Red Hat Linux, you should be able to use the same steps for other \*nix flavours. I am writing the post using Red Hat because Linux can be a little more tricky to set up - on Windows Caché automatically installs a DLL to connect with the standard Windows SNMP service so should be easier to configure. Once SNMP is set up on the server side you can start monitoring using any number of tools. I will show monitoring using the popular PRTG tool but there are many others - [Here is a partial list.](https://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems) Note the Caché and Ensemble MIB files are included in the `Caché_installation_directory/SNMP` folder, the file are: `ISC-CACHE.mib` and `ISC-ENSEMBLE.mib`. #### Previous posts in this series: - [Part 1 - Getting started on the Journey, collecting metrics.](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-1) - [Part 2 - Looking at the metrics we collected.](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-2) - [Part 3 - Focus on CPU.](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-3-focus-cpu) - [Part 4 - Looking at memory.](https://community.intersystems.com/post/intersystems-data-platforms-and-performance-part-4-looking-memory) # Start here... Start by reviewing Monitoring Caché Using SNMP in the [Caché online documentation](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_snmp). ## 1. Caché configuration Follow the steps in _Managing SNMP in Caché_ section in the [Caché online documentation](http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_snmp) to enable the Caché monitoring service and configure the Caché SNMP subagent to start automatically at Caché startup. Check that the Caché process is running, for example look on the process list or at the OS: ps -ef | grep SNMP root 1171 1097 0 02:26 pts/1 00:00:00 grep SNMP root 27833 1 0 00:34 pts/0 00:00:05 cache -s/db/trak/hs2015/mgr -cj -p33 JOB^SNMP Thats all, Caché configuration is done! ## 2. Operating system configuration There is a little more to do here. First check that the snmpd daemon is installed and running. If not then install and start snmpd. Check snmpd status with: service snmpd status Start or Stop snmpd with: service snmpd start|stop If snmp is not installed then you will have to install as per OS instructions, for example: yum -y install net-snmp net-snmp-utils ## 3. Configure snmpd As detailed in the Caché documentation, on Linux systems the most important task is to verify that the SNMP master agent on the system is compatible with the Agent Extensibility (AgentX) protocol (Caché runs as a subagent) and the master is active and listening for connections on the standard AgentX TCP port 705. This is where I ran into problems. I made some basic errors in the `snmp.conf` file that meant the Caché SNMP subagent was not communicating with the OS master agent. The following sample `/etc/snmp/snmp.conf` file has been configured to start agentX and provide access to the Caché and ensemble SNMP MIBs. _Note you will have to confirm whether the following configuration complies with your organisations security policies._ At a minimum the following lines must be edited to reflect your system set up. For example change: syslocation "System_Location" to syslocation "Primary Server Room" Also edit the at least the following two lines: syscontact "Your Name" trapsink Caché_database_server_name_or_ip_address public Edit or replace the existing `/etc/snmp/snmp.conf` file to match the following: ############################################################################### # # snmpd.conf: # An example configuration file for configuring the NET-SNMP agent with Cache. # # This has been used successfully on Red Hat Enterprise Linux and running # the snmpd daemon in the foreground with the following command: # # /usr/sbin/snmpd -f -L -x TCP:localhost:705 -c./snmpd.conf # # You may want/need to change some of the information, especially the # IP address of the trap receiver of you expect to get traps. I've also seen # one case (on AIX) where we had to use the "-C" option on the snmpd command # line, to make sure we were getting the correct snmpd.conf file. # ############################################################################### ########################################################################### # SECTION: System Information Setup # # This section defines some of the information reported in # the "system" mib group in the mibII tree. # syslocation: The [typically physical] location of the system. # Note that setting this value here means that when trying to # perform an snmp SET operation to the sysLocation.0 variable will make # the agent return the "notWritable" error code. IE, including # this token in the snmpd.conf file will disable write access to # the variable. # arguments: location_string syslocation "System Location" # syscontact: The contact information for the administrator # Note that setting this value here means that when trying to # perform an snmp SET operation to the sysContact.0 variable will make # the agent return the "notWritable" error code. IE, including # this token in the snmpd.conf file will disable write access to # the variable. # arguments: contact_string syscontact "Your Name" # sysservices: The proper value for the sysServices object. # arguments: sysservices_number sysservices 76 ########################################################################### # SECTION: Agent Operating Mode # # This section defines how the agent will operate when it # is running. # master: Should the agent operate as a master agent or not. # Currently, the only supported master agent type for this token # is "agentx". # # arguments: (on|yes|agentx|all|off|no) master agentx agentXSocket tcp:localhost:705 ########################################################################### # SECTION: Trap Destinations # # Here we define who the agent will send traps to. # trapsink: A SNMPv1 trap receiver # arguments: host [community] [portnum] trapsink Caché_database_server_name_or_ip_address public ############################################################################### # Access Control ############################################################################### # As shipped, the snmpd demon will only respond to queries on the # system mib group until this file is replaced or modified for # security purposes. Examples are shown below about how to increase the # level of access. # # By far, the most common question I get about the agent is "why won't # it work?", when really it should be "how do I configure the agent to # allow me to access it?" # # By default, the agent responds to the "public" community for read # only access, if run out of the box without any configuration file in # place. The following examples show you other ways of configuring # the agent so that you can change the community names, and give # yourself write access to the mib tree as well. # # For more information, read the FAQ as well as the snmpd.conf(5) # manual page. # #### # First, map the community name "public" into a "security name" # sec.name source community com2sec notConfigUser default public #### # Second, map the security name into a group name: # groupName securityModel securityName group notConfigGroup v1 notConfigUser group notConfigGroup v2c notConfigUser #### # Third, create a view for us to let the group have rights to: # Make at least snmpwalk -v 1 localhost -c public system fast again. # name incl/excl subtree mask(optional) # access to 'internet' subtree view systemview included .1.3.6.1 # access to Cache MIBs Caché and Ensemble view systemview included .1.3.6.1.4.1.16563.1 view systemview included .1.3.6.1.4.1.16563.2 #### # Finally, grant the group read-only access to the systemview view. # group context sec.model sec.level prefix read write notif access notConfigGroup "" any noauth exact systemview none none After editing the `/etc/snmp/snmp.conf` file restart the snmpd deamon. service snmpd restart Check the snmpd status, note that AgentX has been started see the status line: __Turning on AgentX master support.__ h-4.2# service snmpd restart Redirecting to /bin/systemctl restart snmpd.service sh-4.2# service snmpd status Redirecting to /bin/systemctl status snmpd.service ● snmpd.service - Simple Network Management Protocol (SNMP) Daemon. Loaded: loaded (/usr/lib/systemd/system/snmpd.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2016-04-27 00:31:36 EDT; 7s ago Main PID: 27820 (snmpd) CGroup: /system.slice/snmpd.service └─27820 /usr/sbin/snmpd -LS0-6d -f Apr 27 00:31:36 vsan-tc-db2.iscinternal.com systemd[1]: Starting Simple Network Management Protocol (SNMP) Daemon.... Apr 27 00:31:36 vsan-tc-db2.iscinternal.com snmpd[27820]: Turning on AgentX master support. Apr 27 00:31:36 vsan-tc-db2.iscinternal.com snmpd[27820]: NET-SNMP version 5.7.2 Apr 27 00:31:36 vsan-tc-db2.iscinternal.com systemd[1]: Started Simple Network Management Protocol (SNMP) Daemon.. sh-4.2# After restarting snmpd you must restart the Caché SNMP subagent using the `^SNMP` routine: %SYS>do stop^SNMP() %SYS>do start^SNMP(705,20) The operating system snmpd daemon and Caché subagent should now be running and accessible. ## 4. Testing MIB access MIB access can be checked from the command line with the following commands. `snmpget` returns a single value: snmpget -mAll -v 2c -c public vsan-tc-db2 .1.3.6.1.4.1.16563.1.1.1.1.5.5.72.50.48.49.53 SNMPv2-SMI::enterprises.16563.1.1.1.1.5.5.72.50.48.49.53 = STRING: "Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2015.2.1 (Build 705U) Mon Aug 31 2015 16:53:38 EDT" And `snmpwalk` will 'walk' the MIB tree or branch: snmpwalk -m ALL -v 2c -c public vsan-tc-db2 .1.3.6.1.4.1.16563.1.1.1.1 SNMPv2-SMI::enterprises.16563.1.1.1.1.2.5.72.50.48.49.53 = STRING: "H2015" SNMPv2-SMI::enterprises.16563.1.1.1.1.3.5.72.50.48.49.53 = STRING: "/db/trak/hs2015/cache.cpf" SNMPv2-SMI::enterprises.16563.1.1.1.1.4.5.72.50.48.49.53 = STRING: "/db/trak/hs2015/mgr/" etc etc There are also several windows and \*nix clients available for viewing system data. I use the free iReasoning MIB Browser. You will have to load the ISC-CACHE.MIB file into the client so it knows the structure of the MIB. The following image shows the iReasoning MIB Browser on OSX.  ## Including in Monitoring tools This is where there can be wide differences in implementation. The choice of monitoring or analytics tool I will leave up to you. _Please leave comments to the post detailing the tools and value you get from them for monitoring and managing your systems. This will be a big help for other community members._ Below is a screen shot from the popular _PRTG_ Network Monitor showing Caché metrics. The steps to include Caché metrics in PRTG are similar to other tools.  ### Example workflow - adding Caché MIB to monitoring tool. #### Step 1. Make sure you can connect to the operating system MIBs. A tip is to do your trouble-shooting against the operating system not Caché. It is most likely that monitoring tools already know about and are preconfigured for common operating system MIBs so help form vendors or other users may be easier. Depending on the monitoring tool you choose you may have to add an SNMP 'module' or 'application', these are generally free or open source. I found the vendor instructions pretty straight forward for this step. Once you are monitoring the operating system metrics its time to add Caché. #### Step 2. Import the `ISC-CACHE.mib` and `ISC-ENSEMBLE.mib` into the tool so that it knows the MIB structure. The steps here will vary; for example PRTG has a 'MIB Importer' utility. The basic steps are to open the text file `ISC-CACHE.mib` in the tool and import it to the tools internal format. For example Splunk uses a Python format, etc. _Note:_ I found the PRTG tool timed out if I tried to add a sensor with all the Caché MIB branches. I assume it was walking the whole tree and timed out for some metrics like process lists, I did not spend time troubleshooting this, instead I worked around this problem by only importing the performance branch (cachePerfTab) from the `ISC-CACHE.mib`. Once imported/converted the MIB can be reused to collect data from other servers in your network. The above graphic shows PRTG using Sensor Factory sensor to combine multiple sensors into one chart. # Summary There are many monitoring, alerting and some very smart analytics tools available, some free, others with licences for support and many and varied functionality. You must monitor your system and understand what activity is normal, and what activity falls outside normal and must be investigated. SNMP is a simple way to expose Caché and Ensemble metrics. I was asked a couple of questions offline, so the following is to answer them: _Q1. In your article, why do you say it is necessary to change information strings in snmpd.conf? (ie. syslocation/syscontact)?_ A1. What I mean is that you should change syslocation and syscontact to reflect your site, but leaving them as the defaults in the sample will not stop SNMP working using this sample `snmpd.conf`file. _Q2. you also mention basic errors you made in configuring it, which were these? It might be helpful to mention the debugging facilities for snmp `(^SYS("MONITOR","SNMP","DEBUG") )` as well?_ A2. One problem was misconfiguring the security settings in `snmpd.conf`. Following the example above will get you there. I also spun my wheels with what turned out to be a spelling (or case) error on the line `agentXSocket tcp:localhost:705`. In the end I figured out the problem was to do with agentX not starting by looking at the logs written to the `install-dir/mgr/SNMP.log` file. Caché logs any problems encountered while establishing a connection or answering requests in the `SNMP.log`. You should also check `cconsole.log` and the logs for snmpd in the OS. On Windows, iscsnmp.dll logs any errors it encounters in %System%\System32\snmpdbg.log (on a 64–bit Windows system, this file is in the SysWOW64 subdirectory). As pointed out in Fabian's question more information can be logged to the SNMP.log if you set ^SYS("MONITOR","SNMP","DEBUG")=1 in the %SYS namespace and restart the ^SNMP Caché subagent process. This logs details about each message received and sent. Thanks for the questions MO BTW Although I have not tried implementing - due to high number of Healthcare applications using Caché I thought it may be of interest that Paessler PRTG has developed new sensors for monitoring medical equipment that communicate via HL7 and DICOM.https://www.paessler.com/blog/2016/04/13/all-about-prtg/ehealth-sensors-know-what-is-going-on-in-your-medical-it I've installed PRTG on a windows 10 system... enabled SNMP services... I've configured SNMP Service to Community "public" destination "127.0.0.1"... PRTG is able to see and graph the system statistics... OK.Then I imported ISC-Cache.mib with Paesler MIB Imported, OK, and "Save for PRTG Network Monitor"... everything seems fine, but, then, where is supposed to be? When I go to PRTG NM I cannot see anyhing related to Caché ... no clue about the library that I supposedly just imported... S of SNMP means Simple... so I'm pretty sure I'm missing something really basic here, but I don't know how to go on. Found... I just got to go to add sensors to a group, windows type and snmp library... there it is the oidlib I had just imported!! When using containers (IRIS) how do use the host to proxy the snmp calls? is there a way to have the container use the hosts ip (and port 705) to do its reporting? Hi Jay, for the docker run command look at the --net=host flag. Also SAM might be of interest to you. See the recent announcement and a user case I hope it's helpful do we hv a similar topic for Cache on windows？Thx！

Learn the fundamentals of how and when to use the DeepSee Analyzer. DeepSee Analyzer BasicsThis course describes typical use cases for the Analyzer and shows how to access the Analyzer from the Management Portal. You will learn how use drag and drop to create simple queries, and then refine these queries by sorting, applying filters, and drilling down. Learn More.

Caché Localization Manager CLM is a tool for localization/internationalization/adding multi-language support to a project based on InterSystems Caché. Imagine that you have a ready project where all the content is in Russian, and you need to add an English localization to it. You wrap all your strings into resources, translate them into English and call the necessary resource for Russian or English when necessary. Nothing tricky, if you think about it. But what if there are lots of strings and there are mistakes in Russian (or English)? What if you need to localize in more than one language – say, ten? This is exactly the kind of project where you should use CLM. It will help you localize the entire content of your project into the necessary language and retain the possibility to correct entries. CLM allows you to do the following: Add a new localization.Delete a localization.Export a localization.Import a localization.View two tables at a time.Conveniently switch between spaces.Check spelling. Let’s “look under the hood” now Caché has a standard approach to implementing I11N using the $$$TEXT macros: $$$TEXT("Text", "Domain", "Language") where: Text — the text to be used for localization in the future. Domain — modules in your applications. Language — the language of "Text". If you use $$$TEXT in COS code, data is added to the ^CacheMsg global during class compilation. And this is the global that CLM works with. In ^CacheMsg, everything is identical to $$$TEXT, you just add "ID" as the text hash. ^CacheMsg("Domain", "Language", "ID") = "Text" If you are using CSP, then the use of $$$TEXT in CSP will look as follows: <csp:text id="14218931" domain="HOLEFOODS">Date Of Sale</csp:text> Installation First of all, you need to download the Installed class from GitHub and import it to any convenient space in Caché. I will use the USER space. Once done, open the terminal and switch to the USER space. To start the installation, enter the following command in the terminal: USER> do ##class(CLM.Installer).setup() Installation process: You can make sure the application is installed correctly by following this link: http://localhost:57772/csp/clm/index.csp (localhost:57772 — the path to your server). Settings CLM uses Yandex to perform the translation. You will now need to obtain a Yandex API key to let it work. It's free, but needs registration. Let’s now deal with spellchecking. CLM uses Caché Native Access for SpellCheck implementation. CNA was written for calling external functions from dynamic libraries, such as .dll or .so. SpellCheck works with the Hunspell library and needs two files for spellchecking. The first file is a dictionary containing words, the second one contains affixes and defines the meaning of special marks (flags) in the dictionary. How words are checked: All words are packed from CLM and sent to Hunspell via CNA, where CNA converts them into a language that Hunspell understands. Hunspell checks every word, finds the root form and all possible variations, and returns the result. But where do we get all these dictionaries and libraries? — CNA: use an available release or build it on your own. — Hunspell: same thing, use an available version or download sources for making your own build. — We will also need a standard C language library. In Windows, it is located here: C:\Windows\System32\msvcrt.dll. — Dictionaries can be downloaded here. At the moment, 51 languages are supported: Albanian Czech German Latin Romanian VietnameseArabian Chinese Greek Latvian RussianArmenian Danish Hebrew Lithuanian SpanishAzeri Dutch Hungarian Macedonian SerbianBelarusian English Icelandic Malay SlovakBosnian Estonian Indonesian Maltese SlovenianBasque Esperanto Italian Norwegian SwedishBulgarian Finnish Japanese Polish ThaiCatalan French Kazan Portuguese TurkishCroatian Georgian Korean Brazil Ukrainian The entire configuration process boils down to entering the paths to everything you got before. Open CLM in a browser. There is a “Set Paths” button in the upper right corner. Click it and you’ll see the next window. Use it to enter the required paths. Here’s what I got: Demonstration of a registration form localization Link to demonstration. Password and login: demo. Your critique, comments and suggestion are very welcome. The source code and instructions are available on github under an MIT license. An interesting article, but I'm puzzled by your use of the term "I11n". I'm familiar with "I18n" as an abbreviation for Internationalization (because there are 18 letters between the "I" and the "n". Likewise, I understand "L10n" as standing for Localization. Some Googling suggests that "I11n" is short for Introspection. Or have I missed something? Hi, John!i11n here stands for "internationalization" i18n - internationalization, but i11n is something else True. Title is fixed

# Index This is a list of all the posts in the Data Platforms’ capacity planning and performance series in order. Also a general list of my other posts. I will update as new posts in the series are added. > You will notice that I wrote some posts before IRIS was released and refer to Caché. I will revisit the posts over time, but in the meantime, Generally, the advice for configuration is the same for Caché and IRIS. Some command names may have changed; the most obvious example is that anywhere you see the `^pButtons` command, you can replace it with `^SystemPerformance`. --- > While some posts are updated to preserve links, others will be marked as strikethrough to indicate that the post is legacy. Generally, I will say, "See: some other post" if it is appropriate. --- #### Capacity Planning and Performance Series Generally, posts build on previous ones, but you can also just dive into subjects that look interesting. - [Part 1 - Getting started on the Journey, collecting metrics.][1] - [Part 2 - Looking at the metrics we collected.][2] - [Part 3 - Focus on CPU.][3] - [Part 4 - Looking at memory.][4] - [Part 5 - Monitoring with SNMP.][5] - [Part 6 - Caché storage IO profile.][6] - [Part 7 - ECP for performance, scalability and availability.][7] - [Part 8 - Hyper-Converged Infrastructure Capacity and Performance Planning][8] - [Part 9 - Caché VMware Best Practice Guide][9] - [Part 10 - VM Backups and IRIS freeze/thaw scripts][10] - [Part 11 - Virtualizing large databases - VMware cpu capacity planning][11] #### Other Posts This is a collection of posts generally related to Architecture I have on the Community. - [AWS Capacity Planning Review Example.][29] - [Using an LVM stripe to increase AWS EBS IOPS and Throughput.][28] - [YASPE - Parse and chart InterSystems Caché pButtons and InterSystems IRIS SystemPerformance files for quick performance analysis of Operating System and IRIS metrics.][27] - [SAM - Hacks and Tips for set up and adding metrics from non-IRIS targets][12] - [Monitoring InterSystems IRIS Using Built-in REST API - Using Prometheus format.][13] - [Example: Review Monitor Metrics From InterSystems IRIS Using Default REST API][14] - [InterSystems Data Platforms and performance – how to update pButtons.][15] - [Extracting pButtons data to a csv file for easy charting.][16] - [Provision a Caché application using Ansible - Part 1.][17] - [Windows, Caché and virus scanners.][18] - [ECP Magic.][19] - [Markdown workflow for creating Community posts.][20] - [Yape - Yet another pButtons extractor (and automatically create charts)][21] See: [YASPE](https://community.intersystems.com/post/yaspe-yet-another-system-performance-extractor). - [How long does it take to encrypt a database?][22] - [Minimum Monitoring and Alerting Solution][23] - [LVM PE Striping to maximize Hyper-Converged storage throughput][24] - [Unpacking pButtons with Yape - update notes and quick guides][25] - [Decoding Intel processor models reported by Windows][26] Murray Oldfield Principle Technology Architect InterSystems Follow the community or @murrayoldfield on Twitter [1]: https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-1 [2]: https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-2 [3]: https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-3-focus-cpu [4]: https://community.intersystems.com/post/intersystems-data-platforms-and-performance-part-4-looking-memory [5]: https://community.intersystems.com/post/intersystems-data-platforms-and-performance-part-5-monitoring-snmp [6]: https://community.intersystems.com/post/data-platforms-and-performance-part-6-cach%C3%A9-storage-io-profile [7]: https://community.intersystems.com/post/data-platforms-and-performance-part-7-ecp-performance-scalability-and-availability [8]: https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-8-hyper-converged-infrastructure-capacity [9]: https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-part-9-cach%C3%A9-vmware-best-practice-guide [10]: https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-vm-backups-and-cach%C3%A9-freezethaw-scripts [11]: https://community.intersystems.com/post/virtualizing-large-databases-vmware-cpu-capacity-planning [12]: https://community.intersystems.com/post/sam-hacks-and-tips-set-and-adding-metrics-non-iris-targets [13]: https://community.intersystems.com/post/monitoring-intersystems-iris-using-built-rest-api [14]: https://community.intersystems.com/post/example-review-monitor-metrics-intersystems-iris-using-default-rest-api [15]: https://community.intersystems.com/post/intersystems-data-platforms-and-performance-%E2%80%93-how-update-pbuttons [16]: https://community.intersystems.com/post/extracting-pbuttons-data-csv-file-easy-charting [17]: https://community.intersystems.com/post/provision-cach%C3%A9-application-using-ansible-part-1 [18]: https://community.intersystems.com/post/windows-cach%C3%A9-and-virus-scanners [19]: https://community.intersystems.com/post/ecp-magic [20]: https://community.intersystems.com/post/markdown-workflow-creating-community-posts [21]: https://community.intersystems.com/post/yape-yet-another-pbuttons-extractor-and-automatically-create-charts [22]: https://community.intersystems.com/post/how-long-does-it-take-encrypt-database [23]: https://community.intersystems.com/post/minimum-monitoring-and-alerting-solution [24]: https://community.intersystems.com/post/lvm-pe-striping-maximize-hyper-converged-storage-throughput [25]: https://community.intersystems.com/post/unpacking-pbuttons-yape-update-notes-and-quick-guides [26]: https://community.intersystems.com/post/decoding-intel-processor-models-reported-windows [27]: https://community.intersystems.com/post/yaspe-yet-another-system-performance-extractor [28]: https://community.intersystems.com/post/using-lvm-stripe-increase-aws-ebs-iops-and-throughput [29]: https://community.intersystems.com/post/aws-capacity-planning-review-example

Take this online course to learn the foundations of the Caché ObjectScript language especially as it relates to use in creating variables and objects in Caché. You will learn about variables, commands, and operators as well as how to find more information using the InterSystems DocBooks when needed. This course contains instructional videos and exercises.Learn More.