Bug #9627 10 Second Pausing on WAN connections
Submitted: 4 Apr 2005 21:02 Modified: 30 May 2013 9:44
Reporter: Brian Pilati Email Updates:
Status: Closed Impact on me:
None 
Category:Connector / ODBC Severity:S2 (Serious)
Version:3.51.11-3 OS:Windows (Windows 2000 Pro)
Assigned to: CPU Architecture:Any

[4 Apr 2005 21:02] Brian Pilati
Description:
My ODBC pauses 10 seconds between queries. 

Redhat Linux 2.4.20-8 
MySQL 4.1.10 or 4.1.10a (I have one of each server on two machines) 
MyODBC 3.51.3, 3.51.10, 3.51.11-3 

Everything was fine while I was using 3.51.10 and 4.0 but when I upgraded to 4.1 it slowed way down. The LAN is fine no pausing. 

This is a report of the tethereal sniff (Look at the 10 seconds intervals, they should be concurrent however, a few are concurrent and then intervaled, again): 

16.292598 172.16.3.3 -> 192.168.16.4 MySQL Server Greeting Protocol : 10 ,version: 4.1.10a-standard-log Caps: 0xffffa22c 

16.293395 192.168.16.4 -> 172.16.3.3 MySQL Login Request Caps: 

16.399583 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Query : 

16.508006 172.16.3.3 -> 192.168.16.4 MySQL Response OK 

26.722685 172.16.3.3 -> 192.168.16.4 MySQL Server Greeting Protocol : 10 ,version: 4.1.10a-standard-log Caps: 0xffffa22c 

26.723205 192.168.16.4 -> 172.16.3.3 MySQL Login Request Caps: 

26.870087 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Query : 

26.982438 172.16.3.3 -> 192.168.16.4 MySQL Response OK 

37.193078 172.16.3.3 -> 192.168.16.4 MySQL Server Greeting Protocol : 10 ,version: 4.1.10a-standard-log Caps: 0xffffa22c 

37.193604 192.168.16.4 -> 172.16.3.3 MySQL Login Request Caps: 

37.318319 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Query : 

37.435606 172.16.3.3 -> 192.168.16.4 MySQL Response OK 

37.438294 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Quit 

37.439095 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Quit 

47.677699 172.16.3.3 -> 192.168.16.4 MySQL Server Greeting Protocol : 10 ,version: 4.1.10a-standard-log Caps: 0xffffa22c 

47.678229 192.168.16.4 -> 172.16.3.3 MySQL Login Request Caps: 

47.901597 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Query : 

48.012678 172.16.3.3 -> 192.168.16.4 MySQL Response OK 

48.018171 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Query : 

48.137827 172.16.3.3 -> 192.168.16.4 MySQL Response OK 

48.138845 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Quit 

48.146600 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Query : 

48.285379 172.16.3.3 -> 192.168.16.4 MySQL Response OK 

48.286330 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Query : 

48.412633 172.16.3.3 -> 192.168.16.4 MySQL Response OK 

49.128214 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Query : 

49.244233 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Query : 

59.582064 172.16.3.3 -> 192.168.16.4 MySQL Server Greeting Protocol : 10 ,version: 4.1.10a-standard-log Caps: 0xffffa22c 

59.582581 192.168.16.4 -> 172.16.3.3 MySQL Login Request Caps: 

59.700839 172.16.3.3 -> 192.168.16.4 MySQL Response OK 

59.702758 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Query : 

59.821953 172.16.3.3 -> 192.168.16.4 MySQL Response OK 

59.985738 192.168.16.4 -> 172.16.3.3 MySQL Request Command: Quit 

Thanks 

Brian

How to repeat:
Login from the WAN.  Multiple locations on different ISPs have been tried, they are all slow
[14 Apr 2005 19:45] Brian Pilati
I am not sure if this is a bug or not now.  I was able to fix the problem by adding
skip-name-resolve to the my.cnf file.  

It appears that the client was hanging on DNS resolution??
[14 Apr 2005 20:03] MySQL Verification Team
We had already have similar report issue with a Windows box and I suggested
to the bug's reporter to apply the skip-name-resolve for to test the
DNS. Please ready carefully the bug:

http://bugs.mysql.com/bug.php?id=9477

where you should find the reason why in that box happened
this behavior:

 [30 Mar 20:44] Christian Schlepphorst

I will try to describe what I did.

.........

Thanks in advance.
[14 May 2005 23:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[30 May 2013 9:44] Bogdan Degtyariov
I'm closing this bug because I can not continue without feedback from the reporter. If you have new info, please reopen the report.