Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 451072

Summary:	Performance testing back end administered on eclipse.org
Product:	Community	Reporter:	David Williams <david_williams>
Component:	Servers	Assignee:	Eclipse Webmaster <webmaster>
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	daniel_megert, david_williams, denis.roy, jfrantzius, john.arthorne, markus.kell.r, matthias.mailaender, pawel.pogorzelski1, robin, webmaster
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:
Bug Depends on:	390821
Bug Blocks:	374441, 454921

Description David Williams

2014-11-11 22:55:04 EST

+++ This bug was initially created as a clone of Bug #390821 +++

> We need a back end storage mechanism to persist performance test results, and 
> allow comparing to baseline builds, and analysis of performance across builds.
> ....
> We should keep in mind that other eclipse.org projects might want to make use 
> of the same infrastructure.

I am about to close bug 390821, so wanted to open this enhancement request, for *future* work. I would guesstimate we'd be ready to "give up" control of the database administration end of first quarter, 2015. 

I think this would be worth while, for all involved, if and only if ... 

a) there's more people than "us" ((Platform) that want to use it.  
b) "security" is an issue (it is currently "internal" to eclipse.org infrastructure, but things like roles, user names, passwords, etc., are less than ideal (and, ideally, would tie into Eclipse LDAP. 
c) backups become "business critical". At the moment, and, I'd guess for a few months, it would not hurt all that much to "lose" a data base, but, at some point, when everything is running smoothly, and we have a few years worth of data :) ... then it would be pretty important not to lose it. [As things are at this exact moment, for next few weeks, there might actually be times when we want to simply "delete the database", rather than do the extra work to "clean up" bad data, and similar.]

So, I'm entering this now, for long term planning purposes. And, of course, if the Eclipse Foundation were to say "absolutely not", then that is still important for us to know for *our* long term planning purposes! :) 

Thanks,

Comment 1 Denis Roy

2014-11-12 09:33:12 EST

The last thing we (webmasters) want is to administer little bits and pieces of infrastructure. We have a MySQL cluster _today_ that is administered by us, backed up and can be made available to everyone. 

If you'd like for us to administer a database backend, we can help you migrate it over to our existing backend.

Comment 2 David Williams

2014-11-12 12:34:38 EST

(In reply to Denis Roy from comment #1)
> The last thing we (webmasters) want is to administer little bits and pieces
> of infrastructure. We have a MySQL cluster _today_ that is administered by
> us, backed up and can be made available to everyone. 
> 
> If you'd like for us to administer a database backend, we can help you
> migrate it over to our existing backend.

Thanks for the offer, and that might work, and I admire your bravery in letting me write to your production database :) 

I will have to "read up" on it, and see what kind of "client jars" we can get to include with our performance tests, and what kind of "jdbc driver" ... at least, I'm assuming a jdbc driver would be best (since most generic). 

If you have any specific pointers, that's be good, but otherwise I'll just read up on it at https://www.mysql.com/ and see what's available. I'd likely try to "get it working" on my local test machine before doing anything else ... so, "first quarter" still sounds right for any future work. 

Thanks again,

Comment 3 Denis Roy

2014-11-12 16:31:58 EST

> Thanks for the offer, and that might work, and I admire your bravery in
> letting me write to your production database :) 

We would not start there  :)

 
> I will have to "read up" on it, and see what kind of "client jars" we can
> get to include with our performance tests, and what kind of "jdbc driver"
> ... at least, I'm assuming a jdbc driver would be best (since most generic). 

MySQL has jdbc drivers:

http://dev.mysql.com/downloads/connector/j/


> If you have any specific pointers, that's be good

The more ANSI-compliant your SQL code is, the easier it is to port.  Do you have any pointers to some of the more complex SQL statements?

Comment 4 David Williams

2014-11-17 04:17:54 EST

(In reply to Denis Roy from comment #3)

> 
> > If you have any specific pointers, that's be good
> 
> The more ANSI-compliant your SQL code is, the easier it is to port.  Do you
> have any pointers to some of the more complex SQL statements?

I don't know enough about it (the code) yet, (or, about SQL :) to know what's complex and what's not ... but, there are a bunch of the queries in in one class, SQL_Results.java. For example, see 

http://git.eclipse.org/c/platform/eclipse.platform.releng.buildtools.git/tree/bundles/org.eclipse.test.performance.ui/src/org/eclipse/test/internal/performance/results/db/SQL_Results.java#n181

Notice these are "installed" as "prepared statements". 

I'm not even sure where the "adds" are yet :( 
But, they are in a different bundle.

Comment 5 Denis Roy

2014-11-17 09:42:11 EST

That code (and those types of SQL statements) should Just Work by switching to a different jdbc for MySQL.

Comment 6 Denis Roy

2021-12-20 15:30:40 EST

Not sure what more to do here.