Hi oVirt Board Members, We are starting a process of optimizing the Ovirt Engine code for performance. To accomplish that, we need a Java Profiler. Many solutions exist in the market, some of them are open source. However, for our process, we need to have the following functionality from the profiler: * CPU profiling * See the application Hot Spots - meaning which method takes the longest to run, and how many times each method is run. * Memory profiling. * See the biggest objects that exist in the Engine heap, and who created them. * Database profiling. * See the queries that are being sent to the database, how many times they are executed, and the average execution duration. * Thread profiling. * Status of the system threads. These capabilities are covered by commercial profilers. One of them is called JProfiler (http://www.ej-technologies.com/products/jprofiler/overview.html). The company that manufactures JProfiler offers a solution for open source projects, allowing them to use JProfiler licenses for free, in exchange for posting the JProfiler logo on the open source project site. (See here for an example) My question is whether you'll allow such posting on the Ovirt web site, so that the Engine team can use JProfiler to improve Ovirt's Engine performance. Thanks, Liran Zelkha
On 04/18/2013 09:32 PM, Liran Zelkha wrote:
Hi oVirt Board Members,
We are starting a process of optimizing the Ovirt Engine code for performance. To accomplish that, we need a Java Profiler. Many solutions exist in the market, some of them are open source. However, for our process, we need to have the following functionality from the profiler:
* CPU profiling o See the application Hot Spots - meaning which method takes the longest to run, and how many times each method is run. * Memory profiling. o See the biggest objects that exist in the Engine heap, and who created them. * Database profiling. o See the queries that are being sent to the database, how many times they are executed, and the average execution duration. * Thread profiling. o Status of the system threads.
These capabilities are covered by commercial profilers. One of them is called JProfiler (http://www.ej-technologies.com/products/jprofiler/overview.html). The company that manufactures JProfiler offers a solution for open source projects, allowing them to use JProfiler licenses for free, in exchange for posting the JProfiler logo on the open source project site. (See here <http://roq-messaging.org/> for an example)
My question is whether you'll allow such posting on the Ovirt web site, so that the Engine team can use JProfiler to improve Ovirt's Engine performance.
Thanks, Liran Zelkha
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
no replies, so i assume no one objects to this?
I have no issue with this. -- Jon Benedict Technical Marketing Engineer Red Hat Technologies Data Center Platforms Internal Portal http://redhatnetapp.com Blog http://captainkvm.com | Twitter @CaptainKVM On 5/12/13 10:00 AM, "Itamar Heim" <iheim@redhat.com> wrote:
On 04/18/2013 09:32 PM, Liran Zelkha wrote:
Hi oVirt Board Members,
We are starting a process of optimizing the Ovirt Engine code for performance. To accomplish that, we need a Java Profiler. Many solutions exist in the market, some of them are open source. However, for our process, we need to have the following functionality from the profiler:
* CPU profiling o See the application Hot Spots - meaning which method takes the longest to run, and how many times each method is run. * Memory profiling. o See the biggest objects that exist in the Engine heap, and who created them. * Database profiling. o See the queries that are being sent to the database, how many times they are executed, and the average execution duration. * Thread profiling. o Status of the system threads.
These capabilities are covered by commercial profilers. One of them is called JProfiler (http://www.ej-technologies.com/products/jprofiler/overview.html). The company that manufactures JProfiler offers a solution for open source projects, allowing them to use JProfiler licenses for free, in exchange for posting the JProfiler logo on the open source project site. (See here <http://roq-messaging.org/> for an example)
My question is whether you'll allow such posting on the Ovirt web site, so that the Engine team can use JProfiler to improve Ovirt's Engine performance.
Thanks, Liran Zelkha
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
no replies, so i assume no one objects to this? _______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
Hi all I have searched for open alternatives, but they do not provide full view of the application, as is needed in the profiling session of the engine we are conducting. The only alternative I can see is buy JProfiler licenses (or any other commercial profiler) and let internal RedHat team members use it when profiling. Please advise. ----- Original Message ----- From: "Jon Benedict" <Jon.Benedict@netapp.com> To: "Itamar Heim" <iheim@redhat.com>, "Liran Zelkha" <lzelkha@redhat.com> Cc: board@ovirt.org Sent: Tuesday, May 14, 2013 6:12:40 PM Subject: Re: JProfiler I have no issue with this. -- Jon Benedict Technical Marketing Engineer Red Hat Technologies Data Center Platforms Internal Portal http://redhatnetapp.com Blog http://captainkvm.com | Twitter @CaptainKVM On 5/12/13 10:00 AM, "Itamar Heim" <iheim@redhat.com> wrote:
On 04/18/2013 09:32 PM, Liran Zelkha wrote:
Hi oVirt Board Members,
We are starting a process of optimizing the Ovirt Engine code for performance. To accomplish that, we need a Java Profiler. Many solutions exist in the market, some of them are open source. However, for our process, we need to have the following functionality from the profiler:
* CPU profiling o See the application Hot Spots - meaning which method takes the longest to run, and how many times each method is run. * Memory profiling. o See the biggest objects that exist in the Engine heap, and who created them. * Database profiling. o See the queries that are being sent to the database, how many times they are executed, and the average execution duration. * Thread profiling. o Status of the system threads.
These capabilities are covered by commercial profilers. One of them is called JProfiler (http://www.ej-technologies.com/products/jprofiler/overview.html). The company that manufactures JProfiler offers a solution for open source projects, allowing them to use JProfiler licenses for free, in exchange for posting the JProfiler logo on the open source project site. (See here <http://roq-messaging.org/> for an example)
My question is whether you'll allow such posting on the Ovirt web site, so that the Engine team can use JProfiler to improve Ovirt's Engine performance.
Thanks, Liran Zelkha
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
no replies, so i assume no one objects to this? _______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
Hi Liran, It appears I am alone in having concerns about this so I would go ahead and request the project license as you proposed. Thanks, Dave. On 06/25/2013 12:42 PM, Liran Zelkha wrote:
Hi all
I have searched for open alternatives, but they do not provide full view of the application, as is needed in the profiling session of the engine we are conducting. The only alternative I can see is buy JProfiler licenses (or any other commercial profiler) and let internal RedHat team members use it when profiling. Please advise.
----- Original Message ----- From: "Jon Benedict" <Jon.Benedict@netapp.com> To: "Itamar Heim" <iheim@redhat.com>, "Liran Zelkha" <lzelkha@redhat.com> Cc: board@ovirt.org Sent: Tuesday, May 14, 2013 6:12:40 PM Subject: Re: JProfiler
I have no issue with this.
-- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
Hi Dave, Thank you. I appreciate it. ----- Original Message ----- From: "Dave Neary" <dneary@redhat.com> To: "Liran Zelkha" <lzelkha@redhat.com> Cc: "Jon Benedict" <Jon.Benedict@netapp.com>, board@ovirt.org Sent: Tuesday, July 2, 2013 12:33:46 PM Subject: Re: JProfiler Hi Liran, It appears I am alone in having concerns about this so I would go ahead and request the project license as you proposed. Thanks, Dave. On 06/25/2013 12:42 PM, Liran Zelkha wrote:
Hi all
I have searched for open alternatives, but they do not provide full view of the application, as is needed in the profiling session of the engine we are conducting. The only alternative I can see is buy JProfiler licenses (or any other commercial profiler) and let internal RedHat team members use it when profiling. Please advise.
----- Original Message ----- From: "Jon Benedict" <Jon.Benedict@netapp.com> To: "Itamar Heim" <iheim@redhat.com>, "Liran Zelkha" <lzelkha@redhat.com> Cc: board@ovirt.org Sent: Tuesday, May 14, 2013 6:12:40 PM Subject: Re: JProfiler
I have no issue with this.
-- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
On 07/02/2013 02:33 AM, Dave Neary wrote:
Hi Liran,
It appears I am alone in having concerns about this so I would go ahead and request the project license as you proposed.
FWIW, you can *always* figure I have concern about using non-FLOSS tools in an open source project. I like learning from history and past mistakes. Bottom line is, if people like us (and our engineering and product managers) don't step up to the line to deliver open solutions for our development needs, then we continue to fall behind closed-but-ready-today solutions in the drive toward deliverable dates. Every decision to purchase a closed solution instead of writing or fixing an open solution hurts the entire ecosystem. It's behavior we can expect at the corporate layer, but it shouldn't push its way up to the community project layer. - Karsten
Thanks, Dave.
On 06/25/2013 12:42 PM, Liran Zelkha wrote:
Hi all
I have searched for open alternatives, but they do not provide full view of the application, as is needed in the profiling session of the engine we are conducting. The only alternative I can see is buy JProfiler licenses (or any other commercial profiler) and let internal RedHat team members use it when profiling. Please advise.
----- Original Message ----- From: "Jon Benedict" <Jon.Benedict@netapp.com> To: "Itamar Heim" <iheim@redhat.com>, "Liran Zelkha" <lzelkha@redhat.com> Cc: board@ovirt.org Sent: Tuesday, May 14, 2013 6:12:40 PM Subject: Re: JProfiler
I have no issue with this.
-- Karsten 'quaid' Wade http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 07/02/2013 11:38 PM, Karsten 'quaid' Wade wrote:
On 07/02/2013 02:33 AM, Dave Neary wrote:
It appears I am alone in having concerns about this so I would go ahead and request the project license as you proposed.
FWIW, you can *always* figure I have concern about using non-FLOSS tools in an open source project. I like learning from history and past mistakes.
Bottom line is, if people like us (and our engineering and product managers) don't step up to the line to deliver open solutions for our development needs, then we continue to fall behind closed-but-ready-today solutions in the drive toward deliverable dates.
Every decision to purchase a closed solution instead of writing or fixing an open solution hurts the entire ecosystem. It's behavior we can expect at the corporate layer, but it shouldn't push its way up to the community project layer.
The choice here, as I understand it, is for Liran & his team to buy a license so that they are the only ones to have access to this tool, or to request a site license for developers of oVirt so that anyone in the project has access. In the former case, we avoid the risk that our build or test processes depend on this tool, but lose the potential benefit to other community members to have the use of this tool. Apparently there is not, at this time, an equivalent open source tool. I think requesting a project license, and then being wary not to depend on this tool in any way to be able to participate in the project, is an acceptable middle ground. Cheers, Dave. - -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR091tAAoJECd1qeknDCggXF0IAMG/YCM8ESF9hG7x/sXrW65B MubdZAvN/PAQ9JQH2joXqaMjb1FiuofnLsGnVpy89RHVxZFFVyo2w34zey7+OFhZ KNcOXlz/IybhZNS6Or3R5kIIaUxhyS5F3HHqrOhwSd1H3MCkr9eEluA59cewLeYw co3cGY/GwaxEU4Mm5vx+87HEvkqnE04ipvqYyYqfyYeoDKiLnmfI+3y5DXceZs4O 7CEYYjfvNNXc/YuyZdBscJ9d5Z6T3EgnYIM7YzEzBk09RS2DfzBD+HES/ZA73pgF MnHPHvjNvwRh1j925CCWN5Oc0h4p7gM05ar8DOHtjc9fFLCgEPQUrB78TaP16cU= =o6HT -----END PGP SIGNATURE-----
On 07/03/2013 12:38 AM, Karsten 'quaid' Wade wrote:
On 07/02/2013 02:33 AM, Dave Neary wrote:
Hi Liran,
It appears I am alone in having concerns about this so I would go ahead and request the project license as you proposed.
FWIW, you can *always* figure I have concern about using non-FLOSS tools in an open source project. I like learning from history and past mistakes.
Bottom line is, if people like us (and our engineering and product managers) don't step up to the line to deliver open solutions for our development needs, then we continue to fall behind closed-but-ready-today solutions in the drive toward deliverable dates.
Every decision to purchase a closed solution instead of writing or fixing an open solution hurts the entire ecosystem. It's behavior we can expect at the corporate layer, but it shouldn't push its way up to the community project layer.
we aren't purchasing, we are using something provided for free for open source projects. similarly, i'm for using the coverity solution for scanning our code(we are also using the open findbugs, but coverity has things not covered by findbugs (it actually uses findbugs now).
- Karsten
Thanks, Dave.
On 06/25/2013 12:42 PM, Liran Zelkha wrote:
Hi all
I have searched for open alternatives, but they do not provide full view of the application, as is needed in the profiling session of the engine we are conducting. The only alternative I can see is buy JProfiler licenses (or any other commercial profiler) and let internal RedHat team members use it when profiling. Please advise.
----- Original Message ----- From: "Jon Benedict" <Jon.Benedict@netapp.com> To: "Itamar Heim" <iheim@redhat.com>, "Liran Zelkha" <lzelkha@redhat.com> Cc: board@ovirt.org Sent: Tuesday, May 14, 2013 6:12:40 PM Subject: Re: JProfiler
I have no issue with this.
_______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
On 07/03/2013 11:43 AM, Itamar Heim wrote:
On 07/03/2013 12:38 AM, Karsten 'quaid' Wade wrote:
On 07/02/2013 02:33 AM, Dave Neary wrote:
Hi Liran,
It appears I am alone in having concerns about this so I would go ahead and request the project license as you proposed.
FWIW, you can *always* figure I have concern about using non-FLOSS tools in an open source project. I like learning from history and past mistakes.
Bottom line is, if people like us (and our engineering and product managers) don't step up to the line to deliver open solutions for our development needs, then we continue to fall behind closed-but-ready-today solutions in the drive toward deliverable dates.
Every decision to purchase a closed solution instead of writing or fixing an open solution hurts the entire ecosystem. It's behavior we can expect at the corporate layer, but it shouldn't push its way up to the community project layer.
we aren't purchasing, we are using something provided for free for open source projects.
s/purchase/choose/g We all know of experiences (BitKeeper => git, etc.) where a provided-for-free solution became a lock-in and then a trap. Another angle is that closed software fails the good science test. Others should be able to reproduce everything we do without needing to obtain non-FLOSS tools. It's also perceived as unfriendly toward other FLOSS projects when we don't use what they provide and help it fix the delta to the closed solutions. These projects are more of our friends normally than the code vendors.
similarly, i'm for using the coverity solution for scanning our code(we are also using the open findbugs, but coverity has things not covered by findbugs (it actually uses findbugs now).
It's a potentially non-fallacious slippery slope - we can draw a reasonable chain of events from the 'small' act of choosing a single closed solution to something fairly bad for the project. The bottom line is that if a project chooses to use a closed solution, it should be after a lot of due diligence that includes making sure it's not better (for many reasons) to improve a FLOSS-but-not-good-enough solution. The project should then put it on the roadmap to get that closed solution replaced via some method - waiting for another project to mature, working up an open solution in parallel, etc. https://www.theopensourceway.org/wiki/How_to_loosely_organize_a_community#Us... - Karsten -- Karsten 'quaid' Wade http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
Hi, On 05/12/2013 04:00 PM, Itamar Heim wrote:
On 04/18/2013 09:32 PM, Liran Zelkha wrote:
These capabilities are covered by commercial profilers. One of them is called JProfiler (http://www.ej-technologies.com/products/jprofiler/overview.html). The company that manufactures JProfiler offers a solution for open source projects, allowing them to use JProfiler licenses for free, in exchange for posting the JProfiler logo on the open source project site. (See here <http://roq-messaging.org/> for an example)
My question is whether you'll allow such posting on the Ovirt web site, so that the Engine team can use JProfiler to improve Ovirt's Engine performance.
no replies, so i assume no one objects to this?
I have no opposition to oVirt developers using JProfiler themselves, but I would not like to see it become a key piece of the project's infrastructure, because it is not open source. I also do not like the idea of promoting JProfiler, a proprietary tool, on the oVirt website. However, if the board members decide that this is appropriate, then we can do this. Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
board-bounces@ovirt.org wrote on 05/15/2013 01:50:58 PM:
From: Dave Neary <dneary@redhat.com> To: board@ovirt.org, Date: 05/15/2013 02:01 PM Subject: Re: JProfiler Sent by: board-bounces@ovirt.org
Hi,
On 05/12/2013 04:00 PM, Itamar Heim wrote:
On 04/18/2013 09:32 PM, Liran Zelkha wrote:
These capabilities are covered by commercial profilers. One of them is called JProfiler (http://www.ej-technologies.com/products/jprofiler/overview.html). The company that manufactures JProfiler offers a solution for open source projects, allowing them to use JProfiler licenses for free, in exchange for posting the JProfiler logo on the open source project site. (See here <http://roq-messaging.org/> for an example)
My question is whether you'll allow such posting on the Ovirt web site, so that the Engine team can use JProfiler to improve Ovirt's Engine performance.
no replies, so i assume no one objects to this?
I have no opposition to oVirt developers using JProfiler themselves, but I would not like to see it become a key piece of the project's infrastructure, because it is not open source.
I also do not like the idea of promoting JProfiler, a proprietary tool, on the oVirt website.
Is there an Open alternative?
However, if the board members decide that this is appropriate, then we can do this.
Cheers, Dave.
-- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 _______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
Cheers, Frank ----------------------------------------------------------------------------------------------------------------------- Frank Novak ( 诺帆 nuò、fān ) STSM, SCEM Open Hypervisor IBM Linux Technology Center US: fnovak@us.ibm.com ; Notes: Frank Novak/Watson/IBM @IBMUS China: franovak@cn.ibm.com ; Notes: Frank Novak/China/IBM@IBMCN China Office: 86-10-82452057 ; China cell : (86) 186-0091-9203 ** Note new China cell number ** -------------------------------------------------------------------------------------------------------------------------
On 05/15/2013 10:50 AM, Dave Neary wrote:
Hi,
On 05/12/2013 04:00 PM, Itamar Heim wrote:
On 04/18/2013 09:32 PM, Liran Zelkha wrote:
These capabilities are covered by commercial profilers. One of them is called JProfiler (http://www.ej-technologies.com/products/jprofiler/overview.html). The company that manufactures JProfiler offers a solution for open source projects, allowing them to use JProfiler licenses for free, in exchange for posting the JProfiler logo on the open source project site. (See here <http://roq-messaging.org/> for an example)
My question is whether you'll allow such posting on the Ovirt web site, so that the Engine team can use JProfiler to improve Ovirt's Engine performance.
no replies, so i assume no one objects to this?
I have no opposition to oVirt developers using JProfiler themselves, but I would not like to see it become a key piece of the project's infrastructure, because it is not open source.
I also do not like the idea of promoting JProfiler, a proprietary tool, on the oVirt website.
However, if the board members decide that this is appropriate, then we can do this.
+1 Perhaps the oVirt team at Red Hat can purchase the can opener^H profiler tool, use it, and report the results on the wiki (where the results are open and free under the Apache license.) As an open community infrastructure geek, I'm extremely wary of any non-open tools in the chain. It's like conducting science that others can't verify themselves. It also makes it harder to run for a volunteer infrastructure team, where skills are usually learned on freely available open source instances. - Karsten -- Karsten 'quaid' Wade http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
participants (6)
-
Benedict, Jon -
Dave Neary -
Frank Novak -
Itamar Heim -
Karsten 'quaid' Wade -
Liran Zelkha