Your SlideShare is downloading. ×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

(ATS4-PLAT08) Server Pool Management

568

Published on

In order to obtain the best performance possible out of your AEP server, the core architecture provides methods to reuse job processes multiple times. This talk will cover how the mechanism …

In order to obtain the best performance possible out of your AEP server, the core architecture provides methods to reuse job processes multiple times. This talk will cover how the mechanism functions, what performance improvements you might expect as well as what potential problems you might encounter, how to use pooling in protocols and applications, and how the administrator or package developers can configure and debug specialized job pools for their particular applications

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
568
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. (ATS4-PLAT08) Server Job Pool Management Steven Bush R&D, AEP Core Infrastructure steven.bush@accelrys.com
  • 2. Job Pooling• Each job works in a single scisvr process – Isolated memory – One bad protocol cannot crash the server• Without pools, each job spawns a new process• With pools, jobs with the same pool ID can reuse idle processes – Ideal for quick running applications
  • 3. Performance• Prevent reloading system files and configuration data• Reuse allocated memory• Skip initialization• Fast running protocols see substantial improvement• Longer protocols do not see much improvement
  • 4. Performance Fast running protocol (0.1 seconds) 16 simultaneous clients against 8 core laptop
  • 5. Performance Longer running protocol (20 seconds) 16 simultaneous clients against 8 core laptop
  • 6. Performance ZOOMED: Longer running protocol (20 seconds) 16 simultaneous clients against 8 core laptop
  • 7. Disadvantages• Some components may not reinitialize themselves correctly – Can be difficult to track down these errors• Stale resources can cause subsequent protocol failure – Example: persistent DB connections that have timed out at the DB• Ties up memory resources – Later: how this is controlled• Can tie up 3rd party licenses if they are not properly released• Hard to get a good grasp of how much memory is really being used
  • 8. How it happens• Each pool is controlled by an ID – Passed in as a parameter by the client during launch • http://myserver:9944/auth/launchjob?_protocol=Protocols/Foo&__poolid=MyPool – Professional client creates a pool for each new job • Uses job ID as pool ID• Links the pool to its specific set of scisvr processes• Pool behavior is controlled by server configuration – Configurations are created by packages – Pool ID is matched to pool configuration. • If a specific configuration does not exist, the _default_pool configuration is used
  • 9. Configuration• <InstallDir>/apps/myCompany/myPackage/xml/Objects/SciSvrPoolConfig.xml – Maximum processes allowed in the pool – Minimum/maximum number of idle processes to keep – How quickly to trim the servers when the maximum is exceeded – How to queue excess job requests in this pool – How long is a process allowed to sit idle – Memory thresholds for idle processes• See apps/scitegic/core/xml/Objects/SciSvrPoolConfig.xml for example – You rarely need to set up a specific configuration! • The _default_pool configuration is fine for most pools
  • 10. Maximum Servers• Determines how many processes can reside in that pool• Requests past the maximum will follow the queueing behavior for the pool – Queue, spawn new process, reject request • 8.5 always spawned new processes• Maximum servers is a soft limit – Simultaneous job requests can push the number of processes past the maximum • The excess will subside as jobs finish
  • 11. Queueing Within Pools• Added in 9.0 – In 8.5, requests past the maximum for a pool spawned new processes• Improves overall throughput under heavy load• Queued items can time out for longer running jobs• Separate from the queuing that takes place when the entire server reaches its job limit
  • 12. Queueing Within Pools Example which reads 500 molecules and returns a bit of JSON text. Maximum servers configured for pool: 32 Elapsed Time/Throughput vs Number of Simultaneous Clients
  • 13. Spare Servers• Scisvr processes that are idle – Minimum • Server will spawn new processes to reach minimum – Maximum – How quickly to trim extras • Trimming 1 server every N seconds avoids sloshing – Idle timeout
  • 14. Warmup protocols• Pools that have StartServers or MinSpareServers set can configure a protocol that runs when a new server is spawned – Only affects processes that are spawned to meet the minimum • Processes launched as a job request will simply run the request – Initialize DB connections and memory use – Preload expected protocols and shortcuts• Example: Components/Data Access and Manipulation/Utilities/Internals/Reference Components/Warmup – Initializes calculable properties, reporting, java components
  • 15. Memory limits• Under heavy memory usage, pooled processes will shut down – Part of pool configuration – _default_pool • 80% total RAM usage • 15% total RAM usage for an individual process • Example: A server has 8 GB of RAM – Idle pooled processes will shut down when RAM usage reaches 6.4 GB – If an individual idle process reaches 1.2 GB, it will shut down
  • 16. Impersonation• Windows – Restricted • Impersonation occurs after process launch • Different user can reuse the same process – Full • Impersonation occurs during process launch • Different user cannot reuse the same process – Queueing within pools is disabled – May wish to reduce idle timeout of pool configurations (300 to 30)• Linux – Impersonation occurs after process launch – Different user can reuse the same process
  • 17. Data Sources • Connection Timeout – Keeps the connection open while scisvr is idle – Supported by ODBC and JDBC data sources
  • 18. Debugging• http://<server>:<port>/scitegic/managepools?action=debug – Shows each pool by ID. • Configuration • Processes that belong to the pool – PID – Owner (impersonation only) – Number of times the server has executed jobs (including warm ups) – State • Queue – Apache Process/Threads that are waiting for a server in this pool
  • 19. Debugging
  • 20. Using Pools From Clients• Pro Client – Automatic based on jobID• Create Protocol Link… – Add __poolID as a parameter to your URL • http://<server>:<port>/auth/launchjob?_protocol=ABC&__poolID=MyPool• Reporting Forms – Add __poolID using “Hidden Form Data”• Protocol Function – use “Application ID” or “Pool ID”• Web Port and Reporting Protocol Links – Add __poolID as a parameter to your protocol• Client SDKs – Pass in __poolID as a parameter when you call the LaunchXXX() methods
  • 21. Special pools• Windows – Warmup • Jobs launched without a poolID will use a single use server from the warmup pool if one is available – KeepWarm • A single scisvr process that runs a small warmup job every 300 seconds to keep AEP libraries from swapping to disk • Helps prevent cold server delays
  • 22. DisclaimerThe information on the roadmap and future software development efforts areintended to outline general product direction and should not be relied on in makinga purchasing decision.

×