المضيف المحلي لقاعدة بيانات اتصال Mysql أبطأ من 127.0.0.1

أثناء عملية تطوير php+mysql، عند ملء اسم المضيف للاتصال بقاعدة البيانات، يمكن للجهاز المحلي بشكل عام استخدام المضيف المحلي أو 127.0.0.1. في عملية التطبيق الفعلية، لم يتم العثور على أي شذوذ في نظام Linux، ولكن في نظام خادم Windows، عند كتابة المضيف المحلي، ستكون استجابة صفحة الويب بطيئة نسبيًا، بشكل عام، يستغرق إكمال الصفحة أكثر من ثانية واحدة، وقد قمت بتقييم وقت تشغيل البرنامج خطوة بخطوة ووجدت أنها مشكلة عند الاتصال بـ mysql، يستغرق إنشاء الاتصال ما يقرب من ثانية واحدة. إذا كانت هناك مشكلة، فابحث عنها واكتشف أن هذا الموقف موجود بالفعل. المقتطف هو كما يلي:

HTTP://blog.Sina.com.abilities/是/blog_6cost 5ah 76 شعر 0100 لوحة واحدة.HTML

لقد وجدت مؤخرًا أن وقت استجابة البرنامج كان بطيئًا بعض الشيء، لذا قمت بإزالته تدريجيًا وحساب وقت تنفيذ كل برنامج، وأخيرًا، وجدت أن الوقت الضائع في الارتباط بقاعدة البيانات لا توجد طريقة جيدة للربط قاعدة البيانات، لذلك أضعها.

في اليوم التالي، قمت باختبار الارتباط البعيد بقاعدة البيانات ووجدت أن وقت تنفيذ استخدام IP للوصول إلى قاعدة البيانات كان قصيرًا جدًا وأقصر بكثير مما كان عليه عندما استخدمت المضيف المحلي للاتصال بقاعدة البيانات محليًا. لذلك لدينا الاختبار التالي:

set_time_limit(0) ;
$localtime = 0 ;
for($i=1;$i<=50;$i++){
 $btime = get_microtime() ;   
 $conn = new mysqli("localhost","root","admin","") ;
 $conn-close() ;
 $etime = get_microtime() ;
 $localtime += $etime-$btime ;
}
$iptime =0 ;
for($i=1;$i<=50;$i++){
 $btime = get_microtime() ;   
 $conn = new mysqli("127.0.0.1","root","admin","") ;
 $conn-close() ;
 $etime = get_microtime() ;
 $iptime += $etime-$btime ;
}
echo "localhost时间损耗为：".($localtime)/$i."<br /" ;
echo "127.0.0.1时间损耗为：".($iptime/$i)."<br /" ;
function get_microtime(){
 list($micro,$time) = explode(" ",microtime());
 return $time+$micro ;
}

نتيجة الإخراج هي: فقدان وقت المضيف المحلي هو: 0.98833055122226

خسارة الوقت 127.0.0.1 هي: 0.0039590807522044

 

يختلف استهلاك الوقت لطريقتي الاتصال اختلافًا كبيرًا، وسيكون من الرائع أن يكون هناك خبراء يمكنهم المساعدة في الإجابة على هذا السؤال.

لقد خمنت أن ذلك قد يكون بسبب دقة DNS، أو أن دقة المضيف المحلي تستغرق وقتًا. يرجى توضيح أنني أستخدم نظام النوافذ.

شرح السبب:

إنها بالفعل مشكلة في تحليل نظام التشغيل لمزيد من التفاصيل، يرجى الرجوع إلى http://www.cnblogs.com/hayywcy/p/5341550.html.

لقد واجهت مشكلة غريبة اليوم عند الوصول إلى المضيف المحلي، لم يتم العثور على 404، ولكن كان من الممكن الوصول إلى 127.0.0.1. أخيرًا، تم العثور على السبب لأن Windows قام بتحليل المضيف المحلي إلى عنوان IPv6::1 بدلاً من 127.0.0.1. لقد قمت بفحص المضيفين ووجدت أنه تم حظر IPv6. ويوجد أيضًا 127.0.0.1 مضيف محلي، لكن لا يمكن تحليله بشكل طبيعي. بحثت بايدو لفترة طويلة دون جدوى، وأخيراً وجدت حلاً على جوجل باستخدام طرق الإنترنت العلمية لمنع ضياع المنشور الأصلي، قمت بإعادة نشره هنا (عنوان المنشور الأصلي: http://superuser.com/questions/). 436574/ipv4-vs-ipv6- الأولوية في النوافذ-7/436944#436944).

محتوى المقال:

الحل رقم 1: إضافة سياسة بادئة لتفضيل عناوين IPV4 على IPV6 يشبه جدول سياسة البادئة جدول التوجيه، فهو يحدد عناوين IP المفضلة عند إجراء اتصال. لاحظ أن الأسبقية الأعلى في سياسات البادئة يتم تمثيلها من خلال "الأسبقية" الأكبر. القيمة، عكس قيمة "التكلفة" في جدول التوجيه تمامًا.

جدول سياسة بادئة Windows الافتراضي:

C:\netsh واجهة ipv6 تظهر سياسات البادئات الاستعلام عن الحالة النشطة...

 الأسبقية  التسمية  البادئة

 ----------  -----  -------------------------- ---

 50      0  ::1/128

 40      1  ::/0

 30      2  2002::/16

 20      3  ::/96

 10      4  ::ffff:0:0/96

  5      5  2001::/32 لاحظ أن عناوين IPv6 (::/0) مفضلة على عناوين IPv4 (::/96, ::ffff:0:0/96) .

 

يمكننا إنشاء سياسة من شأنها أن تجعل نفق Hurricane Electric IPv6 أقل ملاءمة من أي عنوان IPv4:

واجهة netsh ipv6 add prefixpolicy 2001:470::/32 3 6 2001:470::/32 هي بادئة Hurricane Electric، و3 هي الأسبقية (منخفضة جدًا) و6 هي تسمية.

كان بإمكاني استخدام بادئة أكثر عمومية، ولكنني أردت التأكد من أنه إذا حصلت على اتصال IPv6 مباشر من مزود خدمة الإنترنت، فسيكون له الأسبقية على IPv4.

إذا قمت بتكييف هذا الحل، فستحتاج إلى استبدال بادئة IPv6 المناسبة بدلاً من بادئة Hurricane Electric.

الحل رقم 2: تعديل التسجيل لجعل Windows يفضل دائمًا IPV4 على IPV6

يعد هذا الحل أكثر عمومية، ولكنه أكثر تدخلاً وأقل توافقًا مع المعايير. وفي النهاية، سيستمر Windows في تعديل جدول سياسة البادئة نيابةً عنك.

افتح RegEdit، وانتقل إلى HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters قم بإنشاء قيمة تسجيل DisabledComponents DWORD، وقم بتعيين قيمتها على 20 (سداسي عشري).

راجع Microsoft KB 929852 للحصول على مزيد من المعلومات حول مفتاح التسجيل هذا، خاصة إذا كان DisabledComponentsalready موجودًا على نظامك.

وفقًا للترجمة، لدى Windows قائمة تحليل للأولوية عندما يكون لـ ipv6 أولوية أعلى من ipv4، سيحدث الموقف الذي واجهته اليوم (على الرغم من عدم العثور على سبب ذلك بعد). الطريقة الأولى هي إضافة سجل بأولوية ipv4 أعلى من ipv6 إلى جدول تحليل الأولوية، نظرًا لأن العديد من الكلمات لا يمكن فهمها، وأخشى أن أخطئ في المعلمات، فلا أجرؤ على استخدامها. لقد قمت بحلها بالطريقة الثانية وهي تعديل السجل والطريقة هي كما يلي (إذا كنت لا تفهم اللغة الإنجليزية فلا داعي للتحقق منها):

افتح السجل، وابحث عن المفتاح HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters، وأضف عنصرًا من النوع DWORD بالاسم DisabledComponents (إذا كان هناك عنصر بالفعل، فلن تحتاج إلى إضافته وتغيير القيمة مباشرة ). ثم قم بتعديل القيمة إلى 20 ونوع القيمة إلى النظام الست عشري. هذا كل شيء، احفظ السجل وأعد تشغيل الكمبيوتر. حاول تنفيذ الأمر ping على المضيف المحلي مرة أخرى وحاول.