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 |
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" <[hidden email]> wrote in message > news:iTnOi.101$[hidden email]... >> "S Kartha" <[hidden email]> wrote in message >> news:[hidden email]... >>> 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. > > 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 > > |
Free forum by Nabble | Edit this page |