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?
mysql iis vbscript asp-classic
add a comment |
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?
mysql iis vbscript asp-classic
add a comment |
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?
mysql iis vbscript asp-classic
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
mysql iis vbscript asp-classic
asked Nov 20 at 4:31
BenjaminWKI
162
162
add a comment |
add a comment |
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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 22 at 0:00
BenjaminWKI
162
162
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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