OO overhead in ASP


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 5 of 5

Thread: OO overhead in ASP

  1. #1
    Tom Guest

    OO overhead in ASP

    I have been developing in VB since 3.0 but am new to ASP development. I am
    taking the over the debugging and cleanup of an ASP project.

    The ASP page creates VB COM objects for accessing data in a SQL Server
    database. The details of SQL Server are hidden from ASP so that the back
    end could easily be changed to another database platform. However, to
    accomplish this, the original developer builds field definitions for ALL
    fields in the table (with field names,, data type, etc) each time the COM
    object is created. The ASP page simply passes in a list of fields and a
    conditional for data retrieval.

    I am concerned with the overhead of this approach. For every page hit, ASP
    creates, uses, and destroys these COM objects. I am considering migrating
    to a simpler approach; One option I'm considering is where the COM objects
    determine field definitions as needed. The other option is to move these
    table definition/SQL statement builder objects to application scope so that
    they are only created once. However, I'm sure there are threading issues to
    consider here.

    Anyone found any general guidelines in this area through practice or know of
    some articles on this subject?



  2. #2
    Trey Guest

    Re: OO overhead in ASP


    Tom:

    Why don't you build the database with all the tables and fields that are
    needed once.

    Then write your COM object as a wrapper around that database, to shield the
    ASP pages from its complexities. The COM object will contain the business
    rules. Use register your COM object with MTS.

    Yes the ASP page will still "creates, uses, and destroys" the COM objects,
    but that is normal and expected. HTTP, by nature, is stateless MTS will
    "cache" the objects and help keep the memory clean. This will help promote
    scalability. (MTS on one Server, IIS on a second server, Database on
    a Third, etc...)

    If the database needs to be changed from SQL Server to DB2, you just need
    to change the COM object to recognise the new database (with the same tables,
    fields, and data). The ASP pages will not need to be changed.

    HTH


    "Tom" <nospam@hotmail.com> wrote:
    >I have been developing in VB since 3.0 but am new to ASP development. I

    am
    >taking the over the debugging and cleanup of an ASP project.
    >
    >The ASP page creates VB COM objects for accessing data in a SQL Server
    >database. The details of SQL Server are hidden from ASP so that the back
    >end could easily be changed to another database platform. However, to
    >accomplish this, the original developer builds field definitions for ALL
    >fields in the table (with field names,, data type, etc) each time the COM
    >object is created. The ASP page simply passes in a list of fields and a
    >conditional for data retrieval.
    >
    >I am concerned with the overhead of this approach. For every page hit,

    ASP
    >creates, uses, and destroys these COM objects. I am considering migrating
    >to a simpler approach; One option I'm considering is where the COM objects
    >determine field definitions as needed. The other option is to move these
    >table definition/SQL statement builder objects to application scope so that
    >they are only created once. However, I'm sure there are threading issues

    to
    >consider here.
    >
    >Anyone found any general guidelines in this area through practice or know

    of
    >some articles on this subject?
    >
    >



  3. #3
    Tom Guest

    Re: OO overhead in ASP

    Trey,

    The arrangement you describe is basically what already exists. The ASP
    pages have little to no knowledge of the database, just knows some of the
    field names when asking for some data. All the SQL server specifics are
    isolated in the COM objects.

    However, the site does not use MTS at this point. Therefore, we're not
    getting any benefit from object caching and are creating all objects from
    scratch when they are needed. The database table "objects" have field
    definition objects for every field in the table that are created in the
    table object's Class_Initialize method.

    MTS may be the way to go; I haven't researched it much. How difficult is it
    to switch to for a running site? You mention running MTS on a separate
    server. At what point does this help performance since you have to marshal
    data across machines?





    "Trey" <nospamtcollier@vimata.comnospam> wrote in message
    news:3b2e63a0$1@news.devx.com...
    >
    > Tom:
    >
    > Why don't you build the database with all the tables and fields that are
    > needed once.
    >
    > Then write your COM object as a wrapper around that database, to shield

    the
    > ASP pages from its complexities. The COM object will contain the

    business
    > rules. Use register your COM object with MTS.
    >
    > Yes the ASP page will still "creates, uses, and destroys" the COM objects,
    > but that is normal and expected. HTTP, by nature, is stateless MTS will
    > "cache" the objects and help keep the memory clean. This will help

    promote
    > scalability. (MTS on one Server, IIS on a second server, Database on
    > a Third, etc...)
    >
    > If the database needs to be changed from SQL Server to DB2, you just need
    > to change the COM object to recognise the new database (with the same

    tables,
    > fields, and data). The ASP pages will not need to be changed.
    >
    > HTH
    >
    >
    > "Tom" <nospam@hotmail.com> wrote:
    > >I have been developing in VB since 3.0 but am new to ASP development. I

    > am
    > >taking the over the debugging and cleanup of an ASP project.
    > >
    > >The ASP page creates VB COM objects for accessing data in a SQL Server
    > >database. The details of SQL Server are hidden from ASP so that the back
    > >end could easily be changed to another database platform. However, to
    > >accomplish this, the original developer builds field definitions for ALL
    > >fields in the table (with field names,, data type, etc) each time the COM
    > >object is created. The ASP page simply passes in a list of fields and a
    > >conditional for data retrieval.
    > >
    > >I am concerned with the overhead of this approach. For every page hit,

    > ASP
    > >creates, uses, and destroys these COM objects. I am considering

    migrating
    > >to a simpler approach; One option I'm considering is where the COM

    objects
    > >determine field definitions as needed. The other option is to move these
    > >table definition/SQL statement builder objects to application scope so

    that
    > >they are only created once. However, I'm sure there are threading issues

    > to
    > >consider here.
    > >
    > >Anyone found any general guidelines in this area through practice or know

    > of
    > >some articles on this subject?
    > >
    > >

    >




  4. #4
    Ralph Carrasquillo Guest

    Re: OO overhead in ASP


    Trey,
    It's not entirely necessary to separate MTS on another server it all depends
    on your sys usage. Another way is to have MTS running on your IIS server.
    I believe Tom is right in pointing you in the com/mts direction migrating
    from com to mts is not significant. There are alternative ways of sending
    data across objects reduce overhead my favorite is in using XML. I think
    the real overhead is in the creation of mult com objs that are not being
    shared across by multiple request.

    Ralph

    "Tom" <nospam@hotmail.com> wrote:
    >Trey,
    >
    >The arrangement you describe is basically what already exists. The ASP
    >pages have little to no knowledge of the database, just knows some of the
    >field names when asking for some data. All the SQL server specifics are
    >isolated in the COM objects.
    >
    >However, the site does not use MTS at this point. Therefore, we're not
    >getting any benefit from object caching and are creating all objects from
    >scratch when they are needed. The database table "objects" have field
    >definition objects for every field in the table that are created in the
    >table object's Class_Initialize method.
    >
    >MTS may be the way to go; I haven't researched it much. How difficult is

    it
    >to switch to for a running site? You mention running MTS on a separate
    >server. At what point does this help performance since you have to marshal
    >data across machines?
    >
    >
    >
    >
    >
    >"Trey" <nospamtcollier@vimata.comnospam> wrote in message
    >news:3b2e63a0$1@news.devx.com...
    >>
    >> Tom:
    >>
    >> Why don't you build the database with all the tables and fields that are
    >> needed once.
    >>
    >> Then write your COM object as a wrapper around that database, to shield

    >the
    >> ASP pages from its complexities. The COM object will contain the

    >business
    >> rules. Use register your COM object with MTS.
    >>
    >> Yes the ASP page will still "creates, uses, and destroys" the COM objects,
    >> but that is normal and expected. HTTP, by nature, is stateless MTS

    will
    >> "cache" the objects and help keep the memory clean. This will help

    >promote
    >> scalability. (MTS on one Server, IIS on a second server, Database

    on
    >> a Third, etc...)
    >>
    >> If the database needs to be changed from SQL Server to DB2, you just need
    >> to change the COM object to recognise the new database (with the same

    >tables,
    >> fields, and data). The ASP pages will not need to be changed.
    >>
    >> HTH
    >>
    >>
    >> "Tom" <nospam@hotmail.com> wrote:
    >> >I have been developing in VB since 3.0 but am new to ASP development.

    I
    >> am
    >> >taking the over the debugging and cleanup of an ASP project.
    >> >
    >> >The ASP page creates VB COM objects for accessing data in a SQL Server
    >> >database. The details of SQL Server are hidden from ASP so that the

    back
    >> >end could easily be changed to another database platform. However, to
    >> >accomplish this, the original developer builds field definitions for

    ALL
    >> >fields in the table (with field names,, data type, etc) each time the

    COM
    >> >object is created. The ASP page simply passes in a list of fields and

    a
    >> >conditional for data retrieval.
    >> >
    >> >I am concerned with the overhead of this approach. For every page hit,

    >> ASP
    >> >creates, uses, and destroys these COM objects. I am considering

    >migrating
    >> >to a simpler approach; One option I'm considering is where the COM

    >objects
    >> >determine field definitions as needed. The other option is to move these
    >> >table definition/SQL statement builder objects to application scope so

    >that
    >> >they are only created once. However, I'm sure there are threading issues

    >> to
    >> >consider here.
    >> >
    >> >Anyone found any general guidelines in this area through practice or

    know
    >> of
    >> >some articles on this subject?
    >> >
    >> >

    >>

    >
    >



  5. #5
    Rodney Kendall Guest

    Re: OO overhead in ASP

    For your application, there is no code changes whatsoever when you migrate
    to MTS, unless you are using transactions around your objects - something
    you are most likely not going to need unless you are performing a set of
    financial transactions or other transactions that must all either succeed or
    fail across several objects. To your ASP pages, the Server.CreateObject
    call is still used, you merely need to drag and drop your objects from
    Windows Explorer to a package you create within MTS. See Microsoft for
    information about configuring MTS and creating packages.

    Since you are not currently using MTS, let me STRONGLY suggest that you do
    move your objects to MTS. MTS does cache your objects and allows for much
    faster object instantiation (after the first load of the object into memory)
    in addition to isolating your objects within packages in MTS instead of the
    IIS address space.

    Although it is possible to run MTS on a separate server, it does degrade
    performance due to marshalling the objects across the network.

    Tom <nospam@hotmail.com> wrote in message news:3b2fa680@news.devx.com...
    > Trey,
    >
    > The arrangement you describe is basically what already exists. The ASP
    > pages have little to no knowledge of the database, just knows some of the
    > field names when asking for some data. All the SQL server specifics are
    > isolated in the COM objects.
    >
    > However, the site does not use MTS at this point. Therefore, we're not
    > getting any benefit from object caching and are creating all objects from
    > scratch when they are needed. The database table "objects" have field
    > definition objects for every field in the table that are created in the
    > table object's Class_Initialize method.
    >
    > MTS may be the way to go; I haven't researched it much. How difficult is

    it
    > to switch to for a running site? You mention running MTS on a separate
    > server. At what point does this help performance since you have to

    marshal
    > data across machines?
    >
    >
    >
    >
    >
    > "Trey" <nospamtcollier@vimata.comnospam> wrote in message
    > news:3b2e63a0$1@news.devx.com...
    > >
    > > Tom:
    > >
    > > Why don't you build the database with all the tables and fields that are
    > > needed once.
    > >
    > > Then write your COM object as a wrapper around that database, to shield

    > the
    > > ASP pages from its complexities. The COM object will contain the

    > business
    > > rules. Use register your COM object with MTS.
    > >
    > > Yes the ASP page will still "creates, uses, and destroys" the COM

    objects,
    > > but that is normal and expected. HTTP, by nature, is stateless MTS

    will
    > > "cache" the objects and help keep the memory clean. This will help

    > promote
    > > scalability. (MTS on one Server, IIS on a second server, Database on
    > > a Third, etc...)
    > >
    > > If the database needs to be changed from SQL Server to DB2, you just

    need
    > > to change the COM object to recognise the new database (with the same

    > tables,
    > > fields, and data). The ASP pages will not need to be changed.
    > >
    > > HTH
    > >
    > >
    > > "Tom" <nospam@hotmail.com> wrote:
    > > >I have been developing in VB since 3.0 but am new to ASP development.

    I
    > > am
    > > >taking the over the debugging and cleanup of an ASP project.
    > > >
    > > >The ASP page creates VB COM objects for accessing data in a SQL Server
    > > >database. The details of SQL Server are hidden from ASP so that the

    back
    > > >end could easily be changed to another database platform. However, to
    > > >accomplish this, the original developer builds field definitions for

    ALL
    > > >fields in the table (with field names,, data type, etc) each time the

    COM
    > > >object is created. The ASP page simply passes in a list of fields and

    a
    > > >conditional for data retrieval.
    > > >
    > > >I am concerned with the overhead of this approach. For every page hit,

    > > ASP
    > > >creates, uses, and destroys these COM objects. I am considering

    > migrating
    > > >to a simpler approach; One option I'm considering is where the COM

    > objects
    > > >determine field definitions as needed. The other option is to move

    these
    > > >table definition/SQL statement builder objects to application scope so

    > that
    > > >they are only created once. However, I'm sure there are threading

    issues
    > > to
    > > >consider here.
    > > >
    > > >Anyone found any general guidelines in this area through practice or

    know
    > > of
    > > >some articles on this subject?
    > > >
    > > >

    > >

    >
    >




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center