Archive for category performance

TargetProcess Future

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

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