Some time ago I posted an article about how to calculate RPS in Application Insight or KQL (a.k.a. AQL).
Turns out, that query only works under heavy load. By heavy load I mean a kind of traffic that has activity per unit of your bin (per second.)
We use BitBucket for our source control and VSTS for CI. VSTS build definition has a trigger option which will monitor the repository every so many seconds (min is 60s) and if new changes are there it will trigger the build. But that feature only works when you have VSTS repositories and for any external repository the developer needs to login to VSTS after the changes are pushed and wait for at least 60 seconds for the build to kick off. I’m pretty sure that manually triggering the build takes less time. Also, that model by itself is not efficient specially in the world of Webhooks.
BitBucket supports Webhooks. For example you can call add Webhooks for each push (unfortunately you can not specify a branch). The problem is that VSTS CI build definition does not accept Webhooks as trigger.
In this post I’m going to show how this can be done by using BitBucket Webhooks , Azure Function Apps and VSTS REST API.
This week we decided to create a new isolated mission critical but dead simple and small api in order to publish our web api endpoint address to the mobile clients.
The use-case is very simple: pass platform, version and environment (dev/prod) and receive the api that you need to work with.
Why did we decide that?
This is going to help us seamlessly and gradually shift between old production environment to the new production environment.
Last week I watched a presentation about Azure Function Apps and kind of fell in love with the concept.
Because of the following advantages I knew right a way that’s the best solution for us in order to implement that single, very small and mission critical api method:
This week while starting to do the design an implementation and after some experiments I decided to go with API Apps instead, because of following reasons:
These days I’m on a mission to balance our server sizes in Azure with the actual usage. As part of that it’s very important to know our real RPS (Requests per Second).
When you plug your app to Azure AppInsight many valuable data will be captured and recorded. Azure itself, provides some basic queries for showing some useful charts about your usage. For example, response duration, dependency duration etc. however, there will be a time where you need to run your own specific query in order to make business related decisions. At that stage Azure AppInsight Analytics comes to play with an online query builder/editor to help you run custom queries, draw charts and extract meaningful information. Continue reading Calculating Request per Second (RPS) in Azure