Hi All
I am trying to set-up my test jira instance. However, i observe that the performance (accessing issues, doing searches etc) of my test instance is far slower than my production instance.
The re-indexing also takes thrice as much time as production (30 min as against 10 min in prod)
I performed a disk access speed and the response was very high.
My configurations on test instance (Windows VM and database as MySQL) is identical as my Production instance.
TOTALS
---- ---- ---- ---- ----
stat avg median min max
---- ---- ---- ---- ----
open 312,643 282,903 0 1,971,454
r/w 218,192 204,805 0 6,233,593
close 7,950,142 7,685,733 1 42,521,468
delete 686,339 647,251 0 4,177,542
---- ---- ---- ---- ----
All times are in nanoseconds.
I have also attached the guidelines of disk access speeds suggested by Atlassian
Below is a breakdown of approximate average speeds that can be used to grade the results.
Open | < 40,000 | < 80,000 | > 150,000 |
Read/Write | < 40,000 | < 60,000 | > 100,000 |
Close | < 20,000 | < 40,000 | > 100,000 |
Delete | < 50,000 | < 200,000 | > 300,000 |
My question is, how can I improve the performance of my test instance?
Rahul
Rather than looking for similar settings, look for differences.
Also, if you are in VM, if you VM host as powerful as your production?
You can't really trust timing results inside a VM, it's all down to ticks and you can't guarantee that every tick happens when it should. Overall, the result will be fine but at a low level.... it's a bit like quantum mechanics vs newtonian physics
BTW, why are you going to 4.1.2? This is Jira isn't it? Surely 4.4.5 at the latest (IE7 support)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
and have you benchmarked your MySQL?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Because I have to import projects from another jira instance which is at 4.1.2...final goal is to go to 5.2...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No I have not....I just looked up on the internet what it is....
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
also networking... how do you know that something else in your test VM host isn't taking bandwidth?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Matthew: The test instance VM was cloned from the production VM...so it is the most identical it can get....
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'd probably go through the upgrade and go straight to 5.2 and do your performance testing there. There is no point fine tuning an environment that you are going to be over-writing straight away
I also count 5 major software changes going on all at the same time, it's never going to be easy to identify the root when so much is changing. Can you not do it as a migration on 3.13 to new software (DB, drivers, test env etc) and benchmark that. Then upgrade to 4.1.2, then to 5.2 & re-do the benchmarks
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok, there's a whole swathe of things here.
We don't know what your hardware is. The use of VMs, while they have massive advantages, does reduce the chance of like-for-like testing being of much use. Unless your production and test VM servers are separate and pretty much physically indentical and running about the same stuff, comparing two VMs at this level is mostly useless.
Your software is not like-for-like. This is understandable as you are testing an upgrade, but it further compounds the problems from comparing VMs
You haven't mentioned which VM servers you are using. Have you read https://confluence.atlassian.com/display/JIRA/Running+JIRA+in+a+Virtualised+Environment ?
We don't know much about your MySQL installations - local or remote? Also on VMs? Have you benchmarked them?
One thing that will cause massive disk access on Windows boxes is anti-virus software - have you disabled that on both?
I think a first step might be to forget the upgrade - get a new copy of the live VM and benchmark that with the current software. If it's similar to live, great, you have a baseline. If it isn't the same, then you definitely can't compare them and you might as well give up. Assuming you can, then change one component at a time and re-benchmark. At the moment, you suspect it's Jira (as do I), but you have not ruled out either the database version, the database connector, the operating environment, the database server, etc etc etc
I'm not sure that jumping from 3.13 to 4.1 is the best jump either - I'd have gone for 4.0 or 4.2 myself, but I've not read the docs, so don't quote me.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Nic for your detailed comments. I will investigate on the points you have mentioned.
Rahul
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What is running on your test instance that is not running on live? What's the difference in hardware?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
My SQL connector :
On production it is :mysql-connector-java-5.0.8 and
on new test instance it is: mysql-connector-java-5.1.10
Database Version:
On production it is : MySQl 5.0.67
on new test instance it is: MySQL 5.5.28-0ubuntu0.12.04.3
Java VM memory:
On production it is : 762 MB
on new test instance it is:986 MB
Jira version:
On production it is : 3.13
on new test instance it is: 4.1.2 (using test instance to test upgrade)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.