I travel a lot. But occasionally I get asked “Why”. The answer to that is pretty simple and comes down to three simple things.

1. When I just out of high school (18 years old ish) I had no clue what I’d be doing for a living. My first real job out of high school was working Tech Support at an Internet Service Provider (ISP). I liked working with computers, and I’ve clearly stuck with it. Like most Americans, I had no idea that I’d have a chance to see much if any of the world outside of the US. I wasn’t sure what I’d do, or where I’d go. And I’ve been very fortunate that I’ve been able to see as much of the world as I’ve been able to so far. What this rambling reason really means is that because I can, I do. The world is a very cool place full of some exciting things, and I’ve been fortunate to be able to see as many of them as I can.

2. I’ve made a ton of friends around the world and many of them I wouldn’t get to see very often if I didn’t travel so much. Sometimes these folks see me in San Diego, sometimes they see me in other cities like Seattle, it just depends. Some perfect examples come to mind (I’m sitting in a hotel in Amsterdam as I’m writing this); tonight I’m having dinner with a friend from Holland since I happen to be in town; or when I saw a friend from Slovenia every month for about a year because we happened to go to the same conferences every month. It’s so cool to be able to see friends that live all over the world instead of just catching up with them in letters or online.

3. By going to some of the places that I’ve been, I’ve been able to meet people that I would never have met before and seen things that I would never have seen from one. A perfect example of that is when I went to Saudi Arabia to speak at a conference there. We had an extra day between arriving and the conference so a bunch of us when to visit the National Museum that was a few blocks away. We were able to tour the museum, which most people wouldn’t be able to do simply because of the cost of getting there and the fact that Saudi Arabia doesn’t have any way for tourists to visit. You either go there on business, or you don’t go there.

So as to why I travel so much really boils down to these three things. I definitely understand that I’m fortunate to be able to travel, especially as much as I do, especially considering my health issues from just a couple of years ago.  So because of all of this, I travel as much as I can, as often as I can (yes, I work when I travel) so I can see places and meet people because there’s a lot to see out there and I want to see as much of it as I can.

Denny

The post Why I Travel So Much appeared first on SQL Server with Mr. Denny.

I was going to New York last weekend from my home of Philadelphia. We were running late for the train, and for the first time ever, I had a booked an award ticket on Amtrak. For reasons unbeknownst to me, you can not make changes to an award ticket on their app (I didn’t try the website). Additionally, when you call the standard Amtrak line, the customer service reps can’t change an award ticket, unless you have defined a PIN. This PIN is defined by telling an awards customer service rep what you want your PIN to be. (Because that’s really secure). While this is all god awful business process, that is exacerbated by crappy IT, it’s really down to bad business processes.

Photo by SenuScape on Pexels.com

The bad application design came into play, when the Awards rep, tried to change my ticket, and she asked “do you have it open in our app? I can’t make changes to it if you have it open.” My jaw kind of dropped when this happened, but I went ahead and closed the app. Then the representative was able to make this change. We had to repeat the process when the representative had booked us into the wrong class of service. (The rep was excellent and even called me back directly).

But let’s a talk about the way most mobile apps work. There are a series of front-end screens that are local to your device, and most of the interaction is handled through a series of Rest API calls. The data should be cached locally to your device after the API call, so it can still be read in the event of your device being offline. If you are a database professional, you are used to the concept of ACID (Atomicity, Consistency, Isolation, Durability), which is how we ensure things like bank balances in our databases can remain trusted. In general, a tenant of most databases applications is that readers should never block writers–if a process needs to write to a record someone reading the record should not effect that operation. There are exceptions to this rule, but these rules are generally enforced by the RDBMS in conjunction with the isolation level of the database.

Another tenant of good database development is that you should do what you are doing, and get the hell out of the database. Whether you are reading or writing, you should get the data you need and then return either the data or the status of the transaction to your app. Otherwise, you are going to keep your transaction open, and impact other transactions, in a generally unpredictable set of timings. That’s the whole point of using the aforementioned Rest API calls–they do a thing, return your data, or that you updated some data, and then get the hell out.

What exactly is Amtrak’s app doing? Obviously I don’t have any backend knowledge, but based on that comment from the CS rep, opening your reservation in the mobile app, opens a database transaction. That doesn’t close. I can’t fathom why anyone would ever design an app this way, and I can’t think of a tool that would easily let you design an app like this. At some point, someone made a really bad design choice.

I’m not sure when this feature got introduced, but I just saw it for the first time recently (and I asked for it when Azure Database for MySQL server was in private preview); but Azure Database for MySQL server can show you the slow queries that are running against the MySQL database. In fact, it’ll log more than just the slow queries, queries that don’t have an index can be logged as well as long-running queries.

If you open the properties of a database in the Azure portal, there’s a couple of different places you can set these settings. The first is on the “Server parameters” blade where you’ll see all the various parameters that you can set for the MySQL deployment. The second is if you select the “Server Logs” option towards the bottom (it’s in the Monitoring section) you’ll see the log files that are being created (if there’s any). At the top of this page, you’ll see a blue bar which says, “Click here to enable logs and configure log parameters.” If you click that it’ll show you a shorter list of the parameters which only includes the settings that are related to the log file (shown in the screenshot).

Once you enable the settings that you need wait a few minutes for there to be load on the system, then go into the “Server Logs” setting of the Azure portal, and you’ll see a log file that you can download. Just open it in notepad (or your favorite text editor), and you’ll see the various log records that you enabled.

While I was playing around with this, I turned on the slow queries option, and I got a bunch of records in the log about queries that WordPress needs to do some tuning on. Since I’m guessing WordPress won’t be doing any database tuning, I’ll have to do it myself. But now that I have some data to work off of, I at least have a starting point.

Denny

The post Azure Database for MySQL server has a slow query log now appeared first on SQL Server with Mr. Denny.

A couple of weeks ago DCAC moved our website from being hosted in a single data center to being a globally distributed web application with multiple Azure WebApps with one hosted in the US and one in Europe.  As part of having traffic manager configured and enabled for our site, we get some free reporting on performance of our webapp that’s included as part of the package.  As you can see from our performance chart which we can see on the left, we can see where in the world our readers are coming from, and depending on if the system is able to capture it or not, we can see the performance that those users are getting (all the colors in the chart).

For some users, we aren’t able to get back performance data, and those users are shown in White. The users who are shown in a color (blue/green is good, red is bad) the system was able to get performance data for.

There is a little change which helps gather real-time measurements of data.  Within the settings for Traffic Manager, there’s a setting for “Real Time measurements” which gives you a little bit of javascript to include in your website (I’ve removed our key from the picture). You’ll want this javascript on every page that you have on your website. If you’re using WordPress like we are, we were able to have this on every page by putting it in the default footer that’s part of our theme.  The code that’s in the Measurement JavaScript box in the Azure portal, I copies and put in our Theme’s footer between the <?php wp_footer(); ?> and the </body></html>. This put the code at the very bottom of the page, so even if there’s a delay in loading it, it won’t affect our website performance.

By using this basic reporting, we can see some pretty valuable information.

1. We can see where our website viewers are coming from
2. We can see what the performance for our viewers are

By showing us where in the world the folks reading our website, our coming from this gives us more insight into what kinds of things we should continue to write about. It also gives us insight into where we might need to deploy additional WebApps for better performance so that users in those areas get better performance.

By showing us the performance that users are getting around the world, we can see roughly what kind of performance improvement that users will see if we deploy another copy of our website to their region.  As we can see from the graph users from India, South East Asia, Australia, and Africa are getting 200ms or higher performance levels from browsing our website.  Based on this it might make sense to deploy another copy of the website into Singapore (which would improve performance in South East Asia, India, and Australia) and another copy of our website to the South African data center to improve performance for users in Africa.

Creating additional WebApps in these regions isn’t a give-in. 200ms isn’t a guarantee that there’s a problem. In our case we can talk to people in those various regions of the world and have them browse to the website and see if there’s a problem with viewing the website or not.  In this case, the data that’s available from Azure is just a piece of the puzzle to see if there is a performance problem or not.  This is because only the information that’s available for the portal isn’t everything.

Denny

The post Free Performance Metrics from Traffic Manager appeared first on SQL Server with Mr. Denny.