Paylaşılan .NET IWebProxy paralel sorğular üçün təhlükəsizdirmi?

IWebProxy proksi siyasətini təsvir edir. O, hər tətbiqə eyni paralellik təminatlarını vermir. Bir instansı işçi tapşırıqları arasında paylaşmazdan əvvəl onun konkret tətbiqini və aid olduğu işləmə mühitini müəyyən edin.

İnterfeys təyinatdan asılı marşrut sorğuları və etimadnamələr təqdim edir. Fərdi tətbiq sabit ünvana, dəyişən vəziyyətə və ya avtomatik konfiqurasiyaya müraciət edə bilər. Bu seçimlər həm təhlükəsizliyə, həm də məhsuldarlığa təsir edir.

Konfiqurasiya dəyişikliklərini sorğu emalından kənarda saxlayın

Bir paylaşılan proksi obyektini qaralama vərəqi kimi istifadə etməkdən çəkinin: A işi üçün onun ünvanını və ya etimadnamələrini dəyişmək, B işi isə marşrut seçərkən sahibliyi qeyri-müəyyən edir. Siyasəti müştəriyə verməzdən əvvəl konfiqurasiya edin. Fərqli proksi hesabları və ya son nöqtələri olan yüklər üçün ayrı-ayrı sahiblikdə olan müştəri konfiqurasiyaları istifadə edin.

Tarixi WebProxy sənədləri instans üzvləri üçün thread-təhlükəsizlik təminatı vermirdi. Bu müqaviləni uyğun tətbiqə şamil edin. Sinxronizasiya tələb olunursa, hər oxucu və yazıçı iştirak etməlidir; sarğı kilidi orijinal obyekti birbaşa istifadə edən çağıranları əlaqələndirə bilməz.

GetProxy daxilində uzun fasilə bunun əvəzinə aşkarlanma və ya PAC qiymətləndirməsi ilə bağlı ola bilər. Microsoft WinHTTP üçün bloklayıcı aşkarlanmanı sənədləşdirir; müştəri həmin backend-dən istifadə etdikdə bu izah tətbiq olunur. Marşrut axtarışını bağlantı və cavab vaxtından ayrıca ölçün. Yavaş axtarışı ardıcıllaşdırmaq sadəcə növbə yarada bilər.

Sabit son nöqtə, sabit marşrut nəzərdə tutulduqda aşkarlanmanı aradan qaldıra bilər. Dəyişən sistem siyasətindən bir URI tutmaq da onun gələcək qərarlarını atır. Köhnə kodu saxlayarkən bu fərqi qoruyun; yeni HTTP işləri üçün HttpClient və onun dəstəklənən handler konfiqurasiyasından istifadə edin.