Version 1

    YOU CAN ACCESS THE PRESENTATION HERE: [VIDEO] SolarWinds Enterprise Scalability and Product Integrations


    CHAT LOG - 3/6/2014  1:00PM-1:55PM

    3/6/2014 13:00Johnseems like only yesterday that film was out
    3/6/2014 13:00Johnbut now i am carbon-dating myself
    3/6/2014 13:02francois.caronhello, guys, how many of you have at least one additional polling engine?
    3/6/2014 13:05francois.caronwhat? nobody? can't believe it...
    3/6/2014 13:06Garywe have an additional poller
    3/6/2014 13:06Johnhelps too
    3/6/2014 13:06ErrickWe use EOC with mulitple SW ORION servers but no addtional pollers.
    3/6/2014 13:07francois.caronGood, thanks. What would be the #1 improvement we could do in the area of scalability and deployability?
    3/6/2014 13:10GaryFailover is a big thing for us. We have the failover engine but its not deployed yet. We want to be able to failover one NPM instance to another datacenter. Additional Pollers can be setup in other datacenters to one central NPM instance.
    3/6/2014 13:10francois.carongot you.
    3/6/2014 13:11robhockHow many remote sites would you have to manage typically? Are you presently deploying APEs to those sites?
    3/6/2014 13:12Garyan APE would only be in another datacenter in our environment
    3/6/2014 13:14francois.caronand why that, gary?
    3/6/2014 13:17ErrickFailover is important to our misson. However, we have had limited success with deploying SW FOE across the WAN. Mainly due to SQL replication (Log shipping)crushing or bandwidth.
    3/6/2014 13:19francois.caronFollow-up to Rob's question: has anybody ever been in a situation where you have decided to NOT deploy an additional polling engine on a remote site, because of cost reasons?
    3/6/2014 13:19ErrickHi Ed, Thanks for the NCM info.
    3/6/2014 13:19francois.caronOK, Errick, got it on FoE
    3/6/2014 13:21ed.benderyou're welcome Errick.
    3/6/2014 13:21francois.caronAnybody using the API for automation?
    3/6/2014 13:32ccamlin111What do you mean by "practical" limit of 100K per instance of NPM? I may be working a project that will move above that limit. NPM+9 pollers.
    3/6/2014 13:33francois.caronit means that by default we recommend to limit to this, with default polling period and all the default settings. It is NOT an hardcoded limit. You can go above but you might have to do a bit of tunig and pay attention to the vital signs of your platform (this slide)
    3/6/2014 13:34francois.caronAlso, there is no hard limit to the numbner of pollers per platform. What counts is teh amount of work and teh elements 100K or more with good tuning'
    3/6/2014 13:35francois.caronmakes sense ccamlin11? Will some of your pollers be remote or all locals?
    3/6/2014 13:35robhockThe bottleneck is generally the SQL server. With a large SQL server, this can be pushed further
    3/6/2014 13:36francois.caronwill you have NTA too or just NPM?
    3/6/2014 13:37ccamlin111I was reviewing the Scalability Engine Guideline doc.  It stated NPM+9.  I understand the tuning needs for SW apps.  I often have customers that want to deploy a Corvette SW suite on a Yogo server configuration.
    3/6/2014 13:38ccamlin111No NTA thank God.
    3/6/2014 13:39francois.caron:-) why that comment?
    3/6/2014 13:40ccamlin111Like you stated, it is a performance and storage hog if not configured properly.  Although 4.0 has helped by separating the flow storage.
    3/6/2014 13:41francois.caronyep, 4.0 really helps. many report that their SQL DB is now much more responsive without 100's GB worth of flow data
    3/6/2014 13:51ccamlin111We need to get VMAN and NPM integrated for the Server folks.
    3/6/2014 13:54ccamlin111I have FSM and DBA setup for you and John to review.