ASP Classic On IIS Takes 31 Seconds To Execute Each mySQL Script











up vote
1
down vote

favorite












My development system has suddenly been afflicted with this weird problem where every single SQL script takes exactly 31 seconds to execute on my Classic ASP site's connection to a mySQL (MariaDB) database.



Connecting to either a local copy of the DB running off my system or even my live DB being hosted at a web host, it all the same.
Everything from a simple



adoconn.Execute("SELECT * FROM users;")


or even



adoconn.Execute("SET sql_mode''")


would take 31 seconds to execute. Each!



I can safely rule out any problems with the DB as connecting to it and running scripts from DBeaver shows no problems at all. The results come back instantly.
I can also rule out network problems as the local DB and the hosted DB have the same results and I have used WireShark to confirm that the MySQL packets are being responded to almost immediately from the hosted DB.



Debug stepping through my ASP code, everything runs fine right up until the .Execute() at which it will take 31 seconds, regardless of how complex the script is.



The strangest thing is, this problem just came out of the blue; when my system was powered down, disconnected and untouched over the weekend. No updates, installations or changes were done to the system. Friday I was doing my dev work perfectly fine. But Monday morning when I powered it back up, the DB connections there are stuffed.



I've already tried configuring mySQL to use the "skip-name-resolve" and "bind-address = ::" settings.
I have tried rebuilding my IIS websites and reinstalling IIS itself.
I've also reinstalled mySQL ODBC drivers on my system to no avail.



What is going on here?










share|improve this question


























    up vote
    1
    down vote

    favorite












    My development system has suddenly been afflicted with this weird problem where every single SQL script takes exactly 31 seconds to execute on my Classic ASP site's connection to a mySQL (MariaDB) database.



    Connecting to either a local copy of the DB running off my system or even my live DB being hosted at a web host, it all the same.
    Everything from a simple



    adoconn.Execute("SELECT * FROM users;")


    or even



    adoconn.Execute("SET sql_mode''")


    would take 31 seconds to execute. Each!



    I can safely rule out any problems with the DB as connecting to it and running scripts from DBeaver shows no problems at all. The results come back instantly.
    I can also rule out network problems as the local DB and the hosted DB have the same results and I have used WireShark to confirm that the MySQL packets are being responded to almost immediately from the hosted DB.



    Debug stepping through my ASP code, everything runs fine right up until the .Execute() at which it will take 31 seconds, regardless of how complex the script is.



    The strangest thing is, this problem just came out of the blue; when my system was powered down, disconnected and untouched over the weekend. No updates, installations or changes were done to the system. Friday I was doing my dev work perfectly fine. But Monday morning when I powered it back up, the DB connections there are stuffed.



    I've already tried configuring mySQL to use the "skip-name-resolve" and "bind-address = ::" settings.
    I have tried rebuilding my IIS websites and reinstalling IIS itself.
    I've also reinstalled mySQL ODBC drivers on my system to no avail.



    What is going on here?










    share|improve this question
























      up vote
      1
      down vote

      favorite









      up vote
      1
      down vote

      favorite











      My development system has suddenly been afflicted with this weird problem where every single SQL script takes exactly 31 seconds to execute on my Classic ASP site's connection to a mySQL (MariaDB) database.



      Connecting to either a local copy of the DB running off my system or even my live DB being hosted at a web host, it all the same.
      Everything from a simple



      adoconn.Execute("SELECT * FROM users;")


      or even



      adoconn.Execute("SET sql_mode''")


      would take 31 seconds to execute. Each!



      I can safely rule out any problems with the DB as connecting to it and running scripts from DBeaver shows no problems at all. The results come back instantly.
      I can also rule out network problems as the local DB and the hosted DB have the same results and I have used WireShark to confirm that the MySQL packets are being responded to almost immediately from the hosted DB.



      Debug stepping through my ASP code, everything runs fine right up until the .Execute() at which it will take 31 seconds, regardless of how complex the script is.



      The strangest thing is, this problem just came out of the blue; when my system was powered down, disconnected and untouched over the weekend. No updates, installations or changes were done to the system. Friday I was doing my dev work perfectly fine. But Monday morning when I powered it back up, the DB connections there are stuffed.



      I've already tried configuring mySQL to use the "skip-name-resolve" and "bind-address = ::" settings.
      I have tried rebuilding my IIS websites and reinstalling IIS itself.
      I've also reinstalled mySQL ODBC drivers on my system to no avail.



      What is going on here?










      share|improve this question













      My development system has suddenly been afflicted with this weird problem where every single SQL script takes exactly 31 seconds to execute on my Classic ASP site's connection to a mySQL (MariaDB) database.



      Connecting to either a local copy of the DB running off my system or even my live DB being hosted at a web host, it all the same.
      Everything from a simple



      adoconn.Execute("SELECT * FROM users;")


      or even



      adoconn.Execute("SET sql_mode''")


      would take 31 seconds to execute. Each!



      I can safely rule out any problems with the DB as connecting to it and running scripts from DBeaver shows no problems at all. The results come back instantly.
      I can also rule out network problems as the local DB and the hosted DB have the same results and I have used WireShark to confirm that the MySQL packets are being responded to almost immediately from the hosted DB.



      Debug stepping through my ASP code, everything runs fine right up until the .Execute() at which it will take 31 seconds, regardless of how complex the script is.



      The strangest thing is, this problem just came out of the blue; when my system was powered down, disconnected and untouched over the weekend. No updates, installations or changes were done to the system. Friday I was doing my dev work perfectly fine. But Monday morning when I powered it back up, the DB connections there are stuffed.



      I've already tried configuring mySQL to use the "skip-name-resolve" and "bind-address = ::" settings.
      I have tried rebuilding my IIS websites and reinstalling IIS itself.
      I've also reinstalled mySQL ODBC drivers on my system to no avail.



      What is going on here?







      mysql iis vbscript asp-classic






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 20 at 4:31









      BenjaminWKI

      162




      162
























          1 Answer
          1






          active

          oldest

          votes

















          up vote
          1
          down vote













          As it turns out, the cause of this whole issue was the McAfee software that came pre-installed in my Dell laptop.
          No, I did disable the firewall and antivirus, mind you.
          Those were the first steps I did and triple-checked routinely during my testing. Both McAfee's firewall and auto-protection were all fully disabled.
          But apparently, McAfee, ignores this setting and was screwing my DB connections over ODBC.



          This problem finally only came to an end when I fully uninstalled this McAfee malware. There's no other way to describe it.



          Let this post be a warning to anyone else naively believing this malware to be anything else.






          share|improve this answer





















            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53386276%2fasp-classic-on-iis-takes-31-seconds-to-execute-each-mysql-script%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            1
            down vote













            As it turns out, the cause of this whole issue was the McAfee software that came pre-installed in my Dell laptop.
            No, I did disable the firewall and antivirus, mind you.
            Those were the first steps I did and triple-checked routinely during my testing. Both McAfee's firewall and auto-protection were all fully disabled.
            But apparently, McAfee, ignores this setting and was screwing my DB connections over ODBC.



            This problem finally only came to an end when I fully uninstalled this McAfee malware. There's no other way to describe it.



            Let this post be a warning to anyone else naively believing this malware to be anything else.






            share|improve this answer

























              up vote
              1
              down vote













              As it turns out, the cause of this whole issue was the McAfee software that came pre-installed in my Dell laptop.
              No, I did disable the firewall and antivirus, mind you.
              Those were the first steps I did and triple-checked routinely during my testing. Both McAfee's firewall and auto-protection were all fully disabled.
              But apparently, McAfee, ignores this setting and was screwing my DB connections over ODBC.



              This problem finally only came to an end when I fully uninstalled this McAfee malware. There's no other way to describe it.



              Let this post be a warning to anyone else naively believing this malware to be anything else.






              share|improve this answer























                up vote
                1
                down vote










                up vote
                1
                down vote









                As it turns out, the cause of this whole issue was the McAfee software that came pre-installed in my Dell laptop.
                No, I did disable the firewall and antivirus, mind you.
                Those were the first steps I did and triple-checked routinely during my testing. Both McAfee's firewall and auto-protection were all fully disabled.
                But apparently, McAfee, ignores this setting and was screwing my DB connections over ODBC.



                This problem finally only came to an end when I fully uninstalled this McAfee malware. There's no other way to describe it.



                Let this post be a warning to anyone else naively believing this malware to be anything else.






                share|improve this answer












                As it turns out, the cause of this whole issue was the McAfee software that came pre-installed in my Dell laptop.
                No, I did disable the firewall and antivirus, mind you.
                Those were the first steps I did and triple-checked routinely during my testing. Both McAfee's firewall and auto-protection were all fully disabled.
                But apparently, McAfee, ignores this setting and was screwing my DB connections over ODBC.



                This problem finally only came to an end when I fully uninstalled this McAfee malware. There's no other way to describe it.



                Let this post be a warning to anyone else naively believing this malware to be anything else.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 22 at 0:00









                BenjaminWKI

                162




                162






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Stack Overflow!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53386276%2fasp-classic-on-iis-takes-31-seconds-to-execute-each-mysql-script%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Ottavio Pratesi

                    Tricia Helfer

                    15 giugno