Quantcast

Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Jacopo Cappellato-4
Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) are used to gather statistics about how clients use the OFBiz instance.
The information in these entities is not used by business processes but it is very important to analyze the system performance, user's behavior etc...
This simple data model is very powerful because can capture very granular information about each visit.

The disadvantage is that it can add significant load on the database server and can impact performance; on servers with high users load these tables can be huge; in fact, in most production instances the granular logging is disabled.

I am proposing here a change that should make the stat gathering subcomponent more flexible, clean and powerful, and increase the performance of the system:
1) remove all the fk dependencies from business entities to the Visit/Visitor/ServerHit/ServerHitBin entities
2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) entities to a separate entity-group
3) in this way it will be easy to configure the entity engine to store them in a separate database (e.g. a NoSQL db); by default we could keep them in the same db where all the other entities are

What do you think?

Jacopo
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Divesh Dutta
This will really be a good improvement in OFBiz.  Sounds like good plan to
me.

Thanks
--
Divesh

On Thu, Dec 18, 2014 at 2:17 PM, Jacopo Cappellato <
[hidden email]> wrote:

>
> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) are
> used to gather statistics about how clients use the OFBiz instance.
> The information in these entities is not used by business processes but it
> is very important to analyze the system performance, user's behavior etc...
> This simple data model is very powerful because can capture very granular
> information about each visit.
>
> The disadvantage is that it can add significant load on the database
> server and can impact performance; on servers with high users load these
> tables can be huge; in fact, in most production instances the granular
> logging is disabled.
>
> I am proposing here a change that should make the stat gathering
> subcomponent more flexible, clean and powerful, and increase the
> performance of the system:
> 1) remove all the fk dependencies from business entities to the
> Visit/Visitor/ServerHit/ServerHitBin entities
> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related *Type
> entities) entities to a separate entity-group
> 3) in this way it will be easy to configure the entity engine to store
> them in a separate database (e.g. a NoSQL db); by default we could keep
> them in the same db where all the other entities are
>
> What do you think?
>
> Jacopo
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Jacques Le Roux
Administrator
In reply to this post by Jacopo Cappellato-4
Since those statistics entities have no functional impacts on business entities, that sounds pretty reasonable to me.

Just a question, did you already try (free?) JDBC drivers for NoSQL DBs, like Apache Cassandra or MongoDB for instance?

Jacques

Le 18/12/2014 09:47, Jacopo Cappellato a écrit :

> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) are used to gather statistics about how clients use the OFBiz instance.
> The information in these entities is not used by business processes but it is very important to analyze the system performance, user's behavior etc...
> This simple data model is very powerful because can capture very granular information about each visit.
>
> The disadvantage is that it can add significant load on the database server and can impact performance; on servers with high users load these tables can be huge; in fact, in most production instances the granular logging is disabled.
>
> I am proposing here a change that should make the stat gathering subcomponent more flexible, clean and powerful, and increase the performance of the system:
> 1) remove all the fk dependencies from business entities to the Visit/Visitor/ServerHit/ServerHitBin entities
> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) entities to a separate entity-group
> 3) in this way it will be easy to configure the entity engine to store them in a separate database (e.g. a NoSQL db); by default we could keep them in the same db where all the other entities are
>
> What do you think?
>
> Jacopo
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Ashish Vijaywargiya
In reply to this post by Jacopo Cappellato-4
Very Good Idea, +1 for this change.

--
Kind Regards,
Ashish Vijaywargiya


On Thu, Dec 18, 2014 at 2:17 PM, Jacopo Cappellato <
[hidden email]> wrote:

>
> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) are
> used to gather statistics about how clients use the OFBiz instance.
> The information in these entities is not used by business processes but it
> is very important to analyze the system performance, user's behavior etc...
> This simple data model is very powerful because can capture very granular
> information about each visit.
>
> The disadvantage is that it can add significant load on the database
> server and can impact performance; on servers with high users load these
> tables can be huge; in fact, in most production instances the granular
> logging is disabled.
>
> I am proposing here a change that should make the stat gathering
> subcomponent more flexible, clean and powerful, and increase the
> performance of the system:
> 1) remove all the fk dependencies from business entities to the
> Visit/Visitor/ServerHit/ServerHitBin entities
> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related *Type
> entities) entities to a separate entity-group
> 3) in this way it will be easy to configure the entity engine to store
> them in a separate database (e.g. a NoSQL db); by default we could keep
> them in the same db where all the other entities are
>
> What do you think?
>
> Jacopo
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Gil Portenseigne
In reply to this post by Jacopo Cappellato-4
Seems to be a good enhancement, not changing default behaviour, so +1 !

Gil

Le 18/12/2014 09:47, Jacopo Cappellato a écrit :

> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) are used to gather statistics about how clients use the OFBiz instance.
> The information in these entities is not used by business processes but it is very important to analyze the system performance, user's behavior etc...
> This simple data model is very powerful because can capture very granular information about each visit.
>
> The disadvantage is that it can add significant load on the database server and can impact performance; on servers with high users load these tables can be huge; in fact, in most production instances the granular logging is disabled.
>
> I am proposing here a change that should make the stat gathering subcomponent more flexible, clean and powerful, and increase the performance of the system:
> 1) remove all the fk dependencies from business entities to the Visit/Visitor/ServerHit/ServerHitBin entities
> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) entities to a separate entity-group
> 3) in this way it will be easy to configure the entity engine to store them in a separate database (e.g. a NoSQL db); by default we could keep them in the same db where all the other entities are
>
> What do you think?
>
> Jacopo

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Arun Patidar
In reply to this post by Ashish Vijaywargiya
+1

Thanks & Regards
---
Arun Patidar
Manager,Enterprise Software Development
HotWax Media
www.hotwaxmedia.com

On Thursday 18 December 2014 03:20 PM, Ashish Vijaywargiya wrote:

> Very Good Idea, +1 for this change.
>
> --
> Kind Regards,
> Ashish Vijaywargiya
>
>
> On Thu, Dec 18, 2014 at 2:17 PM, Jacopo Cappellato <
> [hidden email]> wrote:
>> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) are
>> used to gather statistics about how clients use the OFBiz instance.
>> The information in these entities is not used by business processes but it
>> is very important to analyze the system performance, user's behavior etc...
>> This simple data model is very powerful because can capture very granular
>> information about each visit.
>>
>> The disadvantage is that it can add significant load on the database
>> server and can impact performance; on servers with high users load these
>> tables can be huge; in fact, in most production instances the granular
>> logging is disabled.
>>
>> I am proposing here a change that should make the stat gathering
>> subcomponent more flexible, clean and powerful, and increase the
>> performance of the system:
>> 1) remove all the fk dependencies from business entities to the
>> Visit/Visitor/ServerHit/ServerHitBin entities
>> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related *Type
>> entities) entities to a separate entity-group
>> 3) in this way it will be easy to configure the entity engine to store
>> them in a separate database (e.g. a NoSQL db); by default we could keep
>> them in the same db where all the other entities are
>>
>> What do you think?
>>
>> Jacopo

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Pranay Pandey-2
In reply to this post by Jacopo Cappellato-4
+1

It will be really great enhancement. Disabling logging to these entities
because of increased load shouldn't be a choice for sure.

Thanks,

Pranay Pandey
HotWax Media
www.hotwaxmedia.com

On Thu, Dec 18, 2014 at 2:17 PM, Jacopo Cappellato <
[hidden email]> wrote:

>
> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) are
> used to gather statistics about how clients use the OFBiz instance.
> The information in these entities is not used by business processes but it
> is very important to analyze the system performance, user's behavior etc...
> This simple data model is very powerful because can capture very granular
> information about each visit.
>
> The disadvantage is that it can add significant load on the database
> server and can impact performance; on servers with high users load these
> tables can be huge; in fact, in most production instances the granular
> logging is disabled.
>
> I am proposing here a change that should make the stat gathering
> subcomponent more flexible, clean and powerful, and increase the
> performance of the system:
> 1) remove all the fk dependencies from business entities to the
> Visit/Visitor/ServerHit/ServerHitBin entities
> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related *Type
> entities) entities to a separate entity-group
> 3) in this way it will be easy to configure the entity engine to store
> them in a separate database (e.g. a NoSQL db); by default we could keep
> them in the same db where all the other entities are
>
> What do you think?
>
> Jacopo
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Adrian Crum-3
In reply to this post by Jacopo Cappellato-4
+1

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 12/18/2014 8:47 AM, Jacopo Cappellato wrote:

> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) are used to gather statistics about how clients use the OFBiz instance.
> The information in these entities is not used by business processes but it is very important to analyze the system performance, user's behavior etc...
> This simple data model is very powerful because can capture very granular information about each visit.
>
> The disadvantage is that it can add significant load on the database server and can impact performance; on servers with high users load these tables can be huge; in fact, in most production instances the granular logging is disabled.
>
> I am proposing here a change that should make the stat gathering subcomponent more flexible, clean and powerful, and increase the performance of the system:
> 1) remove all the fk dependencies from business entities to the Visit/Visitor/ServerHit/ServerHitBin entities
> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) entities to a separate entity-group
> 3) in this way it will be easy to configure the entity engine to store them in a separate database (e.g. a NoSQL db); by default we could keep them in the same db where all the other entities are
>
> What do you think?
>
> Jacopo
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Mridul Pathak-2
In reply to this post by Jacopo Cappellato-4
+1, Very useful enhancement.

--
Regards,
Mridul Pathak


> On Dec 18, 2014, at 2:17 PM, Jacopo Cappellato <[hidden email]> wrote:
>
> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) are used to gather statistics about how clients use the OFBiz instance.
> The information in these entities is not used by business processes but it is very important to analyze the system performance, user's behavior etc...
> This simple data model is very powerful because can capture very granular information about each visit.
>
> The disadvantage is that it can add significant load on the database server and can impact performance; on servers with high users load these tables can be huge; in fact, in most production instances the granular logging is disabled.
>
> I am proposing here a change that should make the stat gathering subcomponent more flexible, clean and powerful, and increase the performance of the system:
> 1) remove all the fk dependencies from business entities to the Visit/Visitor/ServerHit/ServerHitBin entities
> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) entities to a separate entity-group
> 3) in this way it will be easy to configure the entity engine to store them in a separate database (e.g. a NoSQL db); by default we could keep them in the same db where all the other entities are
>
> What do you think?
>
> Jacopo

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Deepak Dixit-2
In reply to this post by Jacopo Cappellato-4
+1

Thanks & Regards

Deepak Dixit


> On Dec 18, 2014, at 2:17 PM, Jacopo Cappellato <[hidden email]> wrote:
>
> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) are used to gather statistics about how clients use the OFBiz instance.
> The information in these entities is not used by business processes but it is very important to analyze the system performance, user's behavior etc...
> This simple data model is very powerful because can capture very granular information about each visit.
>
> The disadvantage is that it can add significant load on the database server and can impact performance; on servers with high users load these tables can be huge; in fact, in most production instances the granular logging is disabled.
>
> I am proposing here a change that should make the stat gathering subcomponent more flexible, clean and powerful, and increase the performance of the system:
> 1) remove all the fk dependencies from business entities to the Visit/Visitor/ServerHit/ServerHitBin entities
> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) entities to a separate entity-group
> 3) in this way it will be easy to configure the entity engine to store them in a separate database (e.g. a NoSQL db); by default we could keep them in the same db where all the other entities are
>
> What do you think?
>
> Jacopo


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

anahita goljahani
+1

I agree with others that it is a very useful enhancement!


Kind regards

Anahita



2014-12-19 11:06 GMT+01:00 Deepak Dixit <[hidden email]>:

>
> +1
>
> Thanks & Regards
> —
> Deepak Dixit
>
>
> > On Dec 18, 2014, at 2:17 PM, Jacopo Cappellato <
> [hidden email]> wrote:
> >
> > Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities)
> are used to gather statistics about how clients use the OFBiz instance.
> > The information in these entities is not used by business processes but
> it is very important to analyze the system performance, user's behavior
> etc...
> > This simple data model is very powerful because can capture very
> granular information about each visit.
> >
> > The disadvantage is that it can add significant load on the database
> server and can impact performance; on servers with high users load these
> tables can be huge; in fact, in most production instances the granular
> logging is disabled.
> >
> > I am proposing here a change that should make the stat gathering
> subcomponent more flexible, clean and powerful, and increase the
> performance of the system:
> > 1) remove all the fk dependencies from business entities to the
> Visit/Visitor/ServerHit/ServerHitBin entities
> > 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related
> *Type entities) entities to a separate entity-group
> > 3) in this way it will be easy to configure the entity engine to store
> them in a separate database (e.g. a NoSQL db); by default we could keep
> them in the same db where all the other entities are
> >
> > What do you think?
> >
> > Jacopo
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Anil Patel-3
In reply to this post by Jacopo Cappellato-4
+1

Ability to store data in NoSQL database is super important.

Thanks and Regards
Anil Patel
COO
Hotwax Media Inc
http://www.hotwaxmedia.com/
ApacheCon US 2014 Silver Sponsor
http://na.apachecon.com/sponsor/our-sponsors

> On Dec 18, 2014, at 3:47 AM, Jacopo Cappellato <[hidden email]> wrote:
>
> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) are used to gather statistics about how clients use the OFBiz instance.
> The information in these entities is not used by business processes but it is very important to analyze the system performance, user's behavior etc...
> This simple data model is very powerful because can capture very granular information about each visit.
>
> The disadvantage is that it can add significant load on the database server and can impact performance; on servers with high users load these tables can be huge; in fact, in most production instances the granular logging is disabled.
>
> I am proposing here a change that should make the stat gathering subcomponent more flexible, clean and powerful, and increase the performance of the system:
> 1) remove all the fk dependencies from business entities to the Visit/Visitor/ServerHit/ServerHitBin entities
> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) entities to a separate entity-group
> 3) in this way it will be easy to configure the entity engine to store them in a separate database (e.g. a NoSQL db); by default we could keep them in the same db where all the other entities are
>
> What do you think?
>
> Jacopo

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Jacopo Cappellato-4
In reply to this post by Jacopo Cappellato-4
Thanks to all of you for your valuable feedback.
The first pass of this work is now complete, please refer to rev. 1647271

Jacopo

On Dec 18, 2014, at 9:47 AM, Jacopo Cappellato <[hidden email]> wrote:

> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) are used to gather statistics about how clients use the OFBiz instance.
> The information in these entities is not used by business processes but it is very important to analyze the system performance, user's behavior etc...
> This simple data model is very powerful because can capture very granular information about each visit.
>
> The disadvantage is that it can add significant load on the database server and can impact performance; on servers with high users load these tables can be huge; in fact, in most production instances the granular logging is disabled.
>
> I am proposing here a change that should make the stat gathering subcomponent more flexible, clean and powerful, and increase the performance of the system:
> 1) remove all the fk dependencies from business entities to the Visit/Visitor/ServerHit/ServerHitBin entities
> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities) entities to a separate entity-group
> 3) in this way it will be easy to configure the entity engine to store them in a separate database (e.g. a NoSQL db); by default we could keep them in the same db where all the other entities are
>
> What do you think?
>
> Jacopo

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Deepak Dixit-3
I think we can enable the commented group and can add this in
entityengine.xml.
Definitely it will increase one database creation, but if user doesn't want
to create new database user can use same data-resource used for
org.apache.ofbiz package.

Others opinion ?

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Mon, Dec 22, 2014 at 2:52 PM, Jacopo Cappellato <
[hidden email]> wrote:

> Thanks to all of you for your valuable feedback.
> The first pass of this work is now complete, please refer to rev. 1647271
>
> Jacopo
>
> On Dec 18, 2014, at 9:47 AM, Jacopo Cappellato <jacopo.cappellato@
> hotwaxmedia.com> wrote:
>
> > Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities)
> are used to gather statistics about how clients use the OFBiz instance.
> > The information in these entities is not used by business processes but
> it is very important to analyze the system performance, user's behavior
> etc...
> > This simple data model is very powerful because can capture very
> granular information about each visit.
> >
> > The disadvantage is that it can add significant load on the database
> server and can impact performance; on servers with high users load these
> tables can be huge; in fact, in most production instances the granular
> logging is disabled.
> >
> > I am proposing here a change that should make the stat gathering
> subcomponent more flexible, clean and powerful, and increase the
> performance of the system:
> > 1) remove all the fk dependencies from business entities to the
> Visit/Visitor/ServerHit/ServerHitBin entities
> > 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related
> *Type entities) entities to a separate entity-group
> > 3) in this way it will be easy to configure the entity engine to store
> them in a separate database (e.g. a NoSQL db); by default we could keep
> them in the same db where all the other entities are
> >
> > What do you think?
> >
> > Jacopo
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Michael Brohl-3
Hi Deepak,

I'm not sure if I understand correctly. Do you propose to configure
different databases/data resources for the Visits* entity group?

Regards,

Michael


Am 11.05.17 um 14:12 schrieb Deepak Dixit:

> I think we can enable the commented group and can add this in
> entityengine.xml.
> Definitely it will increase one database creation, but if user doesn't want
> to create new database user can use same data-resource used for
> org.apache.ofbiz package.
>
> Others opinion ?
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
>
> On Mon, Dec 22, 2014 at 2:52 PM, Jacopo Cappellato <
> [hidden email]> wrote:
>
>> Thanks to all of you for your valuable feedback.
>> The first pass of this work is now complete, please refer to rev. 1647271
>>
>> Jacopo
>>
>> On Dec 18, 2014, at 9:47 AM, Jacopo Cappellato <jacopo.cappellato@
>> hotwaxmedia.com> wrote:
>>
>>> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities)
>> are used to gather statistics about how clients use the OFBiz instance.
>>> The information in these entities is not used by business processes but
>> it is very important to analyze the system performance, user's behavior
>> etc...
>>> This simple data model is very powerful because can capture very
>> granular information about each visit.
>>> The disadvantage is that it can add significant load on the database
>> server and can impact performance; on servers with high users load these
>> tables can be huge; in fact, in most production instances the granular
>> logging is disabled.
>>> I am proposing here a change that should make the stat gathering
>> subcomponent more flexible, clean and powerful, and increase the
>> performance of the system:
>>> 1) remove all the fk dependencies from business entities to the
>> Visit/Visitor/ServerHit/ServerHitBin entities
>>> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related
>> *Type entities) entities to a separate entity-group
>>> 3) in this way it will be easy to configure the entity engine to store
>> them in a separate database (e.g. a NoSQL db); by default we could keep
>> them in the same db where all the other entities are
>>> What do you think?
>>>
>>> Jacopo
>>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Deepak Dixit-3
Yes Michael, you understood correctly

>>>3) added a new entity group ("org.ofbiz.stats") for the
Visit/Visitor/ServerHit* (and related) entities; for now the group is not
active so that the entities are still in the same database as before;
however assigning them to a different database is now a matter of
uncommenting the group file definition in framework/webapp/ofbiz-component.xml
and provide the new datasource definition



Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Thu, May 11, 2017 at 6:03 PM, Michael Brohl <[hidden email]>
wrote:

> Hi Deepak,
>
> I'm not sure if I understand correctly. Do you propose to configure
> different databases/data resources for the Visits* entity group?
>
> Regards,
>
> Michael
>
>
> Am 11.05.17 um 14:12 schrieb Deepak Dixit:
>
> I think we can enable the commented group and can add this in
>> entityengine.xml.
>> Definitely it will increase one database creation, but if user doesn't
>> want
>> to create new database user can use same data-resource used for
>> org.apache.ofbiz package.
>>
>> Others opinion ?
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>>
>> On Mon, Dec 22, 2014 at 2:52 PM, Jacopo Cappellato <
>> [hidden email]> wrote:
>>
>> Thanks to all of you for your valuable feedback.
>>> The first pass of this work is now complete, please refer to rev. 1647271
>>>
>>> Jacopo
>>>
>>> On Dec 18, 2014, at 9:47 AM, Jacopo Cappellato <jacopo.cappellato@
>>> hotwaxmedia.com> wrote:
>>>
>>> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities)
>>>>
>>> are used to gather statistics about how clients use the OFBiz instance.
>>>
>>>> The information in these entities is not used by business processes but
>>>>
>>> it is very important to analyze the system performance, user's behavior
>>> etc...
>>>
>>>> This simple data model is very powerful because can capture very
>>>>
>>> granular information about each visit.
>>>
>>>> The disadvantage is that it can add significant load on the database
>>>>
>>> server and can impact performance; on servers with high users load these
>>> tables can be huge; in fact, in most production instances the granular
>>> logging is disabled.
>>>
>>>> I am proposing here a change that should make the stat gathering
>>>>
>>> subcomponent more flexible, clean and powerful, and increase the
>>> performance of the system:
>>>
>>>> 1) remove all the fk dependencies from business entities to the
>>>>
>>> Visit/Visitor/ServerHit/ServerHitBin entities
>>>
>>>> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related
>>>>
>>> *Type entities) entities to a separate entity-group
>>>
>>>> 3) in this way it will be easy to configure the entity engine to store
>>>>
>>> them in a separate database (e.g. a NoSQL db); by default we could keep
>>> them in the same db where all the other entities are
>>>
>>>> What do you think?
>>>>
>>>> Jacopo
>>>>
>>>
>>>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Michael Brohl-3
Mmmhh, I would propose it the other way around for the default: use the
same data resource for the new group.

Visits and such are only a problem in large production settings with
lots of traffic. Users who will set up such an environment will have to
do some other tweaks as well and will have no problem to configure the
new group for the use of another data resource.

Whereas new users and those who have lower traffic will not need another
database. I would like to keep it simple here to avoid confusion and
unnecessary complexity.

Best regards,

Michael


Am 11.05.17 um 18:34 schrieb Deepak Dixit:

> Yes Michael, you understood correctly
>
>>>> 3) added a new entity group ("org.ofbiz.stats") for the
> Visit/Visitor/ServerHit* (and related) entities; for now the group is not
> active so that the entities are still in the same database as before;
> however assigning them to a different database is now a matter of
> uncommenting the group file definition in framework/webapp/ofbiz-component.xml
> and provide the new datasource definition
>
>
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
>
> On Thu, May 11, 2017 at 6:03 PM, Michael Brohl <[hidden email]>
> wrote:
>
>> Hi Deepak,
>>
>> I'm not sure if I understand correctly. Do you propose to configure
>> different databases/data resources for the Visits* entity group?
>>
>> Regards,
>>
>> Michael
>>
>>
>> Am 11.05.17 um 14:12 schrieb Deepak Dixit:
>>
>> I think we can enable the commented group and can add this in
>>> entityengine.xml.
>>> Definitely it will increase one database creation, but if user doesn't
>>> want
>>> to create new database user can use same data-resource used for
>>> org.apache.ofbiz package.
>>>
>>> Others opinion ?
>>>
>>> Thanks & Regards
>>> --
>>> Deepak Dixit
>>> www.hotwaxsystems.com
>>>
>>> On Mon, Dec 22, 2014 at 2:52 PM, Jacopo Cappellato <
>>> [hidden email]> wrote:
>>>
>>> Thanks to all of you for your valuable feedback.
>>>> The first pass of this work is now complete, please refer to rev. 1647271
>>>>
>>>> Jacopo
>>>>
>>>> On Dec 18, 2014, at 9:47 AM, Jacopo Cappellato <jacopo.cappellato@
>>>> hotwaxmedia.com> wrote:
>>>>
>>>> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities)
>>>> are used to gather statistics about how clients use the OFBiz instance.
>>>>
>>>>> The information in these entities is not used by business processes but
>>>>>
>>>> it is very important to analyze the system performance, user's behavior
>>>> etc...
>>>>
>>>>> This simple data model is very powerful because can capture very
>>>>>
>>>> granular information about each visit.
>>>>
>>>>> The disadvantage is that it can add significant load on the database
>>>>>
>>>> server and can impact performance; on servers with high users load these
>>>> tables can be huge; in fact, in most production instances the granular
>>>> logging is disabled.
>>>>
>>>>> I am proposing here a change that should make the stat gathering
>>>>>
>>>> subcomponent more flexible, clean and powerful, and increase the
>>>> performance of the system:
>>>>
>>>>> 1) remove all the fk dependencies from business entities to the
>>>>>
>>>> Visit/Visitor/ServerHit/ServerHitBin entities
>>>>
>>>>> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related
>>>>>
>>>> *Type entities) entities to a separate entity-group
>>>>
>>>>> 3) in this way it will be easy to configure the entity engine to store
>>>>>
>>>> them in a separate database (e.g. a NoSQL db); by default we could keep
>>>> them in the same db where all the other entities are
>>>>
>>>>> What do you think?
>>>>>
>>>>> Jacopo
>>>>>
>>>>
>>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Deepak Dixit-3
Make sense Michael,

Its good idea to not to define new datasource for new group to avoid
unnecessary complexity,
will add this group in delegator group mapping and set the default
datasource for new group.

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Thu, May 11, 2017 at 11:35 PM, Michael Brohl <[hidden email]>
wrote:

> Mmmhh, I would propose it the other way around for the default: use the
> same data resource for the new group.
>
> Visits and such are only a problem in large production settings with lots
> of traffic. Users who will set up such an environment will have to do some
> other tweaks as well and will have no problem to configure the new group
> for the use of another data resource.
>
> Whereas new users and those who have lower traffic will not need another
> database. I would like to keep it simple here to avoid confusion and
> unnecessary complexity.
>
> Best regards,
>
> Michael
>
>
> Am 11.05.17 um 18:34 schrieb Deepak Dixit:
>
> Yes Michael, you understood correctly
>>
>> 3) added a new entity group ("org.ofbiz.stats") for the
>>>>>
>>>> Visit/Visitor/ServerHit* (and related) entities; for now the group is
>> not
>> active so that the entities are still in the same database as before;
>> however assigning them to a different database is now a matter of
>> uncommenting the group file definition in framework/webapp/ofbiz-compone
>> nt.xml
>> and provide the new datasource definition
>>
>>
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>>
>> On Thu, May 11, 2017 at 6:03 PM, Michael Brohl <[hidden email]>
>> wrote:
>>
>> Hi Deepak,
>>>
>>> I'm not sure if I understand correctly. Do you propose to configure
>>> different databases/data resources for the Visits* entity group?
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>
>>> Am 11.05.17 um 14:12 schrieb Deepak Dixit:
>>>
>>> I think we can enable the commented group and can add this in
>>>
>>>> entityengine.xml.
>>>> Definitely it will increase one database creation, but if user doesn't
>>>> want
>>>> to create new database user can use same data-resource used for
>>>> org.apache.ofbiz package.
>>>>
>>>> Others opinion ?
>>>>
>>>> Thanks & Regards
>>>> --
>>>> Deepak Dixit
>>>> www.hotwaxsystems.com
>>>>
>>>> On Mon, Dec 22, 2014 at 2:52 PM, Jacopo Cappellato <
>>>> [hidden email]> wrote:
>>>>
>>>> Thanks to all of you for your valuable feedback.
>>>>
>>>>> The first pass of this work is now complete, please refer to rev.
>>>>> 1647271
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Dec 18, 2014, at 9:47 AM, Jacopo Cappellato <jacopo.cappellato@
>>>>> hotwaxmedia.com> wrote:
>>>>>
>>>>> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities)
>>>>> are used to gather statistics about how clients use the OFBiz instance.
>>>>>
>>>>> The information in these entities is not used by business processes but
>>>>>>
>>>>>> it is very important to analyze the system performance, user's
>>>>> behavior
>>>>> etc...
>>>>>
>>>>> This simple data model is very powerful because can capture very
>>>>>>
>>>>>> granular information about each visit.
>>>>>
>>>>> The disadvantage is that it can add significant load on the database
>>>>>>
>>>>>> server and can impact performance; on servers with high users load
>>>>> these
>>>>> tables can be huge; in fact, in most production instances the granular
>>>>> logging is disabled.
>>>>>
>>>>> I am proposing here a change that should make the stat gathering
>>>>>>
>>>>>> subcomponent more flexible, clean and powerful, and increase the
>>>>> performance of the system:
>>>>>
>>>>> 1) remove all the fk dependencies from business entities to the
>>>>>>
>>>>>> Visit/Visitor/ServerHit/ServerHitBin entities
>>>>>
>>>>> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related
>>>>>>
>>>>>> *Type entities) entities to a separate entity-group
>>>>>
>>>>> 3) in this way it will be easy to configure the entity engine to store
>>>>>>
>>>>>> them in a separate database (e.g. a NoSQL db); by default we could
>>>>> keep
>>>>> them in the same db where all the other entities are
>>>>>
>>>>> What do you think?
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>>>>>
>>>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Deepak Dixit-3
Here is the ticket for enabling stats group
https://issues.apache.org/jira/browse/OFBIZ-9356

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Fri, May 12, 2017 at 12:08 AM, Deepak Dixit <
[hidden email]> wrote:

> Make sense Michael,
>
> Its good idea to not to define new datasource for new group to avoid
> unnecessary complexity,
> will add this group in delegator group mapping and set the default
> datasource for new group.
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
>
> On Thu, May 11, 2017 at 11:35 PM, Michael Brohl <[hidden email]>
> wrote:
>
>> Mmmhh, I would propose it the other way around for the default: use the
>> same data resource for the new group.
>>
>> Visits and such are only a problem in large production settings with lots
>> of traffic. Users who will set up such an environment will have to do some
>> other tweaks as well and will have no problem to configure the new group
>> for the use of another data resource.
>>
>> Whereas new users and those who have lower traffic will not need another
>> database. I would like to keep it simple here to avoid confusion and
>> unnecessary complexity.
>>
>> Best regards,
>>
>> Michael
>>
>>
>> Am 11.05.17 um 18:34 schrieb Deepak Dixit:
>>
>> Yes Michael, you understood correctly
>>>
>>> 3) added a new entity group ("org.ofbiz.stats") for the
>>>>>>
>>>>> Visit/Visitor/ServerHit* (and related) entities; for now the group is
>>> not
>>> active so that the entities are still in the same database as before;
>>> however assigning them to a different database is now a matter of
>>> uncommenting the group file definition in framework/webapp/ofbiz-compone
>>> nt.xml
>>> and provide the new datasource definition
>>>
>>>
>>>
>>> Thanks & Regards
>>> --
>>> Deepak Dixit
>>> www.hotwaxsystems.com
>>>
>>> On Thu, May 11, 2017 at 6:03 PM, Michael Brohl <[hidden email]
>>> >
>>> wrote:
>>>
>>> Hi Deepak,
>>>>
>>>> I'm not sure if I understand correctly. Do you propose to configure
>>>> different databases/data resources for the Visits* entity group?
>>>>
>>>> Regards,
>>>>
>>>> Michael
>>>>
>>>>
>>>> Am 11.05.17 um 14:12 schrieb Deepak Dixit:
>>>>
>>>> I think we can enable the commented group and can add this in
>>>>
>>>>> entityengine.xml.
>>>>> Definitely it will increase one database creation, but if user doesn't
>>>>> want
>>>>> to create new database user can use same data-resource used for
>>>>> org.apache.ofbiz package.
>>>>>
>>>>> Others opinion ?
>>>>>
>>>>> Thanks & Regards
>>>>> --
>>>>> Deepak Dixit
>>>>> www.hotwaxsystems.com
>>>>>
>>>>> On Mon, Dec 22, 2014 at 2:52 PM, Jacopo Cappellato <
>>>>> [hidden email]> wrote:
>>>>>
>>>>> Thanks to all of you for your valuable feedback.
>>>>>
>>>>>> The first pass of this work is now complete, please refer to rev.
>>>>>> 1647271
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Dec 18, 2014, at 9:47 AM, Jacopo Cappellato <jacopo.cappellato@
>>>>>> hotwaxmedia.com> wrote:
>>>>>>
>>>>>> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities)
>>>>>> are used to gather statistics about how clients use the OFBiz
>>>>>> instance.
>>>>>>
>>>>>> The information in these entities is not used by business processes
>>>>>>> but
>>>>>>>
>>>>>>> it is very important to analyze the system performance, user's
>>>>>> behavior
>>>>>> etc...
>>>>>>
>>>>>> This simple data model is very powerful because can capture very
>>>>>>>
>>>>>>> granular information about each visit.
>>>>>>
>>>>>> The disadvantage is that it can add significant load on the database
>>>>>>>
>>>>>>> server and can impact performance; on servers with high users load
>>>>>> these
>>>>>> tables can be huge; in fact, in most production instances the granular
>>>>>> logging is disabled.
>>>>>>
>>>>>> I am proposing here a change that should make the stat gathering
>>>>>>>
>>>>>>> subcomponent more flexible, clean and powerful, and increase the
>>>>>> performance of the system:
>>>>>>
>>>>>> 1) remove all the fk dependencies from business entities to the
>>>>>>>
>>>>>>> Visit/Visitor/ServerHit/ServerHitBin entities
>>>>>>
>>>>>> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related
>>>>>>>
>>>>>>> *Type entities) entities to a separate entity-group
>>>>>>
>>>>>> 3) in this way it will be easy to configure the entity engine to store
>>>>>>>
>>>>>>> them in a separate database (e.g. a NoSQL db); by default we could
>>>>>> keep
>>>>>> them in the same db where all the other entities are
>>>>>>
>>>>>> What do you think?
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: remove fk constraints on Visitor/Visit/ServerHit* entities

Michael Brohl-3
Thanks Deepak!

Am 11.05.17 um 20:54 schrieb Deepak Dixit:

> Here is the ticket for enabling stats group
> https://issues.apache.org/jira/browse/OFBIZ-9356
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
>
> On Fri, May 12, 2017 at 12:08 AM, Deepak Dixit <
> [hidden email]> wrote:
>
>> Make sense Michael,
>>
>> Its good idea to not to define new datasource for new group to avoid
>> unnecessary complexity,
>> will add this group in delegator group mapping and set the default
>> datasource for new group.
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>>
>> On Thu, May 11, 2017 at 11:35 PM, Michael Brohl <[hidden email]>
>> wrote:
>>
>>> Mmmhh, I would propose it the other way around for the default: use the
>>> same data resource for the new group.
>>>
>>> Visits and such are only a problem in large production settings with lots
>>> of traffic. Users who will set up such an environment will have to do some
>>> other tweaks as well and will have no problem to configure the new group
>>> for the use of another data resource.
>>>
>>> Whereas new users and those who have lower traffic will not need another
>>> database. I would like to keep it simple here to avoid confusion and
>>> unnecessary complexity.
>>>
>>> Best regards,
>>>
>>> Michael
>>>
>>>
>>> Am 11.05.17 um 18:34 schrieb Deepak Dixit:
>>>
>>> Yes Michael, you understood correctly
>>>> 3) added a new entity group ("org.ofbiz.stats") for the
>>>>>> Visit/Visitor/ServerHit* (and related) entities; for now the group is
>>>> not
>>>> active so that the entities are still in the same database as before;
>>>> however assigning them to a different database is now a matter of
>>>> uncommenting the group file definition in framework/webapp/ofbiz-compone
>>>> nt.xml
>>>> and provide the new datasource definition
>>>>
>>>>
>>>>
>>>> Thanks & Regards
>>>> --
>>>> Deepak Dixit
>>>> www.hotwaxsystems.com
>>>>
>>>> On Thu, May 11, 2017 at 6:03 PM, Michael Brohl <[hidden email]
>>>> wrote:
>>>>
>>>> Hi Deepak,
>>>>> I'm not sure if I understand correctly. Do you propose to configure
>>>>> different databases/data resources for the Visits* entity group?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>> Am 11.05.17 um 14:12 schrieb Deepak Dixit:
>>>>>
>>>>> I think we can enable the commented group and can add this in
>>>>>
>>>>>> entityengine.xml.
>>>>>> Definitely it will increase one database creation, but if user doesn't
>>>>>> want
>>>>>> to create new database user can use same data-resource used for
>>>>>> org.apache.ofbiz package.
>>>>>>
>>>>>> Others opinion ?
>>>>>>
>>>>>> Thanks & Regards
>>>>>> --
>>>>>> Deepak Dixit
>>>>>> www.hotwaxsystems.com
>>>>>>
>>>>>> On Mon, Dec 22, 2014 at 2:52 PM, Jacopo Cappellato <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>> Thanks to all of you for your valuable feedback.
>>>>>>
>>>>>>> The first pass of this work is now complete, please refer to rev.
>>>>>>> 1647271
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Dec 18, 2014, at 9:47 AM, Jacopo Cappellato <jacopo.cappellato@
>>>>>>> hotwaxmedia.com> wrote:
>>>>>>>
>>>>>>> Visit/Visitor/ServerHit/ServerHitBin (and the related *Type entities)
>>>>>>> are used to gather statistics about how clients use the OFBiz
>>>>>>> instance.
>>>>>>>
>>>>>>> The information in these entities is not used by business processes
>>>>>>>> but
>>>>>>>>
>>>>>>>> it is very important to analyze the system performance, user's
>>>>>>> behavior
>>>>>>> etc...
>>>>>>>
>>>>>>> This simple data model is very powerful because can capture very
>>>>>>>> granular information about each visit.
>>>>>>> The disadvantage is that it can add significant load on the database
>>>>>>>> server and can impact performance; on servers with high users load
>>>>>>> these
>>>>>>> tables can be huge; in fact, in most production instances the granular
>>>>>>> logging is disabled.
>>>>>>>
>>>>>>> I am proposing here a change that should make the stat gathering
>>>>>>>> subcomponent more flexible, clean and powerful, and increase the
>>>>>>> performance of the system:
>>>>>>>
>>>>>>> 1) remove all the fk dependencies from business entities to the
>>>>>>>> Visit/Visitor/ServerHit/ServerHitBin entities
>>>>>>> 2) assign the Visit/Visitor/ServerHit/ServerHitBin (and the related
>>>>>>>> *Type entities) entities to a separate entity-group
>>>>>>> 3) in this way it will be easy to configure the entity engine to store
>>>>>>>> them in a separate database (e.g. a NoSQL db); by default we could
>>>>>>> keep
>>>>>>> them in the same db where all the other entities are
>>>>>>>
>>>>>>> What do you think?
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>>
>>>


smime.p7s (5K) Download Attachment
12
Loading...