If you're still having performance issues - take a look at www.deltek.us - The DPMonitor Performance Monitor. We peel the onion, layer by layer, simply, easily, and straight-fowardly.
The DPMonitor Performance Monitor will clearly identify where the bottlenecks are on your application server, and map out when they happen, and also map out progress you make towards resolving those bottlenecks and the issues that drive them. All this without contributing to the overhead of the application platform being monitored. Proof positive that you have indeed resolved those bottleneck issues too. User extensible Probes easily set up to monitor for various thresholds, or script-able test for status/conditions, and then based on results of such test for status/condition, take pre-programmed responsive actions against such conditions. Great for on-going monitoring, operational alerting, capacity planning, and resource utilization. Proactively know what you need and when you need it, before you go over the performance cliff. Clear evidence to justify upgrades to management, if needed, or to hold software developers/providers accountable. Licensed product will track individual, user selected process, or all processes. All monitored processes are graphically mapped out over a timeline of your choosing, so it is rather easy to pick out areas for further drill down investigation and analysis. 10 day free evaluation of system wide performance metrics via downloading the DPMonitor from the website. Priced by number of CPU's on application server. Why not take a free 10 day download evaluation test drive and see what it says? Need support? It's included. Email [EMAIL PROTECTED] Need professional services to find and help resolve those bottlenecks, (including application analysis and restructuring)? Please inquire through the website. We have the technology. ----- Original Message ----- From: "André Nel" <[EMAIL PROTECTED]> To: "U2 Users Discussion List" <[EMAIL PROTECTED]> Sent: Wednesday, March 24, 2004 4:20 AM Subject: RE: UniVerse vs Progress Performance Referring to the posting of Jonothan in reply to my query, I should perhaps clarify the portion regarding the Dynamic Files. Only those files which grow day by day (INVOICE-FILE, RECEIPT-FILE etc.) are Dynamic Files. Further to this the 2 files mentioned above are distributed files spanning 40+ UniVerse Accounts. Tables and files with minimal or no growth are sized as T18 files etc. Issues that we need to address seems to be the following: File Handles. Indexing (we don't index NULL's). Thanks for the feedback. André -----Original Message----- From: Jonathan D Smith [mailto:[EMAIL PROTECTED] Sent: 24 March 2004 10:38 AM To: [EMAIL PROTECTED] Subject: Re: UniVerse vs Progress Performance Hi, Must agree with Tim in that performance bottlenecks are complex things to track down, and others have all made valid suggestions regarding Indexes etc . However I have noticed that you say ALL your files are T30 (i.e Dynamic). Why ?, Dynamic files carry an overhead with UniVerse and at the operating system level, which must be weighed against the maintenance time you have. Firstly Dynamic Files use two Unix Inodes, i.e Two File Handles to open each Dynamic File the DATA.30 and OVER.30 sections. This means it uses two slots in the rotating file pool (Have you checked what MFILES is set to in your UniVerse Config as this controls the size of the rotating file pool). The header information controlling splits and merges for Dynamic Files is controlled by ONE UniVerse Semaphore and ONE shared memory structure (The size of which is defined by T30FILES). This means that the more T30FILES you have, it means more file handles and potential more collisions on the Dynamic file semaphore (have you looked at smat -s to see the collision and retry rate on the Dynamic File Semaphore). Don't get me wrong Dynamic Files have there uses, but they are NOT maintenance free (as some people think) they are low maintenance. Files that do not increase in size or their increase can be predicted over a given period , in my view, should not be Dynamic (why use two file handles, where one will do). Also Dynamic Files are great for work files as they shrink and grow with use .... BUT the time hit is when the file has to grow again, for your temporary / work files have you considered using a minimum modulus to control the contraction of the file and hence making sure UniVerse does not need to repeat work it's already done. Finally, Dynamic Files never return there unused OVER30 space back to the machine, hence from time to time during maintenance you may wish to run RESIZE file * * * as this has the side effect on Dynamic Files of claiming back unused space. Hopefully, this will show you what everyone has meant by eliminating bottlenecks is a complex recursive process, I mean I've done 3 paragraphs on Dynamic Files alone ..... Regards, Jonathan Smith IBM Certified Solutions Expert Advanced Support Engineer - U2 Advanced Technical Support IBM Data Management Solutions Support Phone 0800 773 771 Support Mailto:[EMAIL PROTECTED] http://www.ibm.com/software/data/u2/support - Open, Query, Update, Search - Online! DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please delete it and notify the sender immediately. -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
