Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Which are faster API or direct SQL calls? Our API and SWQL are exponentially slower.

Been trying to diagnose an Information Service and RabbitMQ problem - and Solarwinds support has like that old episode of the Three Stooges when they try to become plumbers. Anyone have any suggestions for how to diagnose this because Solarwinds seems to have no clue.

Find more posts tagged with

Comments

KMSigma.SWI

Any direct call to a database will be faster than working with any API. But that's not the "why" people use APIs.

I'm confused by your title vs. your content. Are you having a problem with SWIS and the RabbitMQ or do you have an inquiry about the API calls? How can we help best?

hythlodaeus

Thank you. Our Account Rep and at least one other (maybe an L1) said that SWQL SWIS would be faster. (I mean he said SWQL but I'm figure SWIS would be / are the same). So this just kinda shows how off-base our Solarwinds support has been for months.

hythlodaeus

Basically I was always certain you were right, but began to feel very gasslit and crazy talking with Solarwinds support and reps.

hythlodaeus

Also, if a query takes 0.3 seconds in SQL Studio, should it take a almost 30 minutes in SWQL Studio?

KMSigma.SWI

Without knowing the exact words and the context, I wouldn't say they are "wrong." What I will say is that working directly in SQL is dangerous and prone to problems as there are no checks (for permissions, for relationships, for updates, and more). The most notable reason is it insulates you from database schema changes - which happen very frequently between versions.

I, for one, never do anything in SQL unless there is a very good reason - and as you can probably reason, I'm someone who has gotten very comfortable with the schema and the changes over the years.

KMSigma.SWI

Probably not - what's the query?

hythlodaeus

Well, that was a basic question I haven't been able to get answered (and haven't investigated much myself) - I ran what I believed to be analogous pull of the entire Interfaces table via SWQL and SQL - but the arrangement is different in SWQL and potentially SQL. Basically fields are not identical and tables are translated (could be views vs tables or queries stored - not sure how SWSQL works or how our SQL server is currently configured)

What would be a good test?

So...

SQL was:

SELECT * FROM [SolarWindsOrion].[dbo].[Interfaces]

SWSQL was (wildcard wouldn't work):

SELECT InterfaceIndex, InterfaceDescription, InterfaceName, InterfaceAlias, InterfaceType, InterfaceTypeName, InterfaceTypeDescription, InterfaceSpeed, MACAddress, AdminStatus, OperStatus, InterfaceMTU, LastChange, PhysicalInterface, Promiscuous, InterfaceID, NodeID, LastDiscovery, FirstDiscovery, Missing, VLANID, PortStatus, VlanType, InterfaceHighSpeed FROM NCM.Interfaces

hythlodaeus

Also regarding that - we were getting absolutely excellent support from Will Mulhe on this. He saw extensive problems in our logs etc pointing to various problems with data throughput - seeming to suggest two main avenues to investigate DB connectivity or data itself (or both) - this could also mean problems with our infrastructure but we tried the least invasive best options first so we reconfigured our MS SQL server and saw improvement but still many crashes like we had back when Will seemed to see a lot of SWIS and Rabbit MQ problems - as well as Database Diagnostics failing on tables (I believe he mentioned specifically the Interfaces table). But Will is no "support" so we have lost all access to him and no one else in SW Support seems to have any idea how to pick up where Will left off. Will was excellent.

hythlodaeus

Man, typos - I mean Will is NOT Support but an Application Developer. I guess I just assumed there would be some support engineers who could follow what I thought was Will's excellent reasoning and diagnostic skills.

Early on it seemed that Will was suggesting we use SWQL *IF* we did any back-end work. He suggested problems with our data (bloated ActiveAlerts table, Interfaces, possibly nodes etc) so I began to pull this data from SWQL in anticipation of building some safe and SW Best Practice tools to cleanup our DB *AND* make tools or procedures for our NOC to properly maintain SW data going forward (we are the Systems Engineers - Sys Admins so not keepers of Solarwinds data). But when Will saw how slowly SWQL was running, he told me to stop using it (no explanation) and he used MS SQL Server Management Studio direct queries - and it seems we may have no other recourse unless we can get our SWQL problems resolved (which will probably affect any API development our Development team's new hire does).

Quick Links

Cisco ASR Devices
Cisco ASR Devices.pollerCisco ASR Devices
Basic SWQL Syntax
SWQL is built on the framework of SQL and as such supports most of the standard clauses as part of a query. A very simple example query is: SELECT Caption, IPAddress, Vendor, ResponseTime FROM Orion.Nodes Dissecting this query is relatively straightforward: show some fields (Caption, IP address, Vendor, and Response Time)…
Cisco ASA SSL Tunnels
Active SSL Tunnels-ASA.UnDPThis poller *should* display the number of Active SSL VPN (Anyconnect) Tunnels currently connected to your box. However, I tried it with my 5520 running 8.0.4 and for some reason I get a OID Not Supported. Here's my post in the forum: *EDIT* This is confirmed working with at least Interm release…
HP ProCurve Switches Hardening check
HP ProCurve Switches Hardening check.xmlGeneral hardening for HP switches