1 / 68

Siebel 7 Performance and Scalability Inside the Siebel Server

Siebel 7 Performance and Scalability Inside the Siebel Server. Richard Sands Siebel Expert Services. Siebel 7 Performance and Scalability. Inside the Siebel Server Introduction to Siebel Architecture How components scale Within servers Across servers Siebel Performance Hints Monitoring

brook
Download Presentation

Siebel 7 Performance and Scalability Inside the Siebel Server

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Siebel 7 Performance and Scalability Inside the Siebel Server Richard SandsSiebel Expert Services

  2. Siebel 7 Performance and Scalability Inside the Siebel Server • Introduction to Siebel Architecture • How components scale • Within servers • Across servers • Siebel Performance • Hints • Monitoring • Diagnosis

  3. Performance and Scalability Architecture Overview Component Scalability Scalability Across Components Network Scalability Performance Optimization Performance Management

  4. VoiceInteraction Object Manager Object Manager EmailInteraction Data Manager Data Manager Siebel 7 Infrastructure Overview Mobile (Disconnected)Web User Connected Web User(Employee) Connected Web User(External) PDA Wireless Web Browser User Interface Browser User Interface Browser User Interface Browser User Interface Object Manager WAP Gateway Server Data Manager Web Server(s) Siebel Web Server Extension SIEBSYNC Local DB Gateway Name Server Central Dispatch Load Balancer Siebel Remote ExternalApplications Siebel Enterprise Server SiebeleAI SiebelReplication Regional Siebel DB Server Central Siebel DB Server

  5. Major Client Types • All accessed through a browser • High Interactivity (Employee facing) • Very demanding on browser • Can only run on strictly defined browser configurations • Rich user interface • Standard Interactivity (Customer facing) • Less demanding on browser • Can run on wide variety of browsers • Standard web user interface • Mobile Client • Has local copy of Siebel database • User-specific subset of data • Local server functionality • Quasi-web server • Business Object and Data Manager functionality • Uses High Interactivity interface

  6. Siebel Server Siebel Server Component Component Siebel Enterprise Server – SWSE • Siebel Web Server Extensions • Web Server Plug-In • Manages communications to Siebel Enterprise • Includes cache for static files (images, etc) Web Server SWSE Gateway Server GatewayName Server Resonate Central Dispatch EnterpriseServer

  7. Siebel Server Siebel Server Component Component Siebel Enterprise Server – Gateway Server • Serves as a single entry point • Includes Siebel Gateway Name Server • Siebel Enterprise configuration data (static) • Siebel Enterprise operations data (dynamic) • Optionally includes Resonate Central Dispatch • Load balancing Web Server SWSE Gateway Server GatewayName Server Resonate Central Dispatch Enterprise Server

  8. Siebel Server Siebel Server Component Component Siebel Enterprise Server – Gateway Name Server • Holds Enterprise Configuration • Stores component definitions, parameters, and connectivity information • Stored in siebns.dat file • Provides Connectivity information when Resonate not used • Dynamically registers Siebel Server and component availability Web Server SWSE Gateway Server GatewayName Server Resonate Central Dispatch Enterprise Server

  9. Web Server SWSE Siebel Server Siebel Server Component Component Siebel Enterprise Server – Resonate Central Dispatch • Load Balances Object Manager Components • Provides resilience for load balanced components • Provides session management • Simplifies firewall configuration • Not always needed Gateway Server GatewayName Server Resonate Central Dispatch Enterprise Server

  10. Architecture Overview – Siebel Server • Framework for running server components • Obtains configuration information from the Gateway Name Server • Runs as a Windows service • Siebel Enterprise Server is a logical grouping of Siebel Servers Web Server SWSE Gateway Server GatewayName Server Resonate Central Dispatch Enterprise Server Siebel Server Siebel Server Component Component

  11. Architecture Overview – Server Components A type of program, executed as a task Examples: • Object Manager - Handling client requests • Workflow Process Manager – Processing Workflows • File System Manager - Handling access to Siebel File System Web Server SWSE Gateway Server GatewayName Server Resonate Central Dispatch Enterprise Server Siebel Server Siebel Server Component Component

  12. Architecture Overview – Server Component Types Different types of component run in different ways: • Background Background mode components execute tasks to perform background operations for the Siebel Server. After a background mode component task starts, it runs until you explicitly stop the task, or until the Siebel Server itself is shut down. • Interactive Interactive mode components start tasks automatically in response to client requests. Interactive mode component tasks execute for as long as the client maintains the session, and end when the client disconnects. • Batch Batch mode components execute tasks in response to requests. Batch mode component tasks execute until they finish processing. • Internal batch tasks are initiated by other Siebel Server tasks • External batch tasks are initiated by Server Manager

  13. Architecture Overview – Component Execution Platforms Different types of component execute in different platforms: • Single Threaded Single threaded components have one execution stream per process. So each operating system process supports a single Siebel Task. i.e. EIM • Multi-threaded Multi-threaded components have multiple execution streams within a single process.. So each operating system process can support multiple Siebel Tasks. i.e. Object Managers

  14. Performance and Scalability Architecture Overview Component Scalability Scalability Across Components Network Scalability Performance Optimization Performance Management

  15. Component Scalability How Components Scale in a Siebel 7 Enterprise • Scaling within a server • Multi-threaded components • Single-threaded components • Scaling across servers • Load balancing • Resonate central dispatch • Load sharing • Server Request Broker • Server Request Processor

  16. Scaling Within a Siebel Server • Single Threaded Components • Create multiple processes (tasks) • Some components are limitedi.e. • Transaction Processor – max 1 per server • Workflow Monitor Agent – max 1 per policy group per Enterprise • Can be started manually, through Server Request Broker, or automatically (‘Default Tasks’ parameter) • Multi-Threaded Components • Create multiple threads &/or processes (tasks) • Control distribution through component parameters

  17. Multi-Threaded Components • Can have multiple processes as well as multiple threads • Important to control ratio of threads to processes • Can have major impact on performance • Determined primarily by rate of switches between threads • 100:1 good starting point for Client Object Managers • Assumes 30sec think time • For 15 sec think time use 50:1 • Can set additional processes to spawn on demand • Will always start minimum number specified • Will start additional processes as needed to maintain process:thread ratio • Limit on maximum number of processes

  18. Memory Scalability • Multi-Process, Multi-Threaded model • All threads in a process share the same memory space • Each Process has a separate memory space • No single process needs a large memory space • Operating system manages memory allocation • If a single process needs more than 1GB there’s normally something wrong • No need for large process memory model (‘/3GB’ switch) • Can use Microsoft PAE for access to large memory capacities • Operating system can allocate memory to each process

  19. Multi-Threaded Component Parameters • Typically set per component • Maximum number of tasks (MaxTasks) • Maximum number of Tasks per component per server • One thread per task • Some additional background “system” threads - not counted by MaxTasks • Maximum number of Multi-Threaded servers (MaxMTServers) • An MTServer is a multi-threaded component process • This defines the maximum number of MTServers per component per server • Minimum number of Multi-Threaded servers (MinMTServers) • This defines the minimum number of MTServers per component per server • Sets the number of MTServers started on server startup

  20. Configuring the Object Managers • Set MaxTasks = peak (concurrent users + anonymous users) • Anonymous users are used for login screens before user authenticates • Typically set to 10%-15% of concurrent user count • Set MaxMTServers = MaxTasks / 100 • An MTServer is equivalent to single instance of Object Manager • 100 : 1 ratio is assuming “average” 30 second think time between user operations • If average user think time is 15 seconds then ratio is 50 : 1 ( 50% of 100:1) • If average user think time is 60 seconds then ratio is 200 : 1 (200% of 100:1) • Set MinMTServers = MaxMTServers • Setting MinMT Servers < MaxMTServers may cause delay of service for “new” users as MTServer gets initialized.

  21. Anonymous Users 120 15% MaxTasks 1000 MaxTasks 920 Round up to maintain100:1 ratio 100:1 MaxMTServers 10 MinMTServers 10 Multi-Threaded Component Parameter Example • Object Manager configuration for 800 Call Center users Concurrent Users 800 Call Center Users Object Manager Level

  22. Scaling Across Siebel Servers Depends on how component task initiated • Component Group Assignment • Which servers a component is available on • Object Managers • Load balanced (Resonate Central Dispatch) • Not valid for eConfigurator Object Manager • Siebel Remote • Manual allocation of mobile client to Siebel Server • Server Requests • Server Request Broker &/or Server Request Processor • Manual Requests (start task) • Manually specified server • Special cases • CTI • eConfigurator

  23. Siebel Server Siebel Server VerticalScalability Sales Object Manager Sales Object Manager Sales Object Manager Sales Object Manager Sales Object Manager Sales Object Manager Sales Object Manager Sales Object Manager Horizontal Scalability Multi-Threaded Component Scalability Enterprise Server Siebel Server Sales Object Manager

  24. Web Client Web Client Web Client Web Client Web Client Web Client Load Balancing Web Server + SWSE Web Server + SWSE Resonate Load Balancing Siebel Server Siebel Server Sales Object Manager Sales Object Manager Sales Object Manager Sales Object Manager Thread Process Server Load Balancing Enterprise Server

  25. Performance and Scalability Architecture Overview Component Scalability Scalability Across Components Network Scalability Performance Optimization Performance Management

  26. Server Request Broker & Server Request Processor • Server Request Broker (SRBroker) • Used to start synchronous Siebel Server tasks • Server Request Broker & Server Manager are the only components which directly start tasks. • New in Siebel 7 • Replaces Server Request Manager (SRMSynch) in Siebel 2000 • Background component • Multi-threaded component • Need to set MaxTasks accordingly • Server Request Processor (SRProc) • Used to start asynchronous Siebel Server tasks • Manages queued requests • Calls SRBroker to manage task execution • Background component

  27. Server Request Broker • Accepts requests from other Components • Will try to service request locally • If component is available on same Siebel Server then this is always used • If not available locally then will use other Siebel Servers • Maintains internal table of components available on each Siebel Server • Will route requests round Siebel Servers in turn (round-robin) • Multi-threaded component • May need to increase MaxTasks • Should always be running on all servers

  28. Run Assignment on local server Siebel Server – Server Request Broker Run Assignment Task ObjectManager AssignmentManager Is Assignment available on this server? ServerRequestBroker ServerRequestBroker ServerRequestBroker WorkflowProcessManager AssignmentManager WorkflowProcessManager

  29. Which other servers have workflow online? Siebel Server – Server Request Broker Run Workflow Process ObjectManager AssignmentManager Is Workflow Manageravailable on this server? ServerRequestBroker ServerRequestBroker ServerRequestBroker Choose server on round-robin basis WorkflowProcessManager AssignmentManager WorkflowProcessManager

  30. Server Request Processor • Processes asynchronous requests • Request submitted by creating record in table • S_SRM_REQUEST • Server Request Processor reads from table • Request must: • Be active (reached activation time) • Not be specified for a different Siebel Server • Not being processed by other Server Request Processor • Eligible requests submitted through Server Request Broker • Normally runs on all Siebel Servers

  31. Siebel Server – Server Request Processor Sleep Interval SRProc S_SRM_REQUEST Request Queue SRBroker Task

  32. Performance and Scalability Architecture Overview Component Scalability Scalability Across Components Network Scalability Performance Optimization Performance Management

  33. Connection Pooling Siebel 7 can pool sessions at two levels: • Web server to Siebel Enterprise • SISNAPI Connection Pooling • Multiple SISNAPI (Siebel) sessions through one TCP session • Reduces operating system overhead and network traffic • Enabled by defaultSet to 20 • Controlled by component parameter:‘Number of Sessions per SISNAPI Connection’ • Siebel Object Manager to Database • Database connection pooling • SQL traffic for multiple Siebel users through one database session • Reduces session overheads on database server • Disabled by default • Suitable for larger deployments (over 500 concurrent users)

  34. Database Connection Pooling • Connections use native database protocols • Some components directly access native protocol • Object Managers • Siebel 7 supports its own database connection pooling • Used for connections from Object Managers • Two types of connection • Shared – for general transactions • Specialized – for long running • Not always appropriate • Should carefully evaluate tradeoffs • Benefits of less database sessions to maintain • Risk of database session contention

  35. Database Connection Pooling • Database session uses login for first user to establish session • Database connection pooling controls • Defined as component parameters • Set to ‘-1’ to disable (default) • Specialized (Dedicated) Database sessions • All valid per component process (MT Server) per Siebel Server • MaxTrxDbConns - Maximum number of specialized DB sessions • MinTrxDbConns - Minimum number of specialized DB sessions to be kept in pool • Shared Database sessions • Valid per component per Siebel Server • MaxSharedDbConns - Maximum number of shared DB sessions • MinSharedDbConns - Minimum number of shared DB sessions to be kept in pool

  36. Siebel Database Database Network Architecture Client Connections Siebel Server Object Manager Server Request Processor Shared Specialized Shared Native Database Connectivity(ODBC for SQL Server) Threads (sessions) Processes (components)

  37. Performance and Scalability Architecture Overview Component Scalability Scalability Across Components Network Scalability Performance Optimization Performance Management

  38. General Siebel Server Optimisation • Disable unused components and component groups • These just use up system resources • Consider using common log file for multi-threaded components that generate too many log files • Consider using multiple instances/server tasks for certain activities • e.g. Parallel EIM, multiple Workflow Policy Groups, etc. • Monitor resource utilization by processes and threads

  39. Object Manager Optimization • Enabling View Caching for High Interactive mode • Set in user preferences • Faster client response times, by as much as 1 second • Better network behavior • Expensive, 3MB per view cached • Most users use < 10 views / pages • Uses LRU mechanism to flush out cache • If not using eAdvisor or browser based eConfigurator • On cfg file set “EnableCDA = FALSE” • Set “Timed Statistics” Off • Set all Log Levels to 1

  40. EAI Optimization • Minimize fields in Integration Components • Keep XML records small • XML is very verbose and needs to be parsed • Lump several records into one transaction • will achieve higher throughput • If possible keep records to 15 fields • More will reduce throughput • Keep in mind that an XML field translates to BC field • Integration Object initialize Business Objects and Business Components • The more fields per record the slower it will process

  41. EAI Optimization • Reduce SessPerSisnConn for EAI Adapters • Do this only if you are going to “bombard” adapter, i.e. little or no think times • For very high throughput systems where you are dedicating EAI machines • Consider letting the SRB forward BIM requests to dedicated machines • BIM processing can become bottleneck if BIM processing is complex • May be necessary to have a higher EAI Adapter:BIM machine ratio (i.e. 1:x) • Use ‘Session-Mode’ for high volume inbound HTTP • Greatly increased throughput • No overhead for authentication & session startup for each message

  42. Workflow Process Optimisation • Use Run-Time Events for process automation • Minimize use of Workflow Policies since workflow policy work at the database layer and do not take advantage of the level of abstraction provided with the Object Manager • Performance gain since the decision event takes place on the business object layer and so no trigger is created on the table • No need for scripting • Workflow Process Distribution • Workflow Policies can’t be directly load balanced • Asynchronous Workflow Processes are distributed by SRProcessor • Synchronous Workflow Process requests are distributed by SRBroker

  43. Application Performance - Configuration • Keep scripting small and tight • Avoid the use of script wherever possible • Remember it is still interpreted code and will execute as such • Ensure all objects are destroyed after use – avoid memory leaks • MVG Applets • Keep to a minimum as they increase SQL complexity • Use primary joins as much as possible; reduces number of SQL statements • Use SmartScript only where really required • E.g. Novice Call Center users • Avoid putting external news pages on login page • 3rd party web sites can be slow

  44. Application Performance - Configuration • Activate only fields that are absolutely necessary • Become active when displayed; “Force Active” in BC configuration • General rule, the more fields on a page the slower the page • Recently saw customer with 750 fields and 80 tables for one applet • Include only manageable set of fields on list applets • Many customers use several dozen fields; not usable and slow performance • Pages with more than three applets will perform slower for HI applications • Reason for this is not really the number of applets, rather the number of fields • PickLists set Long List to TRUE if returning large data sets • Tree Applets can be slow • They generate Bill of Materials type queries

  45. Network Performance – Siebel Configuration • Browser Validation • Reduces the need for server communications to validate data entry • Implement through browser script • Immediate Posting of Changes • Where the ‘Immediate Post Changes’ flag is set against a field data will be transferred whenever a field is changed • Incurs additional round trip with approx 2KB data • Keep to no more than two Applets per View • Minimize Popups • Limit columns in List Applets

  46. Network Performance – Siebel Settings • View Caching • View definitions cached in browser memory • Requires approx 3MB memory per view • Typically around 10 cached views is enough • Uses LRU algorithm to maintain cache contents • Personalization and Applet Toggles won’t use view caching • Enabled through Object Manager configuration (.cfg) file setting [SWE] EnableViewCache=TRUE • Controlled through: • User Preferences > Behaviour > View Cache Size • Default: 10

  47. Network Performance – Siebel Settings • Compression (Dynamic Content) • Performed by SWSE • Do not use web server dynamic compression (application files) • Enabled through SWSE configuration file (‘eapps.cfg’) [Defaults] DoCompression = TRUE • Compression (Static Content) • Performed by web server (IIS only)

  48. Network Performance – Web Server / Browser Settings • Browser Settings • Don’t clear cache except when necessary • Ensure ‘Empty Temporary Internet Files Folder when browser is closed’ option is not enabled.

  49. Network Performance – Web Server • Web Server Settings • Use HTTP keep-alive • Reduces the need to negotiate TCP sessions for each HTTP message

  50. Network Performance – Web Server • Web Server Settings • Set Content Expiration • 2 days is typical setting • Set through Internet Information Services Administration • HTTP Headers > Content Expiration

More Related