"jeffdelong" wrote : Having said this I again raise the concern about
performance. Is the database schema and gui architecture able to handle these types of
queries when there are 20,000 processInstances and 100,000 taskInstances in the db, and
the query results in 2000 hits?
In a word: Yes. :-) Well, subject to testing anyway.
Well, at least for the two types of data you've mentioned (process instances and task
instances).
Process Definitions are a problem. If we had 100,000 processes each with 100 versions it
would be slow (to get a list of the 100,000 processes, we can't use things like
limit/offset because it's a grouping operation, meaning that the server would [in this
contrived case] have to accumulate 10,000,000 rows before it could return even the first
10). I'd like to see this addressed at least for the new prototype as I've
outlined in other posts.
The other queries (in the GUI) are designed right now to impose a hard limit of 100 pages,
under the rationale that more than 100 pages is not useful to the user and that they
should reduce the search. This number is configurable as well. The advantage to this
approach is that the database does not need to be hit to fetch each page, which avoids a
race condition where the result set changes between pages causing rows to appear to vanish
(where in actuality they have simply moved from the page you are on to a prior page). The
disadvantage is that the search can result in a fairly good-sized chunk of data coming
from the database (though in my actual experience it takes more than about 5k rows to
start slowing things down; after all, we're only displaying one page at a time, and in
most cases the real bandwidth bottleneck is between the web server and the end user, not
between the web server and the database).
At some point we should be able to add well-performing sorting to this model as well,
assuming judicious use of indexes.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999068#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...