อะไรคือข้อเสียของการใช้การเชื่อมต่อแบบถาวรใน PDO

ใน PDO สามารถทำการเชื่อมต่อถาวรโดยใช้PDO::ATTR_PERSISTENTแอ็ตทริบิวต์ ตามคู่มือ php -

การเชื่อมต่อแบบต่อเนื่องจะไม่ปิดในตอนท้ายของสคริปต์ แต่จะถูกแคชและนำมาใช้ใหม่เมื่อสคริปต์อื่นร้องขอการเชื่อมต่อโดยใช้ข้อมูลประจำตัวเดียวกัน แคชการเชื่อมต่อถาวรช่วยให้คุณหลีกเลี่ยงค่าใช้จ่ายในการสร้างการเชื่อมต่อใหม่ทุกครั้งที่สคริปต์ต้องการพูดคุยกับฐานข้อมูลทำให้เว็บแอปพลิเคชั่นทำงานได้เร็วขึ้น

คู่มือยังไม่แนะนำให้ใช้การเชื่อมต่อแบบถาวรในขณะที่ใช้ไดรเวอร์ PDO ODBC เพราะอาจขัดขวางกระบวนการเชื่อมต่อ ODBC

เห็นได้ชัดว่าดูเหมือนว่าจะไม่มีข้อเสียของการใช้การเชื่อมต่อแบบถาวรใน PDO ยกเว้นในกรณีสุดท้าย อย่างไรก็ตามฉันต้องการทราบว่ามีข้อเสียอื่น ๆ ของการใช้กลไกนี้หรือไม่เช่นสถานการณ์ที่กลไกนี้ส่งผลให้ประสิทธิภาพการทำงานลดลงหรือเป็นเช่นนั้น

โปรดอ่านคำตอบนี้ด้านล่างซึ่งมีรายละเอียดวิธีการบรรเทาปัญหาที่อธิบายไว้ที่นี่

มีข้อเสียเปรียบเดียวกันโดยใช้ PDO เช่นเดียวกับอินเทอร์เฟซฐานข้อมูล PHP อื่น ๆ ที่ทำการเชื่อมต่อแบบถาวร: หากสคริปต์ของคุณสิ้นสุดลงโดยไม่คาดหมายในระหว่างการดำเนินการฐานข้อมูลคำขอถัดไปที่ได้รับจากการเชื่อมต่อ การเชื่อมต่อนั้นถูกเปิดไว้ที่ระดับผู้จัดการกระบวนการ (Apache สำหรับ mod_php ซึ่งเป็นกระบวนการ FastCGI ปัจจุบันหากคุณใช้ FastCGI และอื่น ๆ ) ไม่ใช่ที่ระดับ PHP และ PHP จะไม่บอกขั้นตอนหลักเพื่อให้การเชื่อมต่อตายเมื่อ สคริปต์หยุดทำงานผิดปกติ

หากสคริปต์ที่ตายแล้วล็อกตารางตารางเหล่านั้นจะยังคงถูกล็อกจนกว่าการเชื่อมต่อจะตายหรือสคริปต์ถัดไปที่ได้รับการเชื่อมต่อจะปลดล็อคตารางเอง

หากสคริปต์ที่ตายแล้วอยู่ในระหว่างการทำธุรกรรมนั้นสามารถบล็อกตารางจำนวนมากจนกว่าตัวจับเวลาการหยุดชะงักจะเริ่มขึ้นและถึงแม้ว่าตัวจับเวลาการหยุดชะงักจะสามารถฆ่าการร้องขอที่ใหม่กว่าแทนที่จะเป็นการร้องขอที่เก่ากว่าซึ่งเป็นสาเหตุของปัญหา

หากสคริปต์ที่ตายแล้วอยู่ในระหว่างการทำธุรกรรมสคริปต์ถัดไปที่ได้รับการเชื่อมต่อนั้นจะได้รับสถานะของธุรกรรมด้วย เป็นไปได้มาก (ขึ้นอยู่กับการออกแบบแอปพลิเคชันของคุณ) ที่สคริปต์ต่อไปอาจไม่เคยลองทำธุรกรรมที่มีอยู่หรือจะกระทำเมื่อไม่ควรทำหรือย้อนกลับเมื่อไม่ควรทำ

นี่เป็นเพียงส่วนเล็ก ๆ ของภูเขาน้ำแข็ง ทุกอย่างสามารถลดลงได้โดยพยายามทำความสะอาดหลังจากการเชื่อมต่อที่สกปรกในการร้องขอสคริปต์ทุกครั้ง แต่อาจมีความเจ็บปวดขึ้นอยู่กับฐานข้อมูล หากคุณไม่ได้ระบุการสร้างการเชื่อมต่อฐานข้อมูลเป็นสิ่งหนึ่งที่เป็นปัญหาคอขวดในสคริปต์ของคุณ (ซึ่งหมายความว่าคุณได้ทำการสร้างรหัสโดยใช้xdebugและ / หรือxhprof ) คุณไม่ควรพิจารณาการเชื่อมต่อแบบถาวรเป็นวิธีการใด ๆ

นอกจากนี้ฐานข้อมูลที่ทันสมัยส่วนใหญ่ (รวมถึง PostgreSQL) มีวิธีที่เป็นที่ต้องการในการดำเนินการรวมการเชื่อมต่อที่ไม่มีข้อเสียในทันทีที่การเชื่อมต่อแบบถาวรบนพื้นฐานของ PHP ใช้วานิลลาธรรมดา

เพื่อชี้แจงประเด็นเราใช้การเชื่อมต่อแบบถาวรที่สถานที่ทำงานของฉัน แต่ไม่ใช่ทางเลือก เรากำลังเผชิญหน้าแปลกพฤติกรรมการเชื่อมต่อที่เชื่อมต่อเริ่มต้นจากเซิร์ฟเวอร์ app ของเราไปยังเซิร์ฟเวอร์ฐานข้อมูลของเราคือการตรงสามวินาทีเมื่อมันควรจะมีการดำเนินการส่วนของเสี้ยววินาทีที่ เราคิดว่าเป็นข้อผิดพลาดเคอร์เนล เราเลิกพยายามแก้ไขปัญหาเพราะมันเกิดขึ้นแบบสุ่มและไม่สามารถทำซ้ำได้ตามความต้องการและฝ่ายไอทีที่เราให้บริการไม่มีความสามารถที่เป็นรูปธรรมในการติดตาม

เมื่อคนในคลังสินค้ากำลังประมวลผลชิ้นส่วนที่เข้ามาสองสามร้อยชิ้นและแต่ละส่วนใช้เวลาสามและครึ่งวินาทีแทนที่จะเป็นครึ่งวินาทีเราต้องดำเนินการก่อนที่พวกเขาจะถูกลักพาตัวเราและทำให้เราช่วยเหลือพวกเขา ดังนั้นเราจึงพลิกบิตสองสามบิตในความน่าประหลาดใจของ ERP / CRM / CMS ที่ปลูกในบ้านของเราและประสบการณ์ที่น่ากลัวทั้งหมดของการเชื่อมต่อแบบคงที่โดยตรง เราใช้เวลาหลายสัปดาห์ในการติดตามปัญหาเล็กน้อยที่ละเอียดอ่อนและพฤติกรรมแปลกประหลาดที่เกิดขึ้นแบบสุ่ม ปรากฎว่าข้อผิดพลาดร้ายแรงครั้งต่อสัปดาห์ที่ผู้ใช้ของเราขยันหมั่นเพียรจากแอพของเรากำลังออกจากตารางที่ถูกล็อคธุรกรรมที่ถูกทอดทิ้งและรัฐที่สกปรกอื่น ๆ ที่โชคร้าย

เรื่องเศร้า ๆ นี้มีประเด็น: มันทำลายสิ่งต่าง ๆ ที่เราไม่เคยคาดคิดมาก่อนในชื่อของการแสดง การแลกเปลี่ยนไม่คุ้มค่าและเรากำลังรอวันที่เราสามารถเปลี่ยนกลับไปใช้การเชื่อมต่อปกติโดยไม่ต้องวุ่นวายจากผู้ใช้ของเรา

เพื่อตอบสนองต่อปัญหาของชาร์ลส์ข้างต้น

จาก: http://www.php.net/manual/en/mysqli.quickstart.connections.php -

บ่นทั่วไปเกี่ยวกับการเชื่อมต่อแบบถาวรคือสถานะของพวกเขาจะไม่รีเซ็ตก่อนที่จะนำมาใช้ใหม่ ตัวอย่างเช่นธุรกรรมที่เปิดและไม่เสร็จจะไม่ถูกย้อนกลับโดยอัตโนมัติ แต่ยังการเปลี่ยนแปลงการอนุญาตที่เกิดขึ้นในช่วงเวลาระหว่างการวางการเชื่อมต่อลงในกลุ่มและการใช้ซ้ำจะไม่สะท้อนให้เห็น สิ่งนี้อาจถูกมองว่าเป็นผลข้างเคียงที่ไม่พึงประสงค์ ในทางตรงกันข้ามชื่อถาวรอาจเข้าใจได้ว่าเป็นสัญญาที่ยืนยันว่ารัฐยังคงอยู่

นามสกุล mysqli รองรับทั้งการตีความการเชื่อมต่อแบบต่อเนื่อง: สถานะคงอยู่และตั้งค่าสถานะใหม่ก่อนที่จะนำมาใช้ซ้ำ ค่าเริ่มต้นจะถูกรีเซ็ต ก่อนที่การเชื่อมต่อแบบถาวรจะถูกนำมาใช้ซ้ำส่วนขยาย mysqli โดยปริยายเรียกmysqli_change_user()เพื่อรีเซ็ตสถานะ การเชื่อมต่อแบบต่อเนื่องจะปรากฏต่อผู้ใช้ราวกับว่าเพิ่งเปิด ไม่มีสิ่งประดิษฐ์จากประเพณีก่อนหน้านี้ปรากฏให้เห็น

mysqli_change_user()ฟังก์ชั่นการทำงานที่มีราคาแพง เพื่อประสิทธิภาพที่ดีที่สุดผู้ใช้อาจต้องการคอมไพล์ส่วนขยายอีกครั้งด้วยMYSQLI_NO_CHANGE_USER_ON_PCONNECTการตั้งค่าสถานะการคอมไพล์

ผู้ใช้จะต้องเลือกระหว่างพฤติกรรมที่ปลอดภัยและประสิทธิภาพที่ดีที่สุด ทั้งสองเป็นเป้าหมายการเพิ่มประสิทธิภาพที่ถูกต้อง เพื่อความสะดวกในการใช้งานพฤติกรรมด้านความปลอดภัยได้ถูกกำหนดเป็นค่าใช้จ่ายเพื่อประสิทธิภาพสูงสุด

การเชื่อมต่อแบบถาวรเป็นความคิดที่ดีเฉพาะเมื่อใช้เวลานานพอสมควรในการเชื่อมต่อกับฐานข้อมูลของคุณ ทุกวันนี้แทบจะไม่เคยเกิดขึ้นเลย ข้อเสียเปรียบที่ใหญ่ที่สุดของการเชื่อมต่อแบบถาวรคือมัน จำกัด จำนวนผู้ใช้ที่คุณสามารถเรียกดูไซต์ของคุณ: ถ้า MySQL ได้รับการกำหนดค่าให้อนุญาตการเชื่อมต่อพร้อมกัน 10 ครั้งในครั้งเดียวแล้วเมื่อบุคคลที่ 11 พยายามเรียกดูไซต์ของคุณ .

PDO ไม่จัดการการติดตา ไดรเวอร์ MySQL ทำ มันนำมาใช้ใหม่การเชื่อมต่อเมื่อ) พวกเขามีอยู่และโฮสต์ / ผู้ใช้ / รหัสผ่าน / ฐานข้อมูลที่ตรงกัน หากมีการเปลี่ยนแปลงใด ๆ มันจะไม่นำการเชื่อมต่อกลับมาใช้ใหม่ ผลกระทบสุทธิกรณีที่ดีที่สุดคือการเชื่อมต่อเหล่านี้คุณจะเริ่มต้นและหยุดบ่อยเพราะคุณมีผู้ใช้ที่แตกต่างกันในเว็บไซต์และทำให้พวกเขาคงไม่ทำดี

สิ่งสำคัญที่ต้องเข้าใจเกี่ยวกับการเชื่อมต่อแบบถาวรคือคุณไม่ควรใช้การเชื่อมต่อเหล่านี้กับเว็บแอปพลิเคชันส่วนใหญ่ พวกมันดูน่าหลงใหล แต่มันอันตรายและไร้ประโยชน์มาก

ฉันแน่ใจว่ามีเธรดอื่น ๆ อยู่ด้วย แต่การเชื่อมต่อแบบถาวรนั้นเป็นอันตรายเพราะมันยังคงอยู่ระหว่างการร้องขอ ตัวอย่างเช่นหากคุณล็อกตารางในระหว่างการร้องขอจากนั้นไม่สามารถปลดล็อกได้ตารางนั้นจะถูกล็อคอย่างไม่มีกำหนด การเชื่อมต่อแบบต่อเนื่องนั้นไร้ประโยชน์มากสำหรับ 99% ของแอพของคุณเพราะคุณไม่รู้ว่าจะใช้การเชื่อมต่อเดียวกันระหว่างคำขอที่แตกต่างกันหรือไม่ แต่ละเธรดเว็บจะมีชุดการเชื่อมต่อถาวรของตัวเองและคุณไม่มีวิธีควบคุมว่าเธรดใดจะจัดการคำขอใด

คลัง mysql ขั้นตอนของ PHP มีคุณสมบัติที่การเรียก mysql_connect ในภายหลังจะกลับลิงค์เดียวกันแทนที่จะเปิดการเชื่อมต่อที่แตกต่างกัน สิ่งนี้ไม่มีส่วนเกี่ยวข้องกับการเชื่อมต่อแบบถาวรและเฉพาะกับไลบรารี mysql PDO ไม่แสดงพฤติกรรมดังกล่าว

ลิงค์ทรัพยากร: ลิงค์

โดยทั่วไปคุณสามารถใช้สิ่งนี้เป็น "ruleset" คร่าวๆ ::

ใช่ใช้การเชื่อมต่อแบบถาวรถ้า:

• มีแอปพลิเคชั่น / ผู้ใช้เพียงไม่กี่รายเท่านั้นที่เข้าถึงฐานข้อมูลนั่นคือคุณจะไม่ส่งผลให้เกิดการเชื่อมต่อ 200 แบบเปิด (แต่อาจจะว่าง) เนื่องจากมีผู้ใช้ 200 คนที่แตกต่างกันในโฮสต์เดียวกัน

• ฐานข้อมูลกำลังทำงานบนเซิร์ฟเวอร์อื่นที่คุณเข้าถึงผ่านเครือข่าย

• แอปพลิเคชัน (หนึ่ง) เข้าถึงฐานข้อมูลบ่อยครั้งมาก

ไม่ไม่ต้องใช้การเชื่อมต่อแบบถาวรหาก:

• แอปพลิเคชันของคุณต้องเข้าถึงฐานข้อมูล 100 ครั้งต่อชั่วโมง

• คุณมีเว็บเซิร์ฟเวอร์จำนวนมากที่เข้าถึงเซิร์ฟเวอร์ฐานข้อมูลเดียว

การใช้การเชื่อมต่อแบบต่อเนื่องนั้นเร็วกว่ามากโดยเฉพาะหากคุณเข้าถึงฐานข้อมูลผ่านเครือข่าย มันไม่ได้สร้างความแตกต่างอย่างมากถ้าฐานข้อมูลกำลังทำงานบนเครื่องเดียวกัน แต่ก็ยังเร็วกว่าเล็กน้อย อย่างไรก็ตาม - ตามชื่อบอกว่า - การเชื่อมต่อจะคงอยู่นั่นคือมันยังคงเปิดอยู่แม้ว่าจะไม่ได้ใช้ก็ตาม

ปัญหาที่เกิดขึ้นคือใน "การกำหนดค่าเริ่มต้น" นั้น MySQL อนุญาตให้ 1,000 ช่องสัญญาณแบบ "เปิด" เท่านั้น หลังจากนั้นการเชื่อมต่อใหม่จะถูกปฏิเสธ (คุณสามารถปรับแต่งการตั้งค่านี้) ดังนั้นถ้าคุณมี - พูด - 20 Webservers ที่มีลูกค้า 100 คนในนั้นและทุกคนมีเพียงหนึ่งหน้าต่อชั่วโมงคณิตศาสตร์ง่าย ๆ จะแสดงให้คุณเห็นว่าคุณจะต้องเชื่อมต่อกับฐานข้อมูลแบบขนาน 2000 ครั้ง นั่นไม่ได้ผล

Ergo: ใช้สำหรับแอปพลิเคชันที่มีคำขอจำนวนมากเท่านั้น

ในการทดสอบของฉันฉันมีเวลาในการเชื่อมต่อนานกว่าหนึ่งวินาทีกับ localhost ของฉันดังนั้นสมมติว่าฉันควรใช้การเชื่อมต่อแบบถาวร การทดสอบเพิ่มเติมพบว่ามันเป็นปัญหากับ 'localhost':

ผลการทดสอบในไม่กี่วินาที (วัดโดย php microtime):

• เว็บโฮสต์: connectDB: 0.0038912296295166
• localhost: connectDB: 1.0214691162109 (เกินหนึ่งวินาที: ห้ามใช้ localhost!)
• 127.0.0.1: connectDB: 0.00097203254699707

ที่น่าสนใจ: รหัสต่อไปนี้เร็วเท่ากับการใช้ 127.0.0.1:

$host = gethostbyname('localhost');
// echo "<p>$host</p>";
$db = new PDO("mysql:host=$host;dbname=" . DATABASE . ';charset=utf8', $username, $password,
    array(PDO::ATTR_EMULATE_PREPARES => false,
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));

การเชื่อมต่อแบบต่อเนื่องควรให้ประสิทธิภาพที่เพิ่มขึ้นอย่างมาก ฉันไม่เห็นด้วยกับการที่คุณควร "หลีกเลี่ยง" การติดตา ..

ดูเหมือนว่าข้อร้องเรียนข้างต้นเกิดจากบางคนที่ใช้ตาราง MyIASM และแฮ็คในการทำธุรกรรมรุ่นของตัวเองโดยการล๊อคล็อคตารางแน่นอนว่าคุณกำลังจะหยุดชะงัก ใช้ startTransaction () ของ PDO และย้ายตารางของคุณไปที่ InnoDB

ดูเหมือนว่าฉันมีการเชื่อมต่อแบบถาวรจะกินทรัพยากรระบบมากขึ้น อาจเป็นเรื่องเล็กน้อย แต่ก็ยัง ...

คำอธิบายสำหรับการใช้การเชื่อมต่อแบบถาวรนั้นลดปริมาณการเชื่อมต่อที่ค่อนข้างมีค่าใช้จ่ายอย่างเห็นได้ชัดแม้ว่าความจริงแล้วมันจะเร็วกว่าด้วย MySQL มากกว่าเมื่อเปรียบเทียบกับฐานข้อมูลอื่น

ปัญหาแรกของการเชื่อมต่อแบบต่อเนื่อง ...

หากคุณกำลังสร้างการเชื่อมต่อ 1,000 รายการต่อวินาทีโดยปกติคุณไม่แน่ใจว่าเปิดอยู่เป็นเวลานาน แต่ระบบปฏิบัติการไม่ ขึ้นอยู่กับโปรโตคอล TCP / IP พอร์ตไม่สามารถนำกลับมาใช้ใหม่ได้ทันทีและต้องลงทุนสักครู่ในขั้นตอน“ FIN” ที่รอก่อนที่จะสามารถนำกลับมาใช้ใหม่ได้

ปัญหาที่สอง ... ใช้การเชื่อมต่อเซิร์ฟเวอร์ MySQL จำนวนมาก

หลายคนไม่ทราบว่าคุณสามารถเพิ่มตัวแปร * max_connections * และรับการเชื่อมต่อพร้อมกันมากกว่า 100 รายการกับคนอื่น ๆ ใน MySQL ได้รับผลกระทบจากปัญหาเก่าของ Linux ที่ไม่สามารถถ่ายทอดมากกว่า 1024 การเชื่อมต่อกับ MySQL

อนุญาตให้พูดคุยเกี่ยวกับสาเหตุที่การเชื่อมต่อแบบถาวรถูกปิดใช้งานในส่วนขยาย mysqli แม้ว่าข้อเท็จจริงที่ว่าคุณสามารถใช้การเชื่อมต่อแบบต่อเนื่องในทางที่ผิดและรับประสิทธิภาพที่ไม่ดีซึ่งไม่ใช่เหตุผลหลัก เหตุผลที่แท้จริงคือ - คุณจะได้รับปัญหามากขึ้นด้วย

การเชื่อมต่อแบบต่อเนื่องถูกใส่เข้าไปใน PHP ตลอดเวลาของ MySQL 3.22 / 3.23 เมื่อ MySQL ไม่ยากดังนั้นหมายความว่าคุณสามารถรีไซเคิลการเชื่อมต่อได้อย่างง่ายดายโดยไม่มีปัญหา อย่างไรก็ตามปริมาณของปัญหาในรุ่นที่ใหม่กว่านั้นเกิดขึ้น - หากคุณรีไซเคิลการเชื่อมต่อที่มีการทำธุรกรรมที่ไม่มีข้อผูกมัด หากคุณรีไซเคิลการเชื่อมต่อด้วยการกำหนดค่าชุดอักขระที่กำหนดเองคุณตกอยู่ในอันตรายอีกครั้งรวมทั้งอาจมีการเปลี่ยนแปลงตามตัวแปรเซสชัน

ปัญหาอย่างหนึ่งของการใช้การเชื่อมต่อแบบถาวรก็คือมันไม่ได้มีขนาดที่ดี สำหรับผู้ที่มีการเชื่อมต่อ 5,000 คนคุณจะต้องเชื่อมต่อแบบต่อเนื่องถึง 5,000 ครั้ง สำหรับความต้องการในการคงอยู่คุณอาจมีความสามารถในการรับใช้ 10,000 คนที่มีจำนวนการเชื่อมต่อที่ใกล้เคียงกันเพราะพวกเขาอยู่ในฐานะที่จะแบ่งปันการเชื่อมต่อส่วนบุคคลเมื่อไม่ได้อยู่กับพวกเขา

ฉันแค่สงสัยว่าโซลูชันบางส่วนจะมีกลุ่มการเชื่อมต่อที่ใช้งานได้หรือไม่ คุณสามารถใช้เวลาในการสร้างกลุ่มการเชื่อมต่อเมื่อระบบมีการใช้งานต่ำถึงขีด จำกัด แจกพวกเขาและฆ่าพวกเขาเมื่อพวกเขาได้เสร็จสิ้นหรือหมดเวลา ในพื้นหลังคุณกำลังสร้างการเชื่อมต่อใหม่ขณะที่พวกเขากำลังถูกพา ในกรณีที่เลวร้ายที่สุดสิ่งนี้ควรจะช้าเท่ากับการสร้างการเชื่อมต่อโดยไม่ต้องใช้พูลการสันนิษฐานว่าการสร้างลิงก์เป็นปัจจัย จำกัด หรือไม่