Mehdi Daoudi

Open banking and APIs are at the heart of the digital finance revolution. Monitoring APIs helps protect banks from issues including failures and slow-downs.

It would be best if you had digital experience monitoring for a transparent view of your IT infrastructure and how well it supports the needs of your customers.

This article focuses on the basics of BGP (Border Gateway Protocol) for the non-network engineer.

Discover the 3 primary monitoring blind spots and what you and your team can do to stay aware of ever-hidden performance problems.

The edge is a new frontier. It throws up many new challenges that the enterprise must consider in relation to their monitoring strategy.

Learn why it’s no longer a best practice to host JavaScript a content delivery network (CDN) due to security considerations, network penalties, and to avoid a single point of failure.

We have all kinds of chief officers. Is now the time for Chief Performance Officers (CPO)? With more onus on performance, maybe so.

in this heat map example, web site’s performance data is overlay with color, where red means “slowest” and green means “fastest” (with various color grades in between). i added this heat map example because the chart data was difficult to “crunch”, to analyze for patterns; adding color made this easier. download the excel sheet here . otherwise, see the below “before” and “after”. before: raw chart data: after: heat map: side by side: the chart data is the arithmetic mean average of six weeks’ worth of web site response time measurements (in milliseconds), broken down by day of week and by hour of day. i then used excel’s built-in /conditional formatting/color scales/red – yellow – green color scale/. document complete / onload: _the following is optional reading material._ here are some potential fact statements we get from looking at this heat map: 01. the weekends are the “fastest”. 02. the weekdays are the “slowest”. 03. response time slows starting at around 07:00 am pt and response time speeds starting at around 07:00 pm pt. 04. the “slowest” (i.e. the most red) “day of week”/”hour of day” combination is wednesday at 05:00 pm pt. 05. the “fastest” (i.e. the most green) “day of week”/”hour of day” combination is wednesday at 02:00 am pt. 06. interestingly enough, the “fastest” and “slowest” “day of week”/”hour of day” combination was on a wednesday. 07. friday afternoons were “faster” when compared to other weekday afternoons (insert comment here re: folks getting ready for the weekend!). download the excel file here: https://docs.google.com/open?id=0b9n5sarv4oonmedtotlvohnib0e ******************************************************************************** i used his model to chart the performance heat map of google search (search for a keyword) and decided to compare the wait time (1st byte) and their search query time: google’s wait time vs. google search query time here is the same for etsy’s home page, wait time and the etsy server time: etsy’s wait time vs. etsy’s server time (data from june 1 2012 to july 13 2012, time in est) i used these 2 examples mainly because not only we are plotting a catchpoint metric but also overlaying customer telemetry coming from google (how long it takes for google to spit the results) or etsy (how long it takes for their server to build the html). what would be cool is to get traffic volume during those days and hours to correlate the performance metrics and usage pattern. but what these chart show is clearly a performance degradation during certain days and hours of day that are driven by volume, users, usage… enjoy the summer and try to keep your web performance cool! thank you leo for sharing this!