Archive for category performance

Support Teamwork: Optimizing Flows

Posted by Olga Kouzina in help desk, performance, support on March 19th, 2010

We’re always working to improve teamwork of our Support and QA folks to better process  support requests (quick reminder:  you can submit your question/idea/request/ issue to TargetProcess HelpDesk or by email)

That’s  how we decided to optimize some flows and eliminate Muda:

1. Some  issues are related to performance. Support work starts with asking basically one and the same set of questions about their server configuration, CPU load, IIS version (see TargetProcess system requirements).  Sending questions and answers back and forth takes time (sometimes days).

The solution we’d use so far is  a documented form that our customers will be supposed to fill in as they encounter performance problems. Why document and not online form: it might take time to put together all the info about server configuration, and an online form can expire. In the future, we could write a utility to measure all the parameters for performance and generate an .xml file.

2. We’ve got a “Waiting for Response” state for the requests waiting on answers from customers. The rule is: if a customer says nothing after 2 days, we send a reminder. Then, if no response in another 2 days, we send a note that we’re closing this request. It takes time to sift through the requests with “Waiting for response” state, so we’d set up an automatic alert utility for that.  Sometimes people don’t see our emails with questions. Maybe their spam filters are blocking TP notifications.  But no emails - no support.  Dear customers, please, keep track of all the notifications and comments from our HelpDesk.

3. Sometimes there’re issues that are impossible to reproduce. Our QA  might spend hours with no success. All the info is in place, all the artifacts - but bugs wouldn’t show up.  For such cases, we’d ask our customers to capture videos and  attach video files to their requests.  If video does not help, then the next step would be to set up an online meeting with customers to find the causes of problems.

You’re welcome to share your opinion: which flows/small things can be improved in TargetProcess support?

Comments

TargetProcess Future

Posted by Michael Dubakov in performance, release, usability on September 11th, 2008

Product development is hard. You have hundreds of customers and thousands of requests. It is impossible to please them all. You may bury the product with blind requests implementation, it is not a news for anybody. You should maintain clear vision and balance like a rope-walker all the time.

During last 11 releases we added new functionality. There was maybe 1 release targeted to peformance and usability improvements, but most of the releases targeted new features: integration, customization, horizontal features, vertical features, etc. We decided to stop.

Next several releases will be dedicated to performance, usability and design improvements. Here is what we are going to do:

  1. Unify design of the application and make it cool and attractive.
  2. Provide outstanding functionality for lists manipulation. People spend much time with data in lists (filtering, editing, etc). All lists will be fully customizable. It will be possible to create a list with any filter, grouping, inner lists, etc. It will be possible to inline edit everything in all lists. All that will be based on ExtJS grid and as a client side solution it will be faster than everything else.
  3. We have about a hundred of really nice requests/ideas/solutions from our customers regarding usability. We are going to implement most of them. Especially email notifications, personal customizability, lists manipulation, navigation, reporting.
  4. Improve overall performance twice.

These are our goals for the next several releases. Maybe quite many of our customers will not be happy. They demand new features like Eclipse integration, CC.NET integration, extended time tracking, budgeting inside TargetProcess, etc. But great performance and superior usability will bring more benefits to all of them.

We are feeling that it is time to eliminate many medium and small problems in TargetProcess to be able to move it forward with greater success.

Comments

Performance in TP 2.3

Posted by Michael Dubakov in performance on February 13th, 2007

Current iteration dedicated to clean-up and performance improvements. We’d released TP 2.1 and TP 2.2 so it is time to refactor some areas as well as improve performance.

The main thing we’ve done is removing Ayende Generics. With other quite specific improvements this gave significant performance boost.

Test Configuration

Test configuration is not enterprise, but rather for small/average company setup. Database and Application are on the same server which is BAD thing for large concurrent users set. In fact if your target is about 100 concurrent users in TargetProcess you should setup database and application on different servers.

Tests themselves are kinda extreme. There are three user types (Developer, QA and Project Manager). QA browse bugs and adds bugs, Developer adds comments and time and browse user stories and ToDo, PM browse different reports. There are about 20% of PM, 40% of QA and 40% of developers in test users population.

Test duration is 10 minutes and during that time about 350 bugs and 400 time records added into database (quite many as you can imagine).

Server configuration: CPU AMD Athlon 64 X2 3800+, RAM 2 GB

Results

Chart below shows average page time (sec) for TP 2.1, TP 2.2 and TP 2.3

This chart shows greater scalability of TP 2.3. Response time for 10, 20 and 30 users in TP 2.3 almost the same.

TP 2.2 or TP 2.1 did not work for 50 or 100 concurrent users (cpu usage is 100% and server almost can’t process requests). TP 2.3 runs with 50 and 100 concurrent users without much problems.

CPU usage is quite good (if you bear in mind that database and IIS on the same server).

Also we’ve measured average CPU usage on application server when database and IIS on separate servers and it is about 50% for 100 concurrent users.

Comments