Benefits of Additional Web Server

Hello,

I've been deploying and maintaining SolarWinds for the past 9 years and have never had the need to use an Additional Web Server (AWS) in any of my environments.  Right now I'm doing an initial deployment for a new company that will have about 50 concurrent users, and I'm wondering if I should look into purchasing the AWS license and install it on its own dedicated server.

We're still in the deployment phase, with a low number of users actually using it right now, so I'm unsure how to measure the performance gain with a dedicated web server.  Our environment has 2.3k nodes, 60k elements, and 4 Additional Polling Engines (APEs).  For modules we have NPM, NCM, SAM, and NTA.

Does anyone here have any experience with AWSs have any insight into the performance gain you've seen by splitting the web server off from the Main Polling Engine (MPE)?

Things I'm most curious on:

- What's the list-price for an AWS?  I can't find it on the North American Price Sheet.

- Is it possible to stack the AWS with an APE similar to how you can stack APEs with the MPE?

- At what level of concurrent users would a business typically purchase an AWS?

- If the MPE goes down for maintenance does that cause errors in the AWS, or can I reboot the MPE and still deliver the site to users?  Does AWS rely on the MPE?

Thanks in advance on any insight you all might have!

-Drew

  • Hey, thanks for asking this question, this is one of my favourite topics, why should you use an additional webserver.

    - it is one of the most "value for the buck" license in the solawinds world.

    - I don't have an actual number but it mus be around 500€

    - you can more easily identify web performance issues that might arise due to an incorrect IIS Config/GPOs that mess with permission etc.etc.etc.

    - you can put that AWS in your DMZ and make your Orion Website available to the public (no more VPNing in when you receive an alert in the middle of the night)

    - you will be able to spread the load of your Web-Users

    - Your core Poller has the ressources for what is is needed -> polling information from devices and handling the core functions

    the downside is:

    - you need to maintain an additional Server

    I'd go for an AWS at any time!

    --- Edit ----

    I forgot to answer all your questions:

    - No stacking possible, I don't even like stacking APEs but that's just me.

    - the Architecture and Design guidelines suggest 20 concurrent web users per Web Server (depending on what ressources you have on your website it might be more or less)

    - AWS relies on MPE running... it will show a website but all Data Widgets will be empty

    --- edit again ---

    pastedImage_0.png

    as there is only one AWS license with no tiers -> 445€

  • Some great notes HerrDoktor !  We have been looking at deploying an AWS as well and I think I might use some of your notes as talking points!

  • Another reason to add to the list:  availability.

    With an additional poller, I can bring the main server down for maintenance - patches/windows updates - in the middle of the day and users will not notice.  There will be an outage in polling, but not of the user interface if both front ends are behind a load balancer.

  • Hi,

    You may also refer to this Thwack article for some great points regarding Additional Web Server provided by bogdan.stan@xpo.combourlism_roberts

    Orion Web Server Scaling

    Some key points -

    • Orion AWS is a 32 bit application
    • Each Web Server (as per recommendations) can handle about 20 concurrent users (but it purely depends on what is being presented to the user). You may be able to cater to even 50 concurrent users on a single web server
    • Keep the web load off the Main Polling Engine, as you have a fairly high number of elements - 60000 from 2300 nodes
    • For additional scaling, load balance the Additional Web Servers and keep a single URL for monitoring
    • Use SAM's AppInsight for IIS and apply it to the Web Server - "monitor the monitor"
  • Hi RaviK​, I remember having the discussion during the EMEA Partner Bootcamp in Cork. bogdan.stan@xpo.com​ provided some pretty deep insights, so the Kudos go to him on that topic.

    I guess all that info sums it up nicely and as always in IT: the answer is "It depends" emoticons_wink.png

  • I was wondering about that setup myself.  I have been contemplating trying to migrate every one of my projects to utilize load balancers and possibly even split them between my two data centers.  Giving me redundancy as well as continued visibility.  Thanks!

  • Just dropping by to say that in recent weeks our main AWS was crashing daily causing significant pain in the universe.

    The minute I configured idle time out on the app pool to 0 it all went away. Some other threads suggest other values. I can only attest to 0 being the magic bullet for us.

  • Hi,

    I quick question a few month later on this thread:

    > can the Additional Web Server be used for the API in order to free the main poller from the load of the API calls ? this mean redirect our APIs call to the AWS rather than to the main server ?

    The more we integrate SolarWinds with other tools the more we need to call the API.

    Cheers

  • To my knowledge, unfortunately not. The SWIS endpoint for API calls is as far as I know on the main polling engine.

    cheers!

  • Actually SWIS exists on all SW servers that have the information service running, so the AWE does in fact provide that option.  The part where things can get ugly is the SWIS schema is not 100% consistent between the various flavors of orion servers, so querying against an AWE will give you slightly different tables compared to what you might see on the core server (i learned this the hard way).  Also there are cases I have run into where the AWE has problems with the messaging and sometimes doesn't display the same data as what I see in the main console.  So yes you CAN offload queries to an AWE, but there are things to be cautious about in doing so.  Ultimately all of the queries in SWQL end up translated back to normal SQL and execute on the database server, regardless of where you call them, so that still represents the ultimate bottleneck in terms how much you crank out of the API.