SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 5 of 5
  1. #1
    Junior Member
    Join Date
    May 2003
    Location
    Melbourne, Australia
    Posts
    16
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    ODBC / COM for Database Test

    My client wants a database load test, based on activity generated from Thick Clients running OLE DB connections to a MS SQL Server Clustered Database - which means that I need to use the COM/DCOM protocol for VUGen.

    However, they only have an ODBC licence for their controller.

    Question: What are the risks of running a test based on ODBC connections (a simple change to the UDL file) using their existing license over generating load based on the OLE DB connections?

    btw: I am not comfortable with such an approach (using odbc) as I don't understand the implications of the different protocol on the performance of the database.
    Paul McLean
    email: pmclean at loadtest.com.au
    www.loadtest.com.au

  2. #2
    Moderator
    Join Date
    Aug 2001
    Location
    NC
    Posts
    6,018
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: ODBC / COM for Database Test

    I posed this very question to a couple of friends one evening over some beers and they provided some very interesting insight. Fortunately these friends all worked for Microsoft and supported SQL Server, so I consider their word a qualified expert opinion.

    Unlike ODBC, which exists as a layer on top of DBLIB, OLEDB uses a different communication method to the SQL Server database. OLEDB is apparently not layered on top of ODBC as ODBC is layered on top of lower level APIs, like DbLib. From what I was able to gather OLEDB employs a modified DCOM model to extract data from COM objects residing on the server. Their perspective (My then beer-laden buddies) is that OLEDB rocks and performs better than ODBC or DBLIB. My thought, hmmmmm, sounds suspicious since at some level (the COM object residing on the server) some sort of native database API call has to be made via DBLIB or it's equivalent...unless Microsoft has taken liberties with their own COM objects to allow them to "speak" directly to the database engine. Still, DBLIB connections on the local named pipe on the server are very fast, so the COM objects could be using this.

    I have not been able to hook up a protocol analyzer to verify this information that no DBLIB information is actually passed within an OLEDB connection, so accept this information with "qualified" grain of salt. So the danger of using ODBC, assuming the above information is true, would be that you are exercising a communication mechanism which is not at all employed by your application and also assuming the information about the efficiency of OLEDB is correct you may find a lower level of scalability with DBLIB/ODBC versus the actual communication mechanism of the app.

    If you hook up a "sniffer" and do actually find a DBLIB stream, then you can discard everything you have read above and go ahead and use an ODBC virtual user since it will in turn call dblib and generate a dblib communication stream between client and server. If no DBLIB in the "sniffed" stream, then you really need to consider using the same communication mechanism as the actual client application.

    As far as the license issue goes, it's up to product management to assess the risk of not performance testing the application. You might want to inquire about a license for Virtual User Days (VUDS), which would allow you to take advantage of a specific number of virtual users for a twenty-four hour period. After all, even absent the license to execute DCOM virtual users in the controller, you can still develop your scripts in VUGEN and build your load test model in the controller. After all of that is complete then you can hook up your VUD license and perform your testing.

    Regards,

    [ 06-09-2003, 10:50 AM: Message edited by: jpulley3 ]
    James Pulley

    Replace ineffective offshore contracts, LoadRunnerByTheHour. Starting @ $19.95/hr USD.

    Put us to the test, skilled expertise is less expensive than you might imagine.

    Twitter: @LoadRunnerBTH @PerfBytes

  3. #3
    Senior Member
    Join Date
    Jul 1999
    Location
    Sweden/Israel/US
    Posts
    388
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: ODBC / COM for Database Test

    There's certanly a different comm protocol and connection methods. However, from the DB point of view we're still talking about same SQL statements.

    Thus, assuming that both OLEDB and ODBC interfaces are scalable enough for your amount of vusers (in fact, these interfaces were build with scalability in mind) you can still apply a descent load to test and tune your DB.

    So, if you break up your test to 2 parts:
    * connection handling test - simple DCOM scripts
    * DB test - can be acheived by ODBC

  4. #4
    Junior Member
    Join Date
    May 2003
    Location
    Melbourne, Australia
    Posts
    16
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: ODBC / COM for Database Test

    So I might as well do the entire test with DCOM scripts, especially as I don't want to make any assumptions regarding the scalability of the implementation of the OLEDB interface.
    Paul McLean
    email: pmclean at loadtest.com.au
    www.loadtest.com.au

  5. #5
    Member
    Join Date
    Apr 2003
    Location
    Fullerton, CA, USA
    Posts
    87
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: ODBC / COM for Database Test

    Hey Paul
    I havent worked with ODBC protocol in Load runner but have worked on COM/DCOM protocol.

    The way i know is that both ODBC and OLEDB use different way to connect to the underlying database.
    ODBC uses the DSN to connect to the database and OLEDB use the COM technology to connect to the database.
    But that is upto the point to get the Provider name. In the case of ODBC, the DSN string and the Machine name entry tells us the database machine to connect whereas in case of OLEDB it is the ProviderName that tells us the database server name.
    In any case we can say that OLEDB in turn uses the ODBC protocol for database connections.

    In your case i feel that you can defn go ahead and use the ODBC protocol for the load test.
    But the fact to keep in mind while doing the same is that OLEDB connection time to the database is just around 18ms as compared to 32ms of that of ODBC connectivity, for SQL server.

    Pls let me know how did your load test go.
    Thanks, mh

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 10.00%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 12:14 AM.

Copyright BetaSoft Inc.