Hi,
I have a problem with performence (and Out of Memmory Issue) with
catalog management module. There is a section invoked after
Choose Top Category
CollectionGenericValue allCategories =
delegator.findList(ProductCategory, null, null, null, null, false);
for (GenericValue curCat:
as far as performance how much memory have you allocated to ofbiz?
what version of ofbiz are you using?
There is a top Category that should be checked for first.
have not been in that part of the code for a while.
Michał Cukierman sent the following on 8/17/2010 7:41 AM:
Hi,
I have a problem
Thanks for the quick answer.
I have allocated 2GB of memory, so it's not a case. The problem is that
I work on huge data sets. Version is 10.4 but 9.04 is has the same code.
I have ommited those informations 'couse as you see - it's not relevant
to the topic.
I don't understand your last
Hi Micha:
Could I ask how big are your data sets? The reason I ask is that several
years ago, prior to 9.04 I had an out-of-memory problem that was never
resolved. The database tables that I was querying had between 4 - 12
million records. My database (and OFBiz usage of the same) went away
Hi Ruth,
I do not know exact data set size, as we are in development stage at the
moment. What I know is that we need to prepare for:
- unknown no of categories (tests made on 100 000 - then the error
eccured)
- at least 2*suppliers number catalogs
- around 200 different manufacturers
- around
One thing to keep in mind is that with database queries and OFBiz there is no
inherent nature of how it handles large data sets. Each bit of code and each
query needs to be designed with a certain expected data set size, and typically
the more data you want to allow for in the data store the
Hi David:
Thanks for chiming in! I understand and my experience has been exactly
as you say: Each bit of code and each query needs to be designed with a
certain expected data set size
What you get with OFBiz out-of-the-box is a middle of the road
compromise. The really good news is that
I wouldn't say that OFBiz OOTB is a middle of the road compromise, that would
imply consistency in the code which is not the case. The fact is some code is
designed and tested to properly handle millions or even billions of rows in its
target table, and other code can only have a few thousand
Hi David:
Would you be interested in describing for us all - here on the list -
where some of that code is and how an implementation was arrived at to
properly handle millions or even billions of rows in a target table.
I, for one would be very interested in knowing just where that code
I know that Ofbiz is limited in some areas, but as far it's the best
place to start. It's better to improve some code than write it all. What
I also think: I have software for free, I can put some effort to improve
it.
So to keep the problem in mind. What is the way of implementing:
1) How to
Hi Micha:
Sorry, but I'm probably not the best person to answer this question.
Hopefully David or someone who has spent considerable time working with
the API could lend a hand. Its been several years since I've had to look
at optimizing SQL statements within OFBiz.
Regards,
Ruth
Michał
Micheal I have, in the past had to deal with large databases.
even the best enterprise DB has memory problems in this case.
i have had to write Procedures (functions) in the database to parse the
data so it is usable.
That said it is more than just joins, indexes, and where statements, it
is
12 matches
Mail list logo
