It is clear that the auto-scale service allows to automatically scale-in and scale-out an application horizontally. And that I can manually scale vertically my application too by MANUALLY increasing/decreasing the memory.
Is there a way to AUTOMATICALLY increase and decrease the memory associated to the node.js instances based on some rules?
Note Bluemix charges the application based on GB * Hour. So by large you will be charged similarly among vertical scaling and horizontal scaling. However, vertical scaling does improves memory usage efficiency because there is less memory overhead (e.g., you load the node.js runtime only once rather than twice ore more). But horizontal scaling also has its merits:
Better availability due to increased app instances;
Better concurrency due to distributed processes;
Potential better exploration of CPU resource (because of the way CGroup works for CPU allocation).
So if your application is memory-hungry, allocating large memory for each instance would make sense. Otherwise if the app is CPU hungry, then horizontal scaling may work better. You can do some benchmark to evaluate the response time and throughput impact of both options.
The Auto-Scaling add-on in Bluemix monitors the chosen resources against their policies and increases or decreases the number of instances, not vertical scaling (memory).
Why does your node app's memory requirements grow? Can you offload some of it by using a database or cashing service? Relying on increasing memory when needed is currently a bad practice because it will require a small downtime as your application restarts.
As Ram mentioned. The Auto-Scaling service doesn't currently support vertical scaling.
You can scale horizontally by discrete numbers of instances or by a % of the total number of instances.
See the docs for which metrics are supported by each application type
edit: typo!
Related
I am designing a learning management system and inflow for the website is more in some cases and less in another time. I would like to know about the getting the vCPU's which are scaled up to make it down after the stipulated time. I found a document regarding scaling up but didn't find a way to scale it down.
Any help is appreciated.
There is a chance of auto scaling for the normal services in azure cloud services, that means for stipulated time you can increase or decrease as mentioned in the link.
When it comes for vCPU which is cannot be performed automatically. vCPU can be scaled up based on the request criteria and in the same manner we need to request the support team to scale those down to the normal.
There is no specific procedure to make the auto scaling for vCPU operations. We can increase the capacity of core, but to reduce to the normal, we need to approach the support system for manual changing. You can change it from 10 cores to next level 16 cores, but cannot be performed automatic scaling down from 16 cores to 10 cores.
I'm experiencing poor on Azure web apps when scaling out. Azure automatically picks up an issue from a set of rules I have set up (like CPU > 80% for 5 minutes). Then it increases the number of VMs by 1. Here is a screenshot of the settings on Azure:
This part works fine. But while it is scaling to one additional VM, I'm experiencing poor performance on the entire website. When the new VM is up and running, everything seems to work as expected.
I have previously observed similar issues when scaling up and down the VM size but this is "just" a new VM.
I have already tried to create application initialization in my Web.config:
<applicationInitialization doAppInitAfterRestart="true">
<add initializationPage="/" />
</applicationInitialization>
Still poor performance while scaling out. Does anyone know what this could be caused by? I wouldn't expect a website to perform worse while scaling. I know that the performance probably isn't that great when the VM reaches 80% CPU. But the performance is definitely worse as soon as Azure starts scaling.
Kindly ensure that the margin between the scale out\in are not small. I have seen cases where the auto scale flapping was the issue.
To avoid a "flapping" situation, where scale-in and scale-out actions continually go back and forth. It is recommended to choose an adequate margin between the scale-out and in thresholds.
Just a adding a few best practices guide for you to review the metric threshold.
Ensure the maximum and minimum values are different and have an adequate margin between them - E.g- If you have a setting that has minimum=2, maximum=2 and the current instance count is 2, no scale action can occur. Keep an adequate margin between the maximum and minimum instance counts, which are inclusive. Autoscale always scales between these limits.
Always use a scale-out and scale-in rule combination that performs an increase and decrease - If you use only one part of the combination, autoscale will only take action in a single direction (scale out, or in) until it reaches the maximum, or minimum instance counts of defined in the profile.
This is not optimal, ideally you want your resource to scale up at times of high usage to ensure availability. Similarly, at times of low usage you want your resource to scale down, so you can realize cost savings. I suggest you review the threshold for the metrics and example outlined in this documentation Autoscale best practices, and let us know if it helps.
What cloud resource metrics (memory, CPU, disk io etc) should I be looking at for auto scaling purpose? FYI, The metrics is strictly used for auto scaling purpose. I have kubernetes architecture and prometheus (for monitoring and scraping metrics)
I have a kubernetes cluster set up in local as well as cloud. I am using Prometheus tool(https://prometheus.io/) set up for scraping system level metrics. Now, I want to have Auto-scaling feature in my system. I have been using prometheus for saving metrics like this. "Memory and CPU used, allocated, total for the last 24 hours." I want to save more metrics. This is the list of metrics that I am getting from Prometheus: http://demo.robustperception.io:9100/metrics I can't decide what more metrics I am going to need for auto scaling purpose. Can anyone suggest some metrics for this purpose? TIA.
Normally, the common bottleneck is the memory hierarchy rather than CPU usage. The more requests your application receives, the more likely to have an out-of-memory error. What is more, if your application is not HPC, it is not likely that it needs to be so CPU-intensive.
In the memory hierarchy, Disk I/O can dramatically affect performance. You would need to check how Disk I/O intensive your application is. In this sense, changing the disk hardware could be a better solution rather than spinning up more instances. However, that depends on the application.
In any case, it would be interesting if you could measure the average response time, and then take decisions accordingly.
I am using a azure websites solution with 20 websites. Hosted on 4 cores, 8 GB RAM standard instance. I would like to know how I could do scaling in Azure websites and when to do it ?
Also I am reading some values from the new azure portal.
Can someone guide me on the values that I see here ?
Thank you
Averages
The Avg % is telling you, on average, how much of that resource is being used. So, if you have 8GB of ram, and you are typically using 66% of it, then you are averaging 5.28 Gb of ram used. Same goes for the CPU average listed below.
For the totals, I have no idea.
You're not using much of the CPU available to you here, but you are definitely taking advantage of the RAM. I'm not sure of what kind of web application you are running though, so it's dificult to determine what could be causing this.
Scaling
In terms of scaling, I always suggest starting with a small machine, then gradually scaling up.
Based on your usage, I'd drop to a machine that has fewer CPU cores, but more available RAM. From within your dashboard, you can see how to scale by clicking no your web app, then scrolling down. Click on the scale tab and it should appear as it does below:
You can now adjust what you want to scale by. The default setting is CPU Percentage, but that isn't particularly useful in this case. Instead, select Schedule and performance rules and a new panel wioll appear. On the right hand side, select Metric name and look for Memory Percentage.
In your particular case, this is helpful as we saw that your RAM is consistently being used.
Look at Action and you will want to Increase count by and change the number of VMs to 1. What this does is when your RAM reaches a certain usage %, Azure will auto-scale and generate a new VM for you. After a cool down period of 5 minutes (the default, listed at the bottom), your machine will revert to 1 machine.
Conclusion
With these settings, each time your website uses <= (Select your percentage) of RAM, Azure will increase the size of your machines.
In your case, I suggest using fewer cores, but more RAM.
Make sure you save your settings, with the Save button above.
Scott Hanselman as a great blog post on how to make sense of all of this.
On Azure I can get 3 extra small instances for the price 1 small.I'm not worried about my site not scaling.
Are there any other reasons I should not go for 3 extra small instead of 1 small?
See: Azure pricing calculator.
An Extra Small instance is limited to approx. 5Mbps bandwidth on the NIC (vs. approx. 100Mbps per core with Small, Medium, Large, and XL), and has less than 1GB of RAM. So, let's say you're running something that's very storage-intensive. You could run into bottlenecks accessing SQL Azure or Windows Azure storage.
With RAM: If you're running 3rd-party apps, such as MongoDB, you'll likely run into memory issues.
From a scalability standpoint, you're right that you can spread the load across 2 or 3 Extra Small instances, and you'll have a good SLA. Just need to make sure your memory and bandwidth are good enough for your performance targets.
For more details on exact specs for each instance size, including NIC bandwidth, see this MSDN article.
Look at the fine print - the I/O performance is supposed to be much better with the small instance compared to the x-small instance. I am not sure if this is due to a technology related bottleneck or a business decision, but that's the way it is.
Also I'm guessing the OS takes a bit of RAM in each of the instances, so in 3 X-small instances it takes it up three times instead of just once in a small instance. That would reduce the resources that are actually available for your application needs.
While 3 xtra-small instances theoretically may equal or even be better "on paper" than one small instance, do remember that xtra-small instances do not have dedicated cores and their raw computing resources are shared with other tenants. I've tried these xtra-small instances in an attempt to save money for tiny-load website and must say that there were simply outages or times of horrible performance that I've found unacceptable.
In short: I would not use xtra-small instances for any sort of production environment