សំណើ Squid យឺត ជាមួយ URL rewriter ដែលគាំង

ប្រសិនបើ Squid ទទួលការតភ្ជាប់ ប៉ុន្តែចំណាយពេលយូរដើម្បីបញ្ជូនសំណើបន្ត សូមពិនិត្យឧបករណ៍សរសេរ URL ឡើងវិញណាមួយនៅលើផ្លូវនោះ។ ក្នុង Squid 5–7, url_rewrite_program គឺជាឈ្មោះកម្មវិធីខាងក្រៅដែលត្រូវបានហៅបន្ទាប់ពីការត្រួតពិនិត្យសិទ្ធិចូលដំបូង។ វាអាចធ្វើឱ្យសំណើយឺតយ៉ាវមុនពេលគោលដៅទទួលបានវា។

1. អានពាក្យបញ្ជាសរសេរឡើងវិញដែលកំពុងដំណើរការ រួមទាំង wrapper និងអាគុយម៉ង់។
2. ផ្គូផ្គងប្រតិបត្តិការដែលរងផលប៉ះពាល់ជាមួយ ការធ្វើរោគវិនិច្ឆ័យរបស់ជំនួយការ។ ការចេញរបស់ដំណើរការកូនម្តងហើយម្តងទៀត ការឆ្លើយតបមិនត្រឹមត្រូវ និងជួររង់ចាំដែលកើនឡើង គឺជាសញ្ញាផ្សេងៗគ្នា។
3. ពិនិត្យថាតើទម្រង់ URL មួយជាអ្នកបង្កឱ្យមានបញ្ហាដែរឬទេ។ រក្សាទុកឧទាហរណ៍ដែលបានលុបព័ត៌មានរសើបនៃទិន្នន័យបញ្ចូលនោះ ជាជាងកែប្រែការកំណត់ resolver ដែលមិនពាក់ព័ន្ធ។

ជំនួយការមានកិច្ចសន្យាសំណើ/ឆ្លើយតបតាមបន្ទាត់។ អត្ថបទវឌ្ឍនភាពរបស់ wrapper នៅលើ standard output អាចធ្វើឱ្យវាខូច។ ការរត់ script ដោយជោគជ័យក្នុងនាមអ្នកគ្រប់គ្រងក៏មិនអាចបង្កើតលំហូរបញ្ចូល បរិស្ថាន ឬសិទ្ធិរបស់ Squid ឡើងវិញបានដែរ។ ផ្លូវនេះដាច់ដោយឡែកពីការផ្ទៀងផ្ទាត់ពាក្យសម្ងាត់។

លុះត្រាតែការផ្លាស់ប្តូរនេះដំណើរការ ទើបគួរចាត់ទុកវាជាបញ្ហាសមត្ថភាព។ url_rewrite_children គ្រប់គ្រងដំណើរការ និងឥរិយាបថជួររង់ចាំពាក់ព័ន្ធ ប៉ុន្តែការបន្ថែមដំណើរការកូនមិនអាចជួសជុលការគាំងដែលបង្កដោយទិន្នន័យបញ្ចូលបានទេ។ ជម្រើស concurrency របស់វាបង្កើតលេខសម្គាល់ឆានែល ហើយតម្រូវឱ្យជំនួយការអនុវត្តការសន្ទនានោះ។

ការប្រៀបធៀបដែលបានអនុញ្ញាតដោយគ្មានឧបករណ៍សរសេរឡើងវិញ អាចញែកវារកឱ្យឃើញការរួមចំណែករបស់វា។ ការទុកឱ្យវារំលងនៅពេលផ្ទុកលើស អាចផ្លាស់ប្តូរការនាំផ្លូវ ឬការត្រងដែលវាអនុវត្ត ដូច្នេះនោះជាជម្រើសគោលនយោបាយ។ ប្រៀបធៀបពេលរង់ចាំរបស់ជំនួយការជាមួយភស្តុតាង DNS និងការតភ្ជាប់បន្ត មុនពេលសន្មតថាការយឺតយ៉ាវទាំងអស់មកពី latency បណ្តាញ។