Smalltalk - Delay in building specs[VW7.4.1]

Author

Delay in building specs[VW7.4.1]

Mani S Kartha

2007-10-05, 7:14 pm

Hi ,

My application includes many windows with main components inputField
,action buttons and subcanvas(instead of labels,we use input fields in
readOnly mode with some text in it).
The complete information for building the windows comes from
database(information like the co ordinates of window and fields,type of
fields and the format of values that is valid for each field, labels of
buttons and background and selection colours of buttons and fields
....etc). We have 7 database tables in which we keep these info(we call
them Base tables) in which we have altogether some 50000 rows(the
project is in the initial stage and the value can grow to the order of
millions)

The application works fine with default memory settings in VisualWorks,
provided the database (we use the HOP framework for DB interaction.So we
assume it is independent of the type of DB. Also we don't use any stored
procedure/functions,now) resides in the same LAN.

But when we have to deal with some centralized database systems(i mean a
remote db server outside the LAN,common for many users) it takes too
much time to build the forms. Most of this lag is caused by the time
needed to fetch the form building data from DB. The application seems to
be too dynamic (the attire of one single form can be entirely different
in looks-if not in functionality, for different users/login)for us to
keep them in the form of normal spec (example #windowSpec and install in
anApplicationModel).

We have been developing this application for more than 2 years and i
think it is too late for us to change the basic design. So my doubt is

Is there some better way to build the windows with much less delay
without compromising on its dynamical advantage?

The suggestions from my team was the following
1. Keep the Entire form building data (all data from 7 base tables)
fetched from db(in RAM),once the application is started.
This causes problem for us in the default memory settings even now.And
we need to consider the possibility of the future growth in the number
of data.

2.Collect all data for form building in Disc (with two options for it)

#1 inside VisualWorks---Not certain, but we would like to try something
like, as in the class side protocol 'interface specs'(we find some
difficulty in that, because we are not sure whether it will be possible,
not to loose the dynamicity of the forms and also we think it will
increase the application size and become too big to handle easily-even
as parcel at deployment)
#2 outside VisualWorks---we don't know much about this option, but we
would like to try object BOSSing

and updating the information for each start up of the application (for
changes in the window configuration, user will have to restart the
application)

Do you have some suggestions to solve these problems (better to be
within VisualWorks)?

thanks in advance for any such hints,

Mani S Kartha

lopemanc@swbell.net

2007-10-05, 7:14 pm

On Oct 5, 10:49 am, Mani S Kartha <mani.kar...@ivasystems.co.in>
wrote:
> Hi ,
>
> My application includes many windows with main components inputField
> ,action buttons and subcanvas(instead of labels,we use input fields in
> readOnly mode with some text in it).
> The complete information for building the windows comes from
> database(information like the co ordinates of window and fields,type of
> fields and the format of values that is valid for each field, labels of
> buttons and background and selection colours of buttons and fields
> ...etc). We have 7 database tables in which we keep these info(we call
> them Base tables) in which we have altogether some 50000 rows(the
> project is in the initial stage and the value can grow to the order of
> millions)
>
> The application works fine with default memory settings in VisualWorks,
> provided the database (we use the HOP framework for DB interaction.So we
> assume it is independent of the type of DB. Also we don't use any stored
> procedure/functions,now) resides in the same LAN.
>
> But when we have to deal with some centralized database systems(i mean a
> remote db server outside the LAN,common for many users) it takes too
> much time to build the forms. Most of this lag is caused by the time
> needed to fetch the form building data from DB. The application seems to
> be too dynamic (the attire of one single form can be entirely different
> in looks-if not in functionality, for different users/login)for us to
> keep them in the form of normal spec (example #windowSpec and install in
> anApplicationModel).
>
> We have been developing this application for more than 2 years and i
> think it is too late for us to change the basic design. So my doubt is
>
> Is there some better way to build the windows with much less delay
> without compromising on its dynamical advantage?
>
> The suggestions from my team was the following
> 1. Keep the Entire form building data (all data from 7 base tables)
> fetched from db(in RAM),once the application is started.
> This causes problem for us in the default memory settings even now.And
> we need to consider the possibility of the future growth in the number
> of data.
>
> 2.Collect all data for form building in Disc (with two options for it)
>
> #1 inside VisualWorks---Not certain, but we would like to try something
> like, as in the class side protocol 'interface specs'(we find some
> difficulty in that, because we are not sure whether it will be possible,
> not to loose the dynamicity of the forms and also we think it will
> increase the application size and become too big to handle easily-even
> as parcel at deployment)
> #2 outside VisualWorks---we don't know much about this option, but we
> would like to try object BOSSing
>
> and updating the information for each start up of the application (for
> changes in the window configuration, user will have to restart the
> application)
>
> Do you have some suggestions to solve these problems (better to be
> within VisualWorks)?
>
> thanks in advance for any such hints,
>
> Mani S Kartha

I don't know what your data looks like in your table, but if you have
large text or binary items like windowspecs compression would have a
significant impact on transmission time.

Mani S Kartha

2007-10-08, 4:27 am

lopemanc@swbell.net wrote:
> On Oct 5, 10:49 am, Mani S Kartha <mani.kar...@ivasystems.co.in>
> wrote:
>
> I don't know what your data looks like in your table, but if you have
> large text or binary items like windowspecs compression would have a
> significant impact on transmission time.
>
The data that we fetch are of normal format like
Integer,String,Date,Time and Float types.
Some tables have more fields and some have less(no large text or binary
items).

Steven Kelly

2007-10-08, 8:14 am

"Mani S Kartha" <mani.kartha@ivasystems.co.in> wrote in message
news:47065D22.60200@ivasystems.co.in...
> My application includes many windows...
> The complete information for building the windows comes from
> database...we have altogether some 50000 rows(the project is in the
> initial stage and the value can grow to the order of millions)
>
> The application works fine [when the DB] resides in the same LAN.
> But when we have to deal with ...a remote db server ... it takes too
> much time to build the forms.

There are four limiting factors that come to mind:
1) ping time between client and DB server vs. number of queries to DB
per window
2) bandwidth between client and DB server vs. amount of data
transferred per window
3) speed of database
4) speed of building the window from the data returned

Since a local DB is fast enough, we can rule out 3 and 4 as the
bottlenecks. My guess is that the bottleneck is 1) rather than 2),
i.e. that building one window requires multiple communications with
the database. If you can reduce that to one query, you will probably
find performance is great.

HTH,
Steve

Niall Ross

2007-10-08, 7:13 pm

Dear Mani,

"Steven Kelly" <stevek@metacase.com> wrote in message
news:iTnOi.101$w94.88@read3.inet.fi...
> "S Kartha" <mani.kartha@ivasystems.co.in> wrote in message
> news:47065D22.60200@ivasystems.co.in...
>
> There are four limiting factors that come to mind:
> 1) ping time between client and DB server vs. number of queries to DB
> per window
> 2) bandwidth between client and DB server vs. amount of data
> transferred per window
> 3) speed of database
> 4) speed of building the window from the data returned
>
> Since a local DB is fast enough, we can rule out 3 and 4 as the
> bottlenecks. My guess is that the bottleneck is 1) rather than 2),
> i.e. that building one window requires multiple communications with
> the database. If you can reduce that to one query, you will probably
> find performance is great.

This email continues Steve's suggestion in the case where we suppose that,
in your design, it is not easy to implement this single-query function on
the database, or at the lowest level where the SQL query is constructed. If
this is so, therefore you cannot immediately do what Steve suggests, I offer
a couple of suggestions.

1) If your design has a higher level where this single-message invocation
_is_ available, you could have a central image, running co-located with the
server, which talks to the remote images e.g. via OpenTalk. The remote
image could invoke the single request on the server image, which could
contruct the spec rapidly and pass it back in a single response.

2) Are you using GLORP to construct your queries? If not, you may find that
fitting GLORP would
- be a very straightforward refactoring of your system
- make it easier to implement Steve's suggestion

HTH.
Yours faithfully
Niall Ross

Mani S Kartha

2007-10-09, 8:11 am

Thanks for the replies,
Now i am aware the different aspects of the problem.
And i have got one more doubt.
Suppose if i plan to keep the application and the db in a single
location and then allow users to use the application from some remote
location can i support the idea with some 'thin client' software?
What i am specific about is, is there some 'thin client' arrangements in
VisualWorks itself?
and/or where can i get some demo version which i ca use to test my
application in this way?

Thanks in advance for any possible help

regrds,

Mani

Niall Ross wrote:
> Dear Mani,
>
> "Steven Kelly" <stevek@metacase.com> wrote in message
> news:iTnOi.101$w94.88@read3.inet.fi...
>
> This email continues Steve's suggestion in the case where we suppose that,
> in your design, it is not easy to implement this single-query function on
> the database, or at the lowest level where the SQL query is constructed. If
> this is so, therefore you cannot immediately do what Steve suggests, I offer
> a couple of suggestions.
>
> 1) If your design has a higher level where this single-message invocation
> _is_ available, you could have a central image, running co-located with the
> server, which talks to the remote images e.g. via OpenTalk. The remote
> image could invoke the single request on the server image, which could
> contruct the spec rapidly and pass it back in a single response.
>
> 2) Are you using GLORP to construct your queries? If not, you may find that
> fitting GLORP would
> - be a very straightforward refactoring of your system
> - make it easier to implement Steve's suggestion
>
> HTH.
> Yours faithfully
> Niall Ross
>
>

Sponsored Links