Results 1 to 11 of 11

Thread: Snelheidstest BDE / ADO / dbExpress

  1. #1
    May I have your votes please ....

    Ik heb een test uitgevoerd met een interfaceprogramma met de toepasselijke Griekse naam Charon. Het betreft hier duidelijk een test en geen benchmark, want het systeem is getest op een live-databank met een live-netwerk, niet helemaal representatief dus, maar desalniettemin misschien dus interessant om te publiceren. Het programma wordt opgestart met als run-time parameter het type driver BDE, ADO of dbExpress waarop hij moet draaien.

    Mode 1: remote mode. Hierbij wordt gebruik gemaakt van beperkte datasets, ordegrootte 3-5 records, er gebeuren dus veel kleine selects.

    Voor BDE : 23 minuten
    Voor ADO : 75 Minuten
    Voor dbExpress : 7 minuten

    Mode 1: locale mode. Hierbij wordt gebruik gemaakt van grote datasets, ordegrootte 500-1000 records, er gebeuren dus weinig selects, maar elke select haalt veel data op.

    Voor BDE : 239 minuten
    Voor ADO : 21 Minuten
    Voor dbExpress : 23 minuten
    De verbazing begint waar de kennis ophoudt

  2. #2
    Deze test zegt nog niet veel.

    "grote datasets", weinig selects, veel data.. Dat zijn niet echt details waar we wat mee kunnen. Wat voor snelheid heeft de PC, hoeveel geheugen. etc. We missen wat informatie.

  3. #3

  4. #4
    Hoe verklaar je het grote verschil tussen ADO en dbExpress in remote mode?

    Het zijn beide alleen maar componenten om de uiteindelijke client te benaderen, hoe verklaar je dat de client in het geval van dbExpress de gegevens in 7 minuten ophaalt en bij ADO in 71 minuten?
    Marcel

  5. #5
    Senior Member walterheck's Avatar
    Join Date
    Oct 2001
    Location
    Belo Horizonte, Brasil
    Posts
    4,212
    Welke database gaat het om?

    Dat grote verschil kan komen doordat er door ADO allerlei dingen worden opgehaald om de metadata tevoorschijn te toveren. Als je de LockType op ltReadOnly zet, gaat het alweer een stuk harder.

    Ik denk persoonlijk dat een betere test zou zijn om voor iedere mogelijkheid zo ver mogelijk te optimaliseren, dan krijg je ook resultaten die je in de praktijk kan gebruiken...
    Nee, de Romeinen spraken geen ISO-8859-1 LATIN

  6. #6
    Maar hoe optimaliseerd je dan. Je geeft al aan dat met het instellen van LockType op ltReadOnly al een flinke winst te halen is, maar dat is in de praktijk misschien niet altijd mogelijk. Je zal dan verschillende praktijksituaties moeten schetsen, zoals het ophalen van een selectie van enkele kolommen, ophalen van alle kolommen, updaten van hele tabel etc. Naar aanleiding daarvan kun je dan bepalen welke database de beste all-round score heeft, of het best geschikt is als je een specifiek doel hebt.
    1+1=b

  7. #7
    Welke database gaat het om?
    SQL Server 2000 EE SP4

    Je zal dan verschillende praktijksituaties moeten schetsen
    Ik heb vandaag nagezien hoe het programma werkt:

    Het programma is een interface-programma tussen twee verschillende databases, (voor de gelegenheid uitgevoerd op de zelfde database) tussen een ERP-systeem en een CIM-systeem.

    Van op een remote server wordt er data gehaald ( altijd in een read-only dataset ), deze wordt verwerkt, getest en ingevoegd in een andere databank. Insert en updates gebeuren altijd in een afzonderlijke Query.

    In de 'remote mode' gebeuren de selects record per record. Er wordt telkens één record opgehaald, verwerkt, gecontroleerd en in de andere database ingevoegd.

    In de locale mode worden selects uitgevoerd van 1000 records, verwerkt en toegevoegd in de databank.

    Het databasecomponent is een component waarbij je at runtime kunt aangeven of het op ADO, BDE of dbExpress moet draaien.

    Indien jullie ideeën hebben om te optimalisen, dan wil ik dat best wel eens proberen.

    Nu, zoals ik al gezegd heb, het is een niet-representatieve test, geen benchmark.
    De verbazing begint waar de kennis ophoudt

  8. #8
    Je geeft al aan dat met het instellen van LockType op ltReadOnly al een flinke winst te halen is, maar dat is in de praktijk misschien niet altijd mogelijk
    In de eerste post wordt geschreven dat er selects worden gedaan, er stond nergens iets van een update. Bij een select haal je gegevens op en kun je dus makkelijker met itReadOnly testen.

    Ik ben met je eens dat het niet altijd kan maar zoals hierboven stond beschreven is het wel een logische aanname om hem op Read-Only te testen. Over het algemeen geldt dat als je echt voor performance je wilt gaan je gewoon per situatie dingen moet testen en niet een algemene test pakken die (misschien wel) toevallig ergens sneller is.

    Maak altijd een test vanuit je eigen situatie, daarbij kun je natuurlijk wel gebruik maken van eerder uitgevoerde tests.

  9. #9
    Je geeft al aan dat met het instellen van LockType op ltReadOnly al een flinke winst te halen is, maar dat is in de praktijk misschien niet altijd mogelijk.
    Ik heb het nagezien, het LockType voor het ADO-component stond op ltReadOnly, wat mij logisch lijkt, want de hier gebruikte datasets zijn altijd allemaal read-only.

    Voor de Dataset-clients wordt geen gebruik gemaakt van een TClientDataset, maar van een ander type 'light' read-only memory-dataset component.
    In remote mode wordt bij dbExpress geen gebruikt gemaakt van Client-Datasets, maar wordt alles uni-directioneel verwerkt
    De verbazing begint waar de kennis ophoudt

  10. #10
    senior member PeterVercruysse's Avatar
    Join Date
    Nov 2006
    Location
    Rijsel
    Posts
    1,608
    Waarom doen we allemaal eens niet dezelfde test met hetzelfde programma? Ik wel zelf wel zo'n programma ineensknutselen. Ik denk dat we veel gaan bijleren.
    Gras groeit niet sneller door er aan te trekken

  11. #11
    Ik denk dat dat alleen zin heeft als je de test op dezelfde hardware draait. Hardware bepaalt denk ik voor een veel groter deel de performance dan software.

    Voor zover de databases vrij verkrijgbaar zijn is dat niet zo'n probleem natuurlijk. Richt een PC in met de databases die je wilt testen en ga testen. Als je ook de betaalde versies van databases wilt testen wordt het wat lastiger, dan ben je afhankelijk van eventuele trials.
    Marcel

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •