Latest Contributions by AaronLopez

Benchmark ArcGIS Enterprise...The Original Approach A while ago, I discussed using the Natural Earth dataset with a preconfigured Apache JMeter test to benchmark an ArcGIS Enterprise deployment. Those results from that test could then compared to runs from other deployments to get a comparative idea of the underlying hardware's performance and scalability characteristics. This approach had some benefits: Natural Earth is a free GIS data Available for public use Low-to-moderate data complexity (easy to work with) Test Plan featured a step load for observing scalability capabilities While useful and a good measuring stick, the scalability component meant the test would typically run for a long time (which also added some complication). I had wondered if there was an easier way to just benchmark the processing hardware (e.g., the CPU) but still through ArcGIS Enterprise: Was it possible to use JMeter from a performance-only perspective? Could I create a test to benchmark ArcGIS Enterprise without an underlying FGDB or enterprise geodatabase dataset (which should simplify the overall effort)? It turns out the answers were yes! Benchmark ArcGIS Enterprise...An Alternative Approach Okay...I am speaking in half-truths. The new benchmark test does not depend on an FGDB or eGDB dataset based service, but does need some data. To help keep things simple, the data (e.g., pre-generated geometries) is simply passed through the JMeter sample elements to an ArcGIS resource that does not have a referenced dataset behind-the-scenes.  So, how is this done? Through the tried-and-true Geometry service. ArcGIS Server's geometry service is a built-in resource that provides access to many functions for performing geometric operations. The calculations of these operations (like buffer or generalize) can be simple or complex (depending on what you ask it). From a performance analyst's perspective, it provides a fantastic means for benchmarking the CPU hardware of the machine running ArcGIS Server. Note: Although the term ArcGIS Enterprise includes ArcGIS Server, this benchmark primary exercises the latter (e.g., ArcGIS Server). Some traffic may go through the ArcGIS Web Adaptor and there would be a small amount of Portal for ArcGIS authentication taking place, but by design, the bulk of the work will  be performed by ArcGIS Server. Benefits of Using the Geometry service The Geometry service has been around in ArcGIS Server since version 9.3, so its ubiquitous. That makes a test utilizing it easy and reliable. Since the data driving the test is put inside the key/value pairs of the requests, that adds portability (e.g., no dataset to lug around). Note: While the Geometry service has been included with ArcGIS Server for some time, by default it is off and not running. The service would need to be started and shared to the appropriate Portal for ArcGIS members before running the test. The Geometry_Functions_Benchmark Test Plan To download the Apache JMeter Test Plan used in this Article see: geometry_functions_benchmark1.zip  Downloading and opening the Test Plan in Apache JMeter should look similar to the following: Adjust the User Defined Variables to fit your environment What Types of Functions Should be Tested? For a benchmark, the short answer is only a few. This particular Test Plan only calls a few different operations...as well as the same operations in different ways (e.g., changing request parameters to purposely get a variant response). This provides mutability so the test is not just doing the same thing over and over. Below is a look at the operations used in this benchmark: generalize toGeoCoordinateString project buffer Expected Test and Operation Performance This test has some operations that may perform fast and others that will take more time. This speed will vary based on the hardware. Ultimately, we just want ArcGIS Enterprise (e.g., Server) to work for a just few minutes so we can get an idea of the processing performance. If each operation took 10 minutes (with the test many times longer) the benchmark itself can become too time-consuming and less practical to use. Deployment Architecture Example This benchmark test was run in a lab against two different severs (e.g., run once per server): ArcGIS Enterprise -- Machine #1 (older hardware) Intel Xeon E5-4650, 2.70 GHz SPECint_base2006  Score:  50.5 32 processing cores  HyperThreading disabled 64GB RAM 10Gbps network ArcGIS Enterprise -- Machine #2 (newer hardware) Intel Xeon Gold 6126, 2.60 GHz  SPECint_base2006  Score:  71.9 24 processing cores  HyperThreading disabled 128GB RAM 10Gbps network Note: Since this testing effort was more focused on speed instead of throughput, SPECint_base numbers were used instead of SPECint_rate_base. Benchmark Test Execution For long running tests, it is not recommended to run the Test Plan within the GUI. However, since this is a relatively short test, the impact is nominal. Note: When running any test, it is always recommended to coordinate the start time and expected duration with the appropriate personnel. This ensures minimal impact to users and other colleagues that may also need to use the ArcGIS Enterprise Site of interest (e.g., the production deployment). Additionally, this helps prevent system noise from other activity and use which may "pollute" the test results. Results After adjusting the User Defined Variables to point to the appropriate environment (Machine #1…devlab05), the benchmark was run right in JMeter GUI. The results can be observed from the View Results in Table element: For convenience, the Test Plan automatically calculates the overall test run duration, right in the name of the last operation This makes benchmark time easy to observe from the table The Test Plan was adjusted to point to a server on newer hardware (Machine #2…eistsrv05) and the benchmark was rerun From the table, the results are added after the first run: Expectedly, the first machine required more time to complete the same operations. This resulted in a measurable difference in performance between the two machines. Machine #1…devlab05 Benchmark duration: 259946 ms Machine #2…eistsrv05 Benchmark duration: 181441 ms Calculate Percentage Change Since the response times were lower (e.g., faster) with newer hardware (compared to the first run on older hardware), we'll calculate a percentage decrease: First, original server time - newer server time = the decrease Then, the decrease ÷ original server number × 100 = the % decrease (259946 ms - 181441 ms) / 259946 ms = 0.302 0.302 x 100 = 30.2%  The benchmark times from the older hardware (our start point) was 30% lower than the newer hardware. This percentage change suggests a measurable improvement when using the newer hardware. Percentage Change Estimate Based on SPEC Let's use the SPEC ratio with the benchmark time from the original run to predict the target_time (benchmark time on the newer machine). This can help with the understand if the roughly the same percentage change could be estimated. (Baseline_SPEC x Baseline_Time) = (Target_SPEC x Target_Time) ((Baseline_SPEC x Baseline_Time) / Target_SPEC) = Target_Time (36.875 x 259946 ms) / 53.75 = 178335 ms (after rounding down to nearest second) (259946 ms - 178335 ms) / 259946 ms = 0.314 0.314 x 100 = 31.4% From this prediction, the older hardware was estimated to be 31% lower than with the newer hardware. This is very close to the percentage change that was calculated based on the observed benchmark times.  Future Hardware Processor architectures and CPU speeds are always improving. Eventually, such a benchmark test (as it is currently built) may only take a minute or tens of seconds to run (what a great problem to have). At this point, complexity could be added to the test to increase its run duration to better match the new technology. You may have noticed the last transaction in the test was disabled. This 1000 Point Buffer request with a distance of 10000 meters and a unit of 9035 (International Meter Distance) takes some time to calculate (even on decent hardware). It was disabled to shorten the run time to a reasonable duration. However, if helpful, it can enabled as an additional calculation, depending on the CPU speed of the deployment of interest. Final Thoughts  As mentioned in other community articles, there is no one service or function that can cover the entire breadth and depth of ArcGIS. However, the Geometry service is a resource that represents a portion of the amazing field of GIS that is easy to work with. This makes it a good option to use for benchmark testing efforts. A Fast Response Time Is All About CPU Speed, Right? For this Geometry benchmark test, yes. However, for real-world services, processing speed is not the only factor. Server hardware components like disk speed, available memory, network speed are other resources which can improve response times (in addition to CPU speed). Together, they all have a positive affect on the user experience. This benchmark focused on CPU performance as it is a large part of the client request/server response process, but as just mentioned, it is not the only server resource when taking into account other potential ArcGIS services. What About Other CPU Comparison Tools? There are many utilities out there that can profile and test the various pieces of server hardware using a whole battery of exercises. These tests are great and certainly add value for understanding the hardware. Again, there is no one test that can represent all things GIS. But hopefully, this Geometry Benchmark Test Plan can be a useful tool in the analyst tool chest.  To download the Apache JMeter Test Plan used in this Article see: geometry_functions_benchmark1.zip        Attribution Resource: File:Wikimedia_Foundation_Servers-8055_43.jpg Description: Rack-mounted 11th-generation PowerEdge servers Author: Victorgrigas - Own work Created: 16 July 2012 Uploaded: 20 July 2012 License: CC BY-SA 3.0, Link    Resource: File:Cpu-processor.jpg Description: Author: Fx Mehdi - Own work Uploaded: 30 May 2019 License: Creative Commons Attribution-Share Alike 4.0 International ... View more

The Shared Service Instance Pool When people talk about load testing an ArcGIS Enterprise Site, such conversations typically involve the consumption of dedicated or hosted feature services. For many years, dedicated and hosted services have provided a fast, dependable mechanism for consuming high-traffic map resources online. This has not changed. However, there is another type of resource to provide maps to users: the Shared Service Instance Pool. Introduced in 10.7, the shared instances pool makes it easier to view and query services that are still valuable but where system memory usage is favored over performance. This feature allows for high service density publishing (e.g., being able to publish and have many running services) at the expense of some speed and throughput. It can be a good trade-off considering that for many organizations, there are generally more shared service candidates than dedicated or hosted. From this advantageous characteristic, shared services have been a true game changer. But, from a load testing perspective there are some considerations. Note: As a GIS administrator, assume all shared services have an equal weight of value with each other. Also, assume that dedicated services should take a higher priority than shared services.    Should Shared Services Be Load Tested? The $64,000 Question! As a performance analyst, this question may come up as your publishing services to the Site. While it can be very tempting to load test shared services to understand their scalability profile, there are several reasons why this strategy does *not* make sense: If scalability was paramount, the service should be moved to dedicated Shared services can still scale (e.g., support multiple, concurrent requests for the same item) but this is not its primary function The administrator has already designated the service to favor memory usage By configuring the service as shared, it is expected that the service will not be requested frequently If the service occasionally has slower or slightly slower response times, that is okay Testing such services steals hardware resources from the dedicated services Dedicated services are your "first class" services, do not have the shared services compete with them Dedicated and hosted services are the go-to mechanisms for scalability Shared services are not By testing or frequently sending requests shared services, (limited) system resources like CPU and Memory can be drawn away from the services that need it for delivering fast performance to users Test Plan Management Challenges It is not uncommon for Sites to have dozens or hundreds of shared services Assuming all shared services are equal, the test plan for effectively testing and profiling a hundred or more shared services could be daunting and difficult to manage A Site has a Mix of Shared and Dedicated Services, Can the Dedicated Ones Still Be Tested? Yes. Understanding the performance and scalability profile of dedicated services is still valuable information to have for deploying and managing the Site optimally. Test your dedicated services as you normally would. Can Shared services be tested if that is the only instance pool type published? There are no technical limitations that prevent shared services from being load tested. While it is certain possible to run such a test, it is not recommended for the reasons above. Analyze and Monitor the Site Periodically The popularity of services can increase or decrease over time. Periodically analyzing the traffic patterns of service requests can help provide administrators with information to configure and manage the Site optimally. This means that as some services are requested more frequently (or it is anticipated that they will be), they can be manually moved from being a shared service to a dedicated service. ... View more

System Log Parser's Statistics By User Reports: the Anonymous Value For evaluating Site performance and quantifying service popularity, System Log Parser (SLP) has several report offerings to conduct ArcGIS Enterprise log analysis. When selecting Analysis Types such as Simple, WithOverviewCharts or Complete, there is an option called "Add Statistics By User to Report" which will include an additional worksheet called Statistics By User into the generated output. The information on this worksheet includes a statistical summary of successful Portal member requests (as reported by ArcGIS Enterprise). This can be quite helpful for GIS administrators to understanding who is asking for what. Sometimes however, the listed User on this worksheet may show the unexpected value of "anonymous". For a Site with secured services, this might be a puzzling username to observe. Is an Anonymous User Sending Successful Queries to a Secured Service? The short answer: no, they are not. The long answer: no, they are still not, but some background is needed to provide the proper context on "anonymous" entries for the User Name value in the logs. Portal Member Log Entry Identity When System Log Parser queries the ArcGIS Enterprise (e.g., ArcGIS Server) logs, it reads the "User Name" field to determine the member identity for each log entry of a successful request. This value is only read from very specific log entries (e.g., where the log Code=100004). Such entries also have the final elapsed time duration of the work performed (e.g., how long the request took from the ArcGIS Server's ArcSOC.exe point of view). These resources are some of best places to look for quantification analysis of the Site. For many service request log entries, this lists the authenticated Portal member username value...as expected. But, there are log entry cases when a member has just authenticated to the Site and the recorded value of "anonymous" is listed instead, but anonymous (e.g., a non-authenticated user) was not actually reading the service. If log queries are executed manually (for the same window of time) through Manager or the REST Admin API, additional details are revealed which can help explain this initial user impersonation by the entity  called "anonymous". By using the Request ID field in the logs, one can correlate multiple entries together (since all of the same Request IDs belong to the same request...which is really awesome). So, while the Code=100004 entry shows the user as "anonymous", the Code=9029 entry actually lists the requesting user's Portal member identity. In this case, "admin". Subsequent queries by that user are listed as the expected name (e.g., and not "anonymous"). Note: In the log entry screenshot above, "NaturalEarth/NaturalEarth_SQLServer.MapServer" was a service shared only to specific Portal members. Note: System Log Parser does not currently present this additional user impersonation detail. Whatever value is recorded under User Name is what SLP uses for the Statistics By User worksheet. Note: There can also be a separate Code=8522 log entry which lists the recorded member value under the User Name column. Actual Anonymous Requests to Services Shared to the Public There are also log entries where the value for the "User Name" field can list "anonymous" as the member, but this where it is truly representing anonymous. In this situation, the logs are identifying a successful request made by someone for a publicly available service where the connecting client was not challenged to authenticate. In other words, the service was intentionally shared to Everyone (e.g., the public). By performing another manual, in-depth log query (for the same window of time) for these types of requests, more details can be derived which show that associated Code=9029 entry. This helps highlight that the request was actually made on behalf of the "Anonymous user". Note: In the log entry screenshot above, "SampleWorldCities.MapServer" was a service shared to Everyone. Note: System Log Parser does not currently present this additional user impersonation detail. Whatever value is recorded under User Name is what SLP uses for the Statistics By User worksheet. Are There Anonymous User Log Entries for Secured Services? No. Requests issued for any non-publicly shared resource will be prompted to authenticate (even if what is requested does not exist). Therefore, Code=100004 entries will not exist for the "Anonymous user" user against secured services. Note: In the log entry screenshot above, "NaturalEarth/NaturalEarth_SQLServer.MapServer" was a service shared only to specific Portal members. Note: ArcGIS Enterprise will still acknowledge an "Anonymous user" request for a secured service (existing or not) with a Code=9029 entry (and potentially a Code=8522 entry as well). What Release is this User Name Log Entry Information Based On? This article is based on ArcGIS Enterprise 11.2/11.3, but the User Name information has been available in the ArcGIS Server logs for many releases. Variability The purpose of this Community Article is to offer guidance and help explain several of the situations where "anonymous" is listed as the User Name in the ArcGIS Enterprise (e.g., ArcGIS Server) logs. Expect some variability of this behavior (over the years and) across the releases. Additionally, since there are many ArcGIS Server service capabilities, each may handle the persistence of the User Name value slightly differently within the framework's internal logging logic.   ... View more

Branch Versioning Branch versioning is a type of versioning for an enterprise geodatabase that aligns with the ArcGIS Enterprise Web GIS model. It uses a service-oriented design to support multiuser editing workflows and long transaction scenarios through web feature layers.  When datasets are registered as branch versioned in the geodatabase, there is an option to enable the Version Management capability as the resource is being shared/published. This creates a version management endpoint that can perform the creation of new named versions as well as the administration of existing ones. Web users can query and edit data of their own named version through the web feature layer or reconcile and post the changes into the default parent version for other members to utilize. In short, branch versioning is built for the modern web and uses a simplified data model that is optimized for today's clients like ArcGIS Pro. For more information see:  Versioning types -- branch versioning Version management Version administrator   Why Test Branch Versioning? Since branch versioning is the data model for multi-user editing over the web with ArcGIS Enterprise and is a major components for frameworks such as utility network and parcel fabric, the understanding of its performance profile can greatly benefit GIS administrators. Branch Versioning Editing Testing Challenges While the exercising of branch versioning queries from JMeter is not too difficult, things become more complex when editing is involved: For example: When a new named version is created, it needs be referenced in the test by the associated GUID in some places and by the name in others Any time a "write" operation like takes place against the data like creating a new named version, applying edits, reconciling or posting, a new historicalMoment is generated Any web feature layer queries that take place after a write operation will want to use the updated historicalMoment to retrieve the most up-to-date information from the version management system Prior to adding new data, the test needs to ask the system to reserve objectIDs and use the returned numeric value as the starting point In addition to objectIDs, items being inserted or updated also have globalIDs to keep track of To properly perform write operations, an editing lock needs to be acquired that utilizes a unique sessionID With editing through a load test, it is easy to see the additional moving parts that the Test Plan needs to keep track of. Of course, when this happens in ArcGIS Pro, this complexity is handled automatically for the user. Note: The historic moment is one of the strengths of branch versioning as it allows a user a mechanism for viewing data for a particular date and time. Lock acquisition is another key feature of branch versioning which allows the system to have multiple readers for each named version or just one exclusive editor. How to Test Branch Versioning Editing? The branch versioning editing workflow was conducted in ArcGIS Pro 3.2 Final (and ArcGIS Enterprise 11.2). While the operations were executed in ArcGIS Pro, the HTTP traffic (between ArcGIS Pro and ArcGIS Enterprise) was captured and later converted from a HAR file to a JMX file (JMeter Test Plan). At a high level, the workflow operations in this Article contained the following steps which represent a user's (branch versioning) editing session in ArcGIS Pro: Portal Member Authentication Open the Project Create a new named version Switch to the named version Zoom in to an area of interest Insert a new point Update attributes of the new point Insert a new polygon Update attributes of the new point Save Edits Reconcile with Default Post the changes back to Default Zoom out (back to the initial map scale) The general steps in this Article should work with any service data that is registered as branch versioned. Though the test workflow makes specific use of a point layer and a polygon layer that existed in the utilized dataset. The dataset tested was the free and publicly available Natural Earth. View of the Natural Earth service from ArcGIS Pro: Southern California, USA The Natural Earth Dataset The Natural Earth datasets provides some decent map detail (at smaller scales) covering the whole world. Download the Natural Each dataset here  The download above is a subset of the larger Natural_Earth_quick_start.zip and includes a modified MXD for ArcMap 10.8.1 and ArcGIS Pro 2.8 project Either can be used to publish and create a cached map service to ArcGIS Enterprise The ArcGIS Pro Feature Cache ArcGIS Pro uses a feature cache to improve the display performance when navigating to areas of interest that have already been visited on the map. If any editing takes place this cache is refreshed. Feature caching is an all-around good performance strategy. However, when capturing the HTTP traffic for this workflow, the feature cache was turned off. The Editing Workflow via ArcGIS Pro This section lists the editing workflow steps from an ArcGIS Pro visualization point of view. Open the Project The resources of the project are based on the web feature layers from the published service Create a new, public named version and switch to it When manually conducting the editing workflow, the value of "edits_20231211_2" was used but within the JMeter test, this value will be dynamic generated and unique to better allow for more automated execution After opening the project, ArcGIS Pro will issue multiple queries to the various layers listed in the table. When a new version is created and ArcGIS Pro switches to it, similar looking layers queries will be sent again but these are actually for the new version. Note: Although the editing workflow starts with "Portal Member Authentication", the logic for this operation was manually adjusted in the Test Plan to remove some additional requests and reduce complexity Zoom in to an area of interest (where the inserts will take place) In this example, the area of interest is Southwest of Palm Springs, California, USA Insert a new point From ArcGIS Pro, select the Edit tab from the top menu; click on Create (under the Features section); then from the list of Create Features Templates select "ne_10m_populated_places" Then, click on an area in the map to insert the point Note: After clicking in the map, the point was actually inserted into the geodatabase. However, since the Save operation has not been executed, the "Branch Moment" for the named version has not yet been updated. Once save has taken place, the edits become "official". The next step involved changing attributes of the newly inserted point as it was an opportunity to later show a feature update within the JMeter Test Plan. Alternatively, you could have just used the Feature Template to pre-populate the attribute fields and then perform the insert. Update attributes of the new point With the newly added point still selected, click Attributes (under Selection), then populate several of the fields. Attributes to update SCALERANK, NATSCALE and LABELRANK rank was given arbitrary numeric values The NAME field was specifically set to "Otisburg" To commit the changes, click Apply Insert a new polygon From ArcGIS Pro, select the Edit tab from the top menu; click on Create (under the Features section); then from the list of Create Features Templates select "ne_10m_urban_areas" Then click on an area of the map and draw a polygon around the "Otisburg point" Update attributes of the new polygon With the newly added polygon still selected, click Attributes (under Selection), then populate several of the fields. scalerank was given an arbitrary numeric value The featurecla field was specifically set to "It's a little bitty place" Note: When adding the point and polygon, several feature queries were being issued as the cursor moved around the map. These queries are the result of the Snapping engine. With snapping enabled (the default option) the additional requests are expected behavior. The captured workflow used in this Article left this option enabled. The functionality can be turned off from the Snapping management if the additional requests are not desired in the captured traffic. Save Edits With the branch versioning edits complete, the changes were internally finalized by the system once Save was clicked Reconcile with Default Reconciling with default is the process of resolving conflicts that result from merging parent version data (e.g., from default) into the edit session  The captured workflow used the Reconcile defaults (as captured by ArcGIS Pro): Detect conflicts by attribute (instead of object) Abort if conflicts were detected was false Issue a Post (after the reconcile) automatically was false Run the job asynchronously was false Since this editing workflow is relatively simple, there should be no existing attributes that conflict the edits that were performed Post the changes back to Default Post is the process of merging the edit session data into the default version The inserts will now become part of default and any new named versions that are created after The captured workflow used the Post defaults (as captured by ArcGIS Pro): Run the job asynchronously was false Note: If the captured traffic is executed in the Test Plan multiple times (e.g., a load test), the "same" items will appear multiple times in default (as expected). From a visual perspective, it might be difficult to "see" these new objects spatially in the default version as they would all be using the same geometry. However, the labeling of the point and polygon layers might give hints that multiple occurrences exist for items using the same geometry. Note: A few words about an asynchronous reconcile or post; with ArcGIS Pro 3.2, the default execution from the ribbon menu is to utilize synchronous execution. If asynchronous for an operation is used instead, it follows a different HTTP request pattern (since it become a submitted job whose status must be periodically polled). Additionally, the action utilizes a separate ArcGIS Server service (e.g., the System GP services like: SyncTools, UtilityNetworkTools, or VersionManagementTools) to carry out the appropriate asynchronous task. Zoom out (back to the initial map scale) Finally, the session ends by navigating back to the original map scale of 1:1,000,000 to help provide a visual point of reference of the edits that were performed The Branch Versioning Editing JMeter Test Plan To download the Apache JMeter Test Plan used in this Article see: branch_versioning_editing1.zip  Opening the Test Plan in Apache JMeter should look similar to the following: The tests steps closely follow the workflow performed in ArcGIS Pro: Portal Member Authentication Open the Project Create a new named version Switch to the named version Zoom in to an area of interest Insert a new point Update attributes of the new point Insert a new polygon Update attributes of the new point Save Edits Reconcile with Default Post the changes back to Default Zoom out (back to the initial map scale) Components of the Test Plan In order to help keep this branching versioning editing Test Plan as simple as possible, only a few options exist under User Defined Variables that need to be configured. A single HTTP Header Manager element is utilized and just one Response Assertion exists to throw messages if the word "error" occurs in any response. CSV Data Set Config The test does make use of a CSV Data Set Config elements in JMeter to order to authenticated and utilize a different Portal member when executed under load. This item is location inside the Thread Group. Note: As administrators, testers and analysists, the JMeter Test Plan could be as complex as needed to fit your needs. It is not uncommon to having an editing test have the actual changes (e.g., geometries inserts or attributes updates) use a CSV file to make the effort more dynamic and realistic. However, one of the goals of this Article is help show how the editing can be done by keeping the complexity of the test down to a minimum. (User Test Thread) Initialization Transaction Once the user or more accurately, the test thread, starts but before authentication takes place, we want JMeter to generate values for a few items and assign them to variables: sessionID Used for acquiring locks and for write operations Unique for each user's ArcGIS Pro session gdbVersion geodatabase Version name identifier Used to help create the named version's "official name" Once created, ArcGIS Enterprise will also generate a GUID associated to the new named version A unique name for each named version A GUID for our point to be added Unique for every added point Unique for each users ArcGIS Pro session A GUID for our polygon to be added Unique for every added polygon  Unique for each users ArcGIS Pro session These are defined through a User Parameters element. Open ArcGIS Pro Project Transaction When expanded, the Open ArcGIS Pro Project transaction will list the requests issued when the aprx file was launched. There are typically many requests for such an operation as ArcGIS Pro gathers meta-data on the service and layers. In the middle of this operation are a few requests calling a special GUID resource. These are calls to the default version in the geodatabase. Typically, "BD3F4817-9A00-41AC-B0CC-58F78DBAE0A1" is the GUID associated with Default. There is also startReading request to obtain a read lock that utilizes the sessionID generated earlier in the test. Create Version and Switch Version Transaction The Create Version operation does a lot of important work in the Test Plan. It ensures that the edits will have a place to go (the named version) until they are intentionally merged with Default. Upon creating the new version, the versionGUID, versionName and branch versioning moment are returned which need to be captured and stored into additional test variables since they will all be used in subsequent requests. The versionName is the official vanity designation of the named version. While the test generated a value for "gdbVersion", the system adds some addition information to its final form. For example: gdbVersion value (generated by JMeter): version_O5AHEMD89CYTH7GW versionName value (returned by ArcGIS Enterprise): USER007.version_O5AHEMD89CYTH7GW Note: Create (version) is available through the service's VersionManagementServer capability. Remember, when creating the new named version, ArcGIS Pro was instructed to switch to it. Immediately following create, there were requests issued against the new version using its GUID and well as several queries. These queries had specific key/value parameters that depended on the new branch versioning moment and name of the new version that was returned (from the response of create). Add Point Spatially Transaction Like the create operation, Add Point Spatially contains several critical pieces. This particular action is the first to "start" the edit session for the long transaction by sending a startEditing request which acquires a write lock against the named version. Since an insert is taking place, an objectID for the point is also required. The reserveObjectIDs call asks the system to return an objectID starting point for that particular layer. The test requested 100 IDs and the system responded with a firstObjectID to start with (which is captured to a JMeter variable) followed by an another number. The second number is the continuous, reserved range of IDs (the firstObjectID is the first item in this range). Note: While the GlobalID GUIDs can be generated by the Test Plan, ObjectIDs cannot. ObjectIDs must be allocated by the web feature layer.   Note: A reserveObjectIDs request asking for 100 allocated ObjectIDs does not guarantee that 100 continuously IDs were reserved. The system will respond with the range available from that initial request. Additional reserveObjectIDs calls might be needed to obtain the necessary amount of IDs if the tested workflow is planning to perform multiple inserts that exceed the allocation. For such a situation, the test plan would need to handle the objectID logic itself. ArcGIS Pro does this automatically for the editing user. With the ObjectID for the point reserved and captured, the insert can now take place. Web feature layer editing (adds, deletes, and updates) happen through the applyEdits function. This request requires the named version name and sessionID as well as the edit payload. This payload lists of the edits to be performed specifying the layer ID, operation (e.g., adds), attributes and geometry. The pointGlobalID (GUID) generated at the start of the test is also used. The value for the edits key:     [{"id":1,"adds":[{"attributes":{"OBJECTID":${pointObjectID},"SCALERANK":null,"NATSCALE":null,"LABELRANK":null,"FEATURECLA":null,"NAME":null,"NAMEPAR":null,"NAMEALT":null,"DIFFASCII":null,"NAMEASCII":null,"ADM0CAP":null,"CAPIN":null,"WORLDCITY":null,"MEGACITY":null,"SOV0NAME":null,"SOV_A3":null,"ADM0NAME":null,"ADM0_A3":null,"ADM1NAME":null,"ISO_A2":null,"NOTE":null,"LATITUDE":null,"LONGITUDE":null,"CHANGED":null,"NAMEDIFF":null,"DIFFNOTE":null,"POP_MAX":null,"POP_MIN":null,"POP_OTHER":null,"RANK_MAX":null,"RANK_MIN":null,"GEONAMEID":null,"MEGANAME":null,"LS_NAME":null,"LS_MATCH":null,"CHECKME":null,"MAX_POP10":null,"MAX_POP20":null,"MAX_POP50":null,"MAX_POP300":null,"MAX_POP310":null,"MAX_NATSCA":null,"MIN_AREAKM":null,"MAX_AREAKM":null,"MIN_AREAMI":null,"MAX_AREAMI":null,"MIN_PERKM":null,"MAX_PERKM":null,"MIN_PERMI":null,"MAX_PERMI":null,"MIN_BBXMIN":null,"MAX_BBXMIN":null,"MIN_BBXMAX":null,"MAX_BBXMAX":null,"MIN_BBYMIN":null,"MAX_BBYMIN":null,"MIN_BBYMAX":null,"MAX_BBYMAX":null,"MEAN_BBXC":null,"MEAN_BBYC":null,"COMPARE":null,"GN_ASCII":null,"FEATURE_CL":null,"FEATURE_CO":null,"ADMIN1_COD":null,"GN_POP":null,"ELEVATION":null,"GTOPO30":null,"TIMEZONE":null,"GEONAMESNO":null,"UN_FID":null,"UN_ADM0":null,"UN_LAT":null,"UN_LONG":null,"POP1950":null,"POP1955":null,"POP1960":null,"POP1965":null,"POP1970":null,"POP1975":null,"POP1980":null,"POP1985":null,"POP1990":null,"POP1995":null,"POP2000":null,"POP2005":null,"POP2010":null,"POP2015":null,"POP2020":null,"POP2025":null,"POP2050":null,"CITYALT":null,"min_zoom":null,"wikidataid":null,"wof_id":null,"CAPALT":null,"name_en":null,"name_de":null,"name_es":null,"name_fr":null,"name_pt":null,"name_ru":null,"name_zh":null,"label":null,"name_ar":null,"name_bn":null,"name_el":null,"name_hi":null,"name_hu":null,"name_id":null,"name_it":null,"name_ja":null,"name_ko":null,"name_nl":null,"name_pl":null,"name_sv":null,"name_tr":null,"name_vi":null,"wdid_score":null,"ne_id":null,"GlobalID":"${pointGlobalID}","created_user":"${username}","created_date":1702339858000,"last_edited_user":"${username}","last_edited_date":1702339858000},"geometry":{"x":-12994151.880899999,"y":3983674.1925999969,"spatialReference":{"wkid":102100,"latestWkid":3857,"xyTolerance":0.001,"zTolerance":0.001,"mTolerance":0.001,"falseX":-20037700,"falseY":-30241100,"xyUnits":10000,"falseZ":0,"zUnits":1,"falseM":0,"mUnits":1}}}]}]     As mentioned earlier, if the insert utilized the feature template, the attributes would have actual values for the initial edit instead of "null".  The point insert operation in this test plan is "simple" in that it uses a fixed geometry of  "x":-12994151.880899999,"y":3983674.1925999969. The test plan could be made to utilize a CSV file with different values to make this part more dynamic. If the applyEdits is successful, a new edit moment is returned to be used on subsequent feature queries. Note: The value of the new historicMoment key in the query requests before applyEdits is called is typically different than the value after. The value of the property (e.g., historicMoment) is updated through the Regular Expression Extractor element. After an edit operation, there are often a few feature queries which use the edit moment, version name and ObjectID that was just inserted.  Update Point Attributes Transaction Since the editing session has already been started and the objectID(s) already reserved, the Update Point Attribute does not have as many moving parts as Add Point Spatially. It contains a handful of queries and one applyEdits request (to perform the update). The update performed by the applyEdits is relatively simple as its just changing a few attributes. However, more columns could be changed in addition to the geometry. The value for the edits key:     [{"id":1,"updates":[{"attributes":{"OBJECTID":${pointObjectID},"SCALERANK":550,"NATSCALE":425,"LABELRANK":231,"NAME":"Otisburg","GlobalID":"${pointGlobalID}"}}]}]     Polygon Transactions The same editing process (e.g., insert followed by an update) is repeated for the polygon layer. While the Add Polygon Spatially contains a new reserveObjectIDs request (since the insert is taking place against a different layer) there is not an additional startEditing request against the named version GUID because the long transaction is still active.  The value for the edits key:      [{"id":7,"adds":[{"attributes":{"OBJECTID":${polygonObjectID},"scalerank":null,"featurecla":null,"area_sqkm":null,"min_zoom":null,"GlobalID":"${polygonGlobalID}","created_user":"${username}","created_date":1702340363000,"last_edited_user":"${username}","last_edited_date":1702340363000,"Shape__Area":293911790.76777756,"Shape__Length":85235.280315167271},"geometry":{"rings":[[[-12973934.7456,3982326.3835999966],[-12974309.137,3979331.2524999976],[-12977753.537900001,3978732.2261999995],[-12982021.5997,3977908.565200001],[-12984193.069800001,3974913.4340000004],[-12991456.2629,3974464.1643000022],[-12996697.7424,3976336.121299997],[-13002688.004700001,3978956.8611000031],[-13003736.3006,3984872.245099999],[-13005758.0142,3991910.8033000007],[-13004485.0834,3994381.7864999995],[-13002762.883000001,3990413.2377000004],[-12996922.3772,3986893.9585999995],[-12986589.174800001,3987193.4717999995],[-12983369.4088,3985995.4192999974],[-12981197.9387,3984348.0971999988],[-12973934.7456,3982326.3835999966]]],"spatialReference":{"wkid":102100,"latestWkid":3857,"xyTolerance":0.001,"zTolerance":0.001,"mTolerance":0.001,"falseX":-20037700,"falseY":-30241100,"xyUnits":10000,"falseZ":0,"zUnits":1,"falseM":0,"mUnits":1}}}]}]     The polygon layer update is similar to the point update in that it modifies several column attributes of the data. Save Edits (to the Named Version) Transaction At this point in the Test Plan, the edits are done and the long transaction can be completed. This happens by a stopEditing request being issued against the named version. When the commit is successful, the branch moment value is updated and the edits performed will persist in the named version. Reconcile With Default Transaction If the changes made against the named version need to be visible in Default, the reconcile operation must  take place first. As mentioned earlier, reconcile helps resolve data conflicts, that might exist between the two versions. Since a write could be taking place during this process, a startEditing request is issued to the named version GUID resource just prior to the reconcile.  From an HTTP request point of view, reconcile is called against the GUID of the named version (which was created from this iteration of the test). The key/value pair request parameters are fairly straight-forward with the only dynamic pieces being the sessionID (and of course the token). A stopEditing request is issued (also against the named version GUID) once reconcile has finished. Once the reconcile has completed successfully, a new branch moment is returned and captured. Note: This test focuses on "write operations" returning an updated edit moment. While this is true, the edit moment change can also be reflected through the responses from VersionManagementServer/versions/[GUID]  requests. Many times, this value is identical to the moment returned by the write operation. Sometimes it is different but still very close. For simplicity, this test plan did not reflect this potentially different moment change with an additional regular expression extractor element (for these VersionManagementServer/versions/[GUID] requests). Post To Default Transaction Post is the last step to bring the edits in the named version to the default version. Like reconcile, the captured editing session used the defaults options. As a result, the key/value pair request parameters are straight-forward with the only dynamic pieces being the sessionID and the token. There are a few more reading and editing calls than the reconcile operation to the named version and default version, but the operation is also straight-forward. Managing the Named Versions Named versions can build up over time, but if the post operation is the last action in the user's edit session, the named version could be deleted. Note: For simplicity, deleting the named version after the post transaction completed was not added to the test. Zoom Out (to Scale 1 Million) Transaction The edit session concludes with a navigation zoom out to the map scale 1:1,000,000. This was done in ArcGIS Pro to make it easier to see the edits with respect to the rest of the data. The result of this simple operation is a handful of feature layer queries. However, it is important to understand that these queries (based on the values for historicMoment and gdbVersion) are still against the named version and not the default version. Note: Queries against default would (always) use the gdbVersion value of "sde.DEFAULT". However, since Default has been updated in this test plan as a result of the post operation, new queries would need to utilize an updated historicMoment in order to pull down the latest data. The most recent value for default's historicMoment can be found in the response of a VersionManagementServer request (e.g., VersionManagementServer/versions/BD3F4817-9A00-41AC-B0CC-58F78DBAE0A1). Such a request exists in the post transaction, but for simplicity, this was not captured with a regular expression. Final Thoughts  The Apache JMeter Test Plan in this Article represents a basic programmatic approach for handling some of the key components of a branch versioning editing workflow. While the steps of the workflow were straight-forward, the end result was a Test Plan that still contained contains several moving parts. To help with this, the edits themselves were static and hard-coded into the test. This was done to keep things as simple as possible so the Article could focus on critical points and strategies.  However, there is nothing to stop you from recording and creating more complex edits in a new test or to make the edits of your effort dynamic where the values are derived from a CSV file. As a tester and GIS analyst, the sky's always the limit when building a JMeter Test Plan to consume or edit data from ArcGIS Enterprise. To download the Apache JMeter Test Plan used in this Article see: branch_versioning_editing1.zip  Running the Load Test Note: Please coordinate with your GIS team if your Apache JMeter test will be sending requests to a server that might impact other users. A load test should be scheduled to run during non-peak business hours. Note: Before running an editing test against an enterprise geodatabase, ensure that proper backups exist, are accessible, and can be utilized, if needed. While named versions can be easily deleted via the version management system, edits and changes posted to default are more difficult to undo. Typically, restoring the data from a backup to get the system to a clean state is often the last step after the edit testing effort has completed anyways. Historic Moment Testing Details The branch moment is a critical component of branch versioning as it allows the feature layer queries to pull data from a specific moment in time from the geodatabase. However, from an HTTP testing perspective, the response from various functions list this value under different string names. Some resources list it under creationdate or modifiedDate, whiles others use editmoment or just moment. As a tester, that is something to look out for when constructing the regular expression to capture the appropriate value. In the case of create (version), creationdate and modifiedDate are returned  though they often contain the same value. For more information see: Historical moments  Operation Concurrency As a tester and analyst, one of your jobs is to observe how your services perform and scale. This curiosity includes an understanding of the branch versioning operations like: query, create version, applyEdits, save, reconcile, and post. Of course, the write operations (back to the enterprise geodatabase) can be more resource intensive. While functions like query and applyEdits can certainly support many concurrent calls across different named versions, you may find calls like post do not behave in that same manner...especially if they are long running (e.g., the named version contained a large number of changes). While every dataset is different and each editing workflow may have a unique performance characteristic, this is something to keep in mind if the load test utilizes a high number of concurrent test threads with the post operation bringing a large amount of changes back to default. Real-world workflows may not always post the changes from multiple named versions back to default all-at-once. Instead, it is not uncommon that a data steward performs this particular job serially and manually to help ensure the changed data meets the needs of the organization.      Attribution File:c8db9197-fc08-4673-8bd1-6b622c7d4f6e_text.gif, Otisburg -- Superman (1978)    Apache JMeter released under the Apache License 2.0. Apache, Apache JMeter, JMeter, the Apache feather, and the Apache JMeter logo are trademarks of the Apache Software Foundation. ... View more