ASP code vs COM Components

Discussion in 'ASP General' started by CJM, Sep 2, 2003.

  1. CJM

    CJM Guest

    I realise this question has come up in some form or other many times in the
    past, but indulge me, please.

    I've just been reviewing a COM component (VB6) that I wrote a while ago to
    record when and where 404 errors occur; each error is logged in a DB along
    with supporting information.

    Looking at it now, I'm wondering why I chose a COM component rather than
    just an ASP page. There is not that much code involved, so I could easily
    have expanded the ASP page that calls the DLL to do the whole job....

    COM Component:
    Generally perform faster than an ASP page, but there is an overhead
    associated with creating a new object in the calling ASP page, so more
    suited to more intense apps that dont require user-interaction. Also keeps
    code private of course.

    ASP:
    Keeping you code in an ASP page is often more efficient for smaller jobs,
    where the cost of creating a COM object outweighs the potential performance
    gain. Also prefered for tasks that require frequent user interaction. Code
    remains public (to those who have access to server).

    This is what prompted my question: At what point, does it become worthwhile
    to go for a COM component as opposed to an ASP page? Is there that much
    difference in it?

    Are perceptions of the issues fairly accurate?

    I've updated the DLL in question - it was a bit of a ball ache: modify code
    & compile, reset IIS, then copy DLL to server and re-register. I know my DLL
    in this example doesnt do much, and I'm certain that modifying and copying
    ASP pages would be simple & efficient, but at what point does it pay to use
    a DLL?

    Thanks

    Chris
    CJM, Sep 2, 2003
    #1
    1. Advertising

  2. CJM

    Bob Barrows Guest

    CJM wrote:
    > COM Component:
    > Generally perform faster than an ASP page, but there is an overhead
    > associated with creating a new object in the calling ASP page, so more
    > suited to more intense apps that dont require user-interaction. Also
    > keeps code private of course.


    No argument with the security factor. However, performance has been shown to
    be better with straight ASP. See here:
    http://msdn.microsoft.com/library/en-us/dnnile/html/docu2kbench.asp
    Bob Barrows, Sep 2, 2003
    #2
    1. Advertising

  3. Anthony J Biondo Jr wrote:
    >
    > Hi Chris:
    >
    > The way I look at it, if you have allot of processing and logic you need to
    > perform it should be done in COM, because of the sheer fact that each time a
    > person hits the page it does not need to be recompiled.


    An ASP page is NOT recompiled every time a person hits it!

    It is only compiled for the first request; thereafter the pre-compiled
    pcode (bytecode) is cached in IIS memory so all subsequent requests can
    be executed immediately. For a description of the compilation and
    execution process see Appendix 3 of
    http://www.microsoft.com/technet/tr...rodtechnol/iis/maintain/optimize/iis5tune.asp

    To see a sample of the compiled bytecode see
    http://groups.google.com/groups?q= ...ng=r&selm=&rnum=2

    > I guess everyone
    > has their own perception of what "allot of processing" would be. I know
    > that we use COM for the web where we expect allot of hits and have critical
    > functions that need to happen. User Authentication, Logging, Inquiries to
    > other data stores.


    In the light of how IIS and ASP *really* work, your methodology should
    be re-evaluated. COM components will enhance performance only if the
    task is *highly* CPU-intensive. I/O bound tasks (e.g., "User
    Authentication, Logging, Inquiries to other data stores") do not qualify
    and will perform better when done in ASP script. Before components pay
    off performance-wise, you must have a *lot* of compute-bound code:

    "Rule of thumb: unless there are at least 100 lines of script and some
    big loops in that script, it's probably not worth thinking about
    translating that page into a component."
    Alex Homer, Dave Sussman, Brian Francis
    page 1042,
    "Active Server Pages 3.0"
    (Wrox Press Ltd., 1999)

    See http://groups.google.com/groups?oi=djq&selm=an_558802478 for more
    details.
    Good Luck,
    Michael D. Kersey
    Michael D. Kersey, Sep 2, 2003
    #3
  4. "Michael D. Kersey" wrote:
    <snipped>
    > It is only compiled for the first request; thereafter the pre-compiled
    > pcode (bytecode) is cached in IIS memory so all subsequent requests can
    > be executed immediately. For a description of the compilation and
    > execution process see Appendix 3 of
    > http://www.microsoft.com/technet/tr...rodtechnol/iis/maintain/optimize/iis5tune.asp


    Apologies, the above URL is unduly nested. The correct URL is
    http://www.microsoft.com/technet/prodtechnol/iis/iis5/maintain/optimize/iis5tune.asp?frame=true

    > Good Luck,
    > Michael D. Kersey
    Michael D. Kersey, Sep 2, 2003
    #4
  5. CJM

    Tamara Guest

    Perfect example is when your dll implements business logic
    needed on both Web server and application(non-Web) server.
    You can not share your asp code between two.

    Another case would be a number-crunching task that
    consumes CPU cycles. You are better off with compiled
    code.

    ANother one: ASP does not (at least explicitly) support
    data types. You do not want to deal with ASP when the data
    type matters (calculations or conversions). It can play
    nasty tricks on you unless you deeply understand the
    underlying data types in ASP.

    Last one: Use of 3-d party libraries. You might be better
    of with a wrapper around the library for the above reason
    of data conversions.

    Good luck.


    Makes no sense for a 3-liner.



    >-----Original Message-----
    >I realise this question has come up in some form or other

    many times in the
    >past, but indulge me, please.
    >
    >I've just been reviewing a COM component (VB6) that I

    wrote a while ago to
    >record when and where 404 errors occur; each error is

    logged in a DB along
    >with supporting information.
    >
    >Looking at it now, I'm wondering why I chose a COM

    component rather than
    >just an ASP page. There is not that much code involved,

    so I could easily
    >have expanded the ASP page that calls the DLL to do the

    whole job....
    >
    >COM Component:
    >Generally perform faster than an ASP page, but there is

    an overhead
    >associated with creating a new object in the calling ASP

    page, so more
    >suited to more intense apps that dont require user-

    interaction. Also keeps
    >code private of course.
    >
    >ASP:
    >Keeping you code in an ASP page is often more efficient

    for smaller jobs,
    >where the cost of creating a COM object outweighs the

    potential performance
    >gain. Also prefered for tasks that require frequent user

    interaction. Code
    >remains public (to those who have access to server).
    >
    >This is what prompted my question: At what point, does it

    become worthwhile
    >to go for a COM component as opposed to an ASP page? Is

    there that much
    >difference in it?
    >
    >Are perceptions of the issues fairly accurate?
    >
    >I've updated the DLL in question - it was a bit of a ball

    ache: modify code
    >& compile, reset IIS, then copy DLL to server and re-

    register. I know my DLL
    >in this example doesnt do much, and I'm certain that

    modifying and copying
    >ASP pages would be simple & efficient, but at what point

    does it pay to use
    >a DLL?
    >
    >Thanks
    >
    >Chris
    >
    >
    >.
    >
    Tamara, Sep 2, 2003
    #5
  6. CJM

    CJM Guest

    This is this is my understanding also...

    And you have essentially provided a good rule of thumb:

    If the task is CPU-intensive (eg > 100 lines of code) then a COM solution
    may offer some benefits, otherwise, an ASP-only solution is likely to be the
    best result.

    ...other conserations permitting....

    It's what I suspected, but it's good to hear it again.

    Thanks

    "Michael D. Kersey" <> wrote in message
    news:...
    > Anthony J Biondo Jr wrote:
    > >
    > > Hi Chris:
    > >
    > > The way I look at it, if you have allot of processing and logic you need

    to
    > > perform it should be done in COM, because of the sheer fact that each

    time a
    > > person hits the page it does not need to be recompiled.

    >
    > An ASP page is NOT recompiled every time a person hits it!
    >
    > It is only compiled for the first request; thereafter the pre-compiled
    > pcode (bytecode) is cached in IIS memory so all subsequent requests can
    > be executed immediately. For a description of the compilation and
    > execution process see Appendix 3 of
    >

    http://www.microsoft.com/technet/tr...rodtechnol/iis/maintain/optimize/iis5tune.asp
    >
    > To see a sample of the compiled bytecode see
    >

    http://groups.google.com/groups?q= ...ng=r&selm=&rnum=2
    >
    > > I guess everyone
    > > has their own perception of what "allot of processing" would be. I know
    > > that we use COM for the web where we expect allot of hits and have

    critical
    > > functions that need to happen. User Authentication, Logging, Inquiries

    to
    > > other data stores.

    >
    > In the light of how IIS and ASP *really* work, your methodology should
    > be re-evaluated. COM components will enhance performance only if the
    > task is *highly* CPU-intensive. I/O bound tasks (e.g., "User
    > Authentication, Logging, Inquiries to other data stores") do not qualify
    > and will perform better when done in ASP script. Before components pay
    > off performance-wise, you must have a *lot* of compute-bound code:
    >
    > "Rule of thumb: unless there are at least 100 lines of script and some
    > big loops in that script, it's probably not worth thinking about
    > translating that page into a component."
    > Alex Homer, Dave Sussman, Brian Francis
    > page 1042,
    > "Active Server Pages 3.0"
    > (Wrox Press Ltd., 1999)
    >
    > See http://groups.google.com/groups?oi=djq&selm=an_558802478 for more
    > details.
    > Good Luck,
    > Michael D. Kersey
    CJM, Sep 3, 2003
    #6
  7. CJM

    CJM Guest

    "Tamara" <> wrote in message
    news:02b701c37193$fdf021d0$...

    >> ANother one: ASP does not (at least explicitly) support

    > data types. You do not want to deal with ASP when the data
    > type matters (calculations or conversions). It can play
    > nasty tricks on you unless you deeply understand the
    > underlying data types in ASP.
    >
    > Last one: Use of 3-d party libraries. You might be better
    > of with a wrapper around the library for the above reason
    > of data conversions.


    Yes, its a fair point about type-conversion...

    Thanks
    CJM, Sep 3, 2003
    #7
  8. CJM

    CJM Guest

    That's a good link Bob.

    Takes a bit of reading but very 'enlightening'!

    Thanks


    "Bob Barrows" <> wrote in message
    news:u%...
    > CJM wrote:
    > > COM Component:
    > > Generally perform faster than an ASP page, but there is an overhead
    > > associated with creating a new object in the calling ASP page, so more
    > > suited to more intense apps that dont require user-interaction. Also
    > > keeps code private of course.

    >
    > No argument with the security factor. However, performance has been shown

    to
    > be better with straight ASP. See here:
    > http://msdn.microsoft.com/library/en-us/dnnile/html/docu2kbench.asp
    >
    >
    CJM, Sep 3, 2003
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alex
    Replies:
    3
    Views:
    1,477
    Alvin Bruney
    Dec 2, 2003
  2. Wayfarer
    Replies:
    1
    Views:
    2,628
    =?Utf-8?B?QmhhcmF0IEJpeWFuaQ==?=
    Jul 31, 2004
  3. Mickey Segal
    Replies:
    0
    Views:
    856
    Mickey Segal
    Feb 2, 2004
  4. mf_sina

    Placing webwiz ASP-made site components in ASP pages

    mf_sina, Feb 13, 2005, in forum: ASP .Net Building Controls
    Replies:
    0
    Views:
    211
    mf_sina
    Feb 13, 2005
  5. mf_sina

    Placing webwiz ASP-made site components in ASP pages

    mf_sina, Feb 13, 2005, in forum: ASP .Net Web Controls
    Replies:
    0
    Views:
    140
    mf_sina
    Feb 13, 2005
Loading...

Share This Page