You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Clement Escoffier <cl...@gmail.com> on 2014/06/20 19:43:16 UTC

Re: IPojo performance benchmark

Hi,

First, I just discovered the slides. About the performance benches, I don’t know them, but for sure in the recent versions we didn’t really focus on performances (except if the overhead with really big). The service registration overhead is definitely weird, I will have a look on it.

Anyway, so far I’ve applications running from 500 to 5000 services in different context (IoT, Web Applications…). In these case, iPOJO performs pretty well, and its cost is meaningless in comparison of the other costs (network, file system…).

Regards,

Clement


On 20 juin 2014 at 17:41:52, sylvain.hamel@miranda.com (sylvain.hamel@miranda.com) wrote:

Hi  

Recently I read this article regarding various Dependency manager  
performance.  

http://www.slideshare.net/SanderMak/the-ultimate-dependency-manager-shootout-qcon-ny-2014  

We are now asking ourself what is the "real" IPojo performance in the  
field ( actual real enterprise application with thousands of services).  

Thanks  
Sylvain Hamel | Software Designer/Concepteur de logiciels  
Grass Valley, A Belden Brand | Tel:(514) 333-1772 Ext: 3146  
3499 Douglas-B.-Floreani, Montreal, Quebec Canada H4S 2C6  

Please note our new company name!  
www.new.grassvalley.com  
DISCLAIMER:  
Privileged and/or Confidential information may be contained in this  
message. If you are not the addressee of this message, you may not  
copy, use or deliver this message to anyone. In such event, you  
should destroy the message and kindly notify the sender by reply  
e-mail. It is understood that opinions or conclusions that do not  
relate to the official business of the company are neither given  
nor endorsed by the company.  
Thank You.  

Re: IPojo performance benchmark

Posted by Karl Pauls <ka...@gmail.com>.
I believe the code is here (haven't looked at it myself):
https://github.com/sandermak/osgi-dm-shootout

regards,

Karl


On Fri, Jun 20, 2014 at 7:43 PM, Clement Escoffier <
clement.escoffier@gmail.com> wrote:

> Hi,
>
> First, I just discovered the slides. About the performance benches, I
> don’t know them, but for sure in the recent versions we didn’t really focus
> on performances (except if the overhead with really big). The service
> registration overhead is definitely weird, I will have a look on it.
>
> Anyway, so far I’ve applications running from 500 to 5000 services in
> different context (IoT, Web Applications…). In these case, iPOJO performs
> pretty well, and its cost is meaningless in comparison of the other costs
> (network, file system…).
>
> Regards,
>
> Clement
>
>
> On 20 juin 2014 at 17:41:52, sylvain.hamel@miranda.com (
> sylvain.hamel@miranda.com) wrote:
>
> Hi
>
> Recently I read this article regarding various Dependency manager
> performance.
>
>
> http://www.slideshare.net/SanderMak/the-ultimate-dependency-manager-shootout-qcon-ny-2014
>
> We are now asking ourself what is the "real" IPojo performance in the
> field ( actual real enterprise application with thousands of services).
>
> Thanks
> Sylvain Hamel | Software Designer/Concepteur de logiciels
> Grass Valley, A Belden Brand | Tel:(514) 333-1772 Ext: 3146
> 3499 Douglas-B.-Floreani, Montreal, Quebec Canada H4S 2C6
>
> Please note our new company name!
> www.new.grassvalley.com
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
> Thank You.
>



-- 
Karl Pauls
karlpauls@gmail.com
http://twitter.com/karlpauls
http://www.linkedin.com/in/karlpauls
https://profiles.google.com/karlpauls

Re: IPojo performance benchmark

Posted by Al...@miranda.com.
I was at OSGi DevCon last week where that presentation was given and to be 
fair, the guys did say that the iPojo results were suspicious and that 
they might be due to some misunderstanding of how to use iPojo since they 
don't normally use it. But as it was mentioned already by Karl, the code 
is publicly available so maybe someone can take a look.

Alejandro Endo | Software Designer/Concepteur de logiciels 





From:   Clement Escoffier <cl...@gmail.com>
To:     users@felix.apache.org, sylvain.hamel@miranda.com, 
Date:   2014-06-20 01:43 PM
Subject:        Re: IPojo performance benchmark



Hi,

First, I just discovered the slides. About the performance benches, I 
don?t know them, but for sure in the recent versions we didn?t really 
focus on performances (except if the overhead with really big). The 
service registration overhead is definitely weird, I will have a look on 
it.

Anyway, so far I?ve applications running from 500 to 5000 services in 
different context (IoT, Web Applications?). In these case, iPOJO performs 
pretty well, and its cost is meaningless in comparison of the other costs 
(network, file system?).

Regards,

Clement


On 20 juin 2014 at 17:41:52, sylvain.hamel@miranda.com 
(sylvain.hamel@miranda.com) wrote:

Hi 

Recently I read this article regarding various Dependency manager 
performance. 

http://www.slideshare.net/SanderMak/the-ultimate-dependency-manager-shootout-qcon-ny-2014 
 

We are now asking ourself what is the "real" IPojo performance in the 
field ( actual real enterprise application with thousands of services). 

Thanks 
Sylvain Hamel | Software Designer/Concepteur de logiciels 
Grass Valley, A Belden Brand | Tel:(514) 333-1772 Ext: 3146 
3499 Douglas-B.-Floreani, Montreal, Quebec Canada H4S 2C6 

Please note our new company name! 
www.new.grassvalley.com 
DISCLAIMER: 
Privileged and/or Confidential information may be contained in this 
message. If you are not the addressee of this message, you may not 
copy, use or deliver this message to anyone. In such event, you 
should destroy the message and kindly notify the sender by reply 
e-mail. It is understood that opinions or conclusions that do not 
relate to the official business of the company are neither given 
nor endorsed by the company. 
Thank You. 


DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.