This video continues our comparison series of how the newest generation of Geocortex products are different (and better!) from their previous versions in Geocortex Essentials. In this video, we demonstrate the performance differences between Geocortex Workflow and the workflow capability in Geocortex Essentials.
On that note, in this week’s Geocortex Tech Tip, we will discuss some of the challenges faced with regard to performance in creating and running workflows in Geocortex Essentials, and how they have been addressed in Geocortex Workflow. With most workflows now running entirely on the client, there are no longer costly round-trips to the server and no need to use performance-enhancing tricks like reducing the scope of variables.
Video Transcript
“Hi, I’m Ken. I’m on the Products team here at Geocortex. Today, we are going to look at some of the performance improvements that have been made in the Geocortex Workflow product compared to how it used to be done in Essentials. Let’s get started!
Ok, so I am going to give you a quick look at Workflow here. I’ve got two different versions of it. I’ve got the Workflow in Essentials on your left, Geocortex Workflow on your right, and they are both doing the same thing really, just different technologies.
We’re going to be getting some sample data from a map service, and we are going to find the largest census track. So, we’re looking at a number of features, we are going to iterate through them and compare them, find the one with the largest area, and show an alert.
So, fairly straightforward example, just to show you something that can be impacted by the way these work in terms of performance.
Before I show you them, I just want to talk briefly about the difference between how they actually work.
With workflows in Geocortex Essentials, it’s all run on the server, and the browser is just really sending you a request to the server, getting back a response, and sending an extra request back and forth and back and forth for pretty much every step in the workflow. There are a few minor exceptions to this. When you are selecting things from the map that’s also done in the client, but everything else is happening in the server.
So, there’s a lot of that chatty traffic back and forward, sometimes this can get quite big because the state of the workflow has to be persisted, it has to remember what’s all been done. So, if you have things like variables or feature sets then that whole thing can be ended up going back and forward every time.
There are ways to mitigate this, but it’s not really obvious to the average workflow authors as they start to learn this stuff to begin with. For example, you can scope variables to only be used by certain sequences, you can also use client parallel to allow you to batch client task, reducing the overall number of round trips. But, these are kind of advanced tricks, we really wanted to make it easier to get performance right from the start.
So, that’s where Geocortex Workflow comes in. One of the main differences with it is that everything is run in the client, so you don’t really need to worry about the scope of your variables or things like that because we’re not sending that stuff to the server.
There are still a few things that can only be done in the server like database stuff and file access, things like that. Those kinds of things, you can create a server workflow and you can run it from your regular client workflow, so it is still possible to achieve that sort of thing, but only where it is absolutely necessary.
So, let’s just take a quick comparison between the two here. We can see that we’ve got a display form, this really just shows you a simple form explaining what the workflow is about to do. We’re going to find the Largest Census Track, and then after we show the form, we perform a query, and then we get the number of features and then we assign the largest feature to whichever the first one is. We have a ForEach that goes through them all, comparing them, and then we tell you which is the largest.
Over here, we’ve got a similar thing, we’ve got a form, we have a Query, we Create a Value for the largest, we’ve got For Each, and we’ve got an Alert. So, these are two equivalent workflows.
Here, we’ve got a viewer that’s going to run both of them in GVH. We have the Network tab open at the bottom here, so that we can see what’s going on behind the scenes.
First of all, we run the workflow in Essentials, you can that there’s our form telling us what it’s going to do. I click ‘OK’, it takes a moment. Then, we can see that there’s the result. So, there were over 1000 features from the query, which is the most you can get back from a query, there’s the name of the largest track and there’s it’s area. So, job done.
Notice that at this point, it’s going to request. Even after I click ‘OK’ for that alert at the end of the workflow, there’s still one final request, and it finally comes back and tells us that the workflow is completed.
So, the client is completely at the mercy of the server telling it what’s happening next and then it doesn’t stop sending it back until it tells it it’s finally done.
So, you can notice the second request here, the time that it took to respond was five and a half seconds, so that is quite slow. That’s where the query was happening and all the comparison of all of the features. Also, notice this, the request we sent after submitting the alert was actually quite a large request. If we look at the headers here, look at the size of the content, that’s 19728585, that’s huge. In fact, the browser doesn’t even want to show me the whole things, it’s truncated. So, that’s all the state of the workflow which includes the features, and all that stuff.
So, pretty slow there. Let’s now clear the console, and we’ll run it again from Geocortex Workflow and see the difference.
So, here we can see the appearance is slightly different. Over here on this side, we’ve had a request for an image here. That’s more a part of GVH than Workflow itself.
There we go. We’ve got the results already, that was way faster. We get the same response over 1000 features, the largest census tract is 9009, that’s the area, exactly the same. We click ‘OK’, and we are done.
You can see that the only network traffic here was that query. So, in the case of the first one, the query was done by the server, so it doesn’t show up in the browser’s traffic, but because the Geocortex Workflow runs in the browser itself, the browser initiated that query. Even though we were getting back 1000 features, that still was very quick, it only took 114 milliseconds there. That was much faster.
So, that was just a quick example of the difference between these two technologies. I hope that helps illustrate the point. Obviously, in a real workflow, things will be much more complicated and you would have many more steps, and actually the effect would be much more significant. This is was just really a simple example to give you the idea.
Thank you very much for your time. I hope this was useful. Bye!”
Not a Geocortex Workflow user and want to give it a try? See all it has to offer below!
Contributors