SnowMirror vs ODBC driver

[Casey12]

My company is experiencing performance issues with the ServiceNow ODBC driver.  As I understand it, this driver is not a real driver -- it is merely a wrapper around the out-of-the-box (OOTB) ServiceNow SOAP API, which is the cause of its poor throughput.  It was recommended to me to look into SnowMirror to resolve our throughput problem.  As I understand it, SnowMirror also uses the OOTB ServiceNow SOAP API.  But, somehow, it has better performance than the ODBC driver (or so it's claimed).  Is this true?  If so, how can this be, given that they both use the OOTB ServiceNow SOAP API (and are, therefore, effectively the same thing)?

[alfredodeambros]

Hello, I’m with Perspectium, and I saw that this discussion asks about the performance of Perspectium. A major reason that enterprises use us to move massive quantities of data without crippling performance impacts is that our architecture does not use SOAP or APIs for extracting data from ServiceNow. Our ServiceNow native application minimizes performance impact during data extraction for multiple reasons.

1. Lower impact through push technology. A native application, because it’s already installed into the ServiceNow system, can notice when records change – and push payloads of changed records to a message bus. Push technology empowers the best possible throughput.

2. Lower impact through load-balancing. Performance stays strong with a native application because a ServiceNow admin uses a native application to load-balance the integration. ServiceNow is a multi-node cluster, but not all nodes are equally used in a cluster. Some may be actively used, while others are just standing by. Using push technology, a native application can make use of those non-active nodes, load-balancing to maximize performance. This arrangement removes the impact from those who use the ServiceNow platform on a daily basis.

3. Lower impact by throttling the rate of posting. A ServiceNow admin can decide when the native application will publish selected data. If data volumes are especially high, that admin can use a staggered approach to publish data via HTTP POST to databases or other instances, where teams can engage in otherwise performance-impacting jobs away from the production instance. For example, ServiceNow admins regularly receive requests for data. In addition to identifying fields, timing, and frequency for the integration, they are also in a position to identify which time slots are regularly available for the delivery of large batches of data.

As Ryan mentioned in a separate comment in this thread, Perspectium’s architecture is a "game changer." ServiceNow themselves use Perspectium for this very use case to move eye-popping volumes of records daily.

I hope this explanation helps clarify how Perspectium's architecture stays performant – and minimizes performance impact on ServiceNow. Let me know if you have any questions.