First "Suspect Everything!" when it comes to performance issues. Suspect the Database! (well, not the DB, but your accessing it!) Turn on SQL Logging (SQL Profiler), and restrict to Queries which take > 4 seconds to return data. Then take the top 5 Txxx tables and fix.
Suspect your USERS! (Again SQL Logging) do you have users always searching for "description like ..." well that is a table scan. (You didn't mentioned DB Size, record volume, etc) always searching something else, Index it! (Ok, sometimes do a sp_spaceused and check the index size over the table_size :( ) Suspect the network! Command prompt 'Netstat -s' can tell you a lot! What is the packet retransmission (Segments Retransmitted) percentage to Segments Sent! Do this on EVERY SERVER! (Yes I love my network and server teams, but, you have to keep then honest at times!) Gig-E (Copper or fiber) has known issues about "full - half - auto" settings! And what 'switch' they are hooked to! (Our Gig-e Copper is hard-set (Full) and the Fiber is "Auto"). A great little tool, called "iperf" http://dast.nlanr.net/Projects/Iperf/ is what I use to set a baseline between DBServer<->ARServer<->MidTier HINT: Do this "Idle Hours" to get the "Best Baseline" as reference! HINT: Adjust the PACKET SIZE! User Tool is 'chatty' in small packets, ARSystem is returning data in big chunks.. Suspect your USERS! (Wait I already mentioned that, but suspect them anyway) Suspect the development: As previously mentioned on this thread. Table refresh, especially of tables which are hidden! (not used).. All AL's that run multiple times (form Load & Form Display is quite common and stupidly redundantly redundant at certain times.) Suspect your 'configuration': How much memory do you have allocated (MIN / MAX) to Servlet Exec? (we have 2GB as max, and are thinking about increasing it!) What are the IIS Settings? (IIS 6 - check the "recycler on threads" settings!) Do you have Mid-Tier "Check Cache Settings" DISABLED in production? (Remember to flush cache after a migration to production!) OK, now to reality. When it comes to performance, I always ask: * What are the requirements? Click to Window Open __ Secs? Save to "Commit message" ___ Sec? * Have they "Ever been met, tested and recorded in all environments"? * Are you monitoring these? (Automated scripts check ours and report every 5 minutes to NetIQ!) Just because a "human" says "performance is bad", that is not, pardon me, enough scientific information to go upon! *Where was the user doing it? (Web / Client / Physical Location compared to Server) *What was the user doing? (Open Window, Search, Create, Modify?) *What is the user expectation? (see requirement statement above :) ) I always tell people "Performance Troubleshooting is the 'divide and conquer' technique! Good luck, keep us posted! Thanks-n-advance; HDT Platform Incident / Problem Manager & Architect Robert Molenda IT OS PA Tel: +1 408 501 6310 Fax: +1 408 501 2410 Mobile: +1 408 472 8097 [EMAIL PROTECTED] Quality begins with your actions. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 12:01 PM To: [email protected] Subject: Re: Server sizing & Performance Update: There has been a little degradation over time, I managed to identify a few issues with customization that were causing pain and shave off a little time. Network is 1GB copper app/mid-tier, we're only using one interface although a second is available. I'm dark when it comes to db, I'm going to say it's 1gb as well. DB is MSSQL, shared with another database that's fairly active though DBA says disk I/O isn't causing issue (yet). Performance seems relative no matter where you are, if anything mid-tier seems slower and citrix actually gives us the best performance, we have quiet a few users, most of the heavy users hitting the app via citrix. ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
