ক্রোম https সাইটগুলি বিশেষত অভ্যন্তরীণগুলিতে ধীর করে


8

আমরা আমাদের কর্পোরেট নেটওয়ার্ক জুড়ে গুগল ক্রোম মোতায়েন করার চেষ্টা করছি, তবে আমরা খুঁজে পেয়েছি যে আইইয়ের তুলনায় একটি https পৃষ্ঠা লোড করতে 2-4X বেশি সময় লাগে (বিশেষত আমাদের নিজস্ব অভ্যন্তরীণগুলি)। কেউ কি এই অভিজ্ঞতা পেয়েছে এবং এর সমাধান খুঁজে পেয়েছে?

হালনাগাদ

হ্যান্ডিম্যান 5 এর পরামর্শের ভিত্তিতে, আমি ক্রোমে কিছু ডায়াগনস্টিকস চালিয়েছি এবং দেখেছি সর্বাধিক পরিমাণে (প্রতিটি পৃষ্ঠায় 90% এর বেশি) ক্যাশে থেকে স্থির ফাইলগুলি টানতে এবং পৃষ্ঠাটি রেন্ডার করতে ব্যয় করা হচ্ছে। তবে, আমি যদি আমাদের সাইটে এসএসএল বন্ধ করি তবে এটি প্রায় তাত্ক্ষণিক।

কেন এমন হবে তা নিয়ে কোনও চিন্তা?


আপনি একটি tcpdump ট্রেস যোগ করতে পারেন? এটা সত্যিই সাহায্য করবে। আপনি কি আপনার নেটওয়ার্কে আইপিভি 6 চালিয়ে যাচ্ছেন? আমি মাঝে মাঝে এই সমস্যাটি নিয়ে আসি যেখানে
সিসাদমিন

আমরা আইপিভি 6 চালাচ্ছি না এবং আমি মনে করি না যে আমরা সরাসরি সাইটটিতে অ্যাক্সেস করছি (যেমন https: // 192.168.0.33/) ডিএনএস রেকর্ডগুলি প্রযোজ্য। আমি কোনও ট্রেস পোস্ট করতে পারি কিনা তা দেখার জন্য আমি ডেস্কটপে ওয়্যারশার্ক বা অনুরূপ সরঞ্জাম ইনস্টল করার চেষ্টা করব।
বীপ বীপ

আপনি ডিএনএস সার্ভারগুলি কী ব্যবহার করেন /
ওয়ারেন

অভ্যন্তরীণ ডিএনএস, ভেরাইজন বা আইপি ঠিকানার মাধ্যমে সাইটটি অ্যাক্সেস করার সময় কোনও বিষয় মনে হচ্ছে না।
বীপ বীপ

উত্তর:


18

ক্রোমের একটি দুর্দান্ত বিল্ট-ইন ডায়াগনস্টিক সরঞ্জাম রয়েছে, "সম্পর্কে: নেট-ইন্টারনালস" , যা নেটওয়ার্ক সমস্যা সমাধানের জন্য ডিজাইন করা হয়েছে। বিশেষত, এটিতে "ইভেন্টস" ট্যাব রয়েছে যা আপনাকে একটি ইউআরএল নির্দিষ্ট করতে দেয় এবং তারপরে ক্রোম এটি লোড করার পুরো প্রক্রিয়াটি ভেঙে দেয়, ধাপে ধাপে, ডিএনএস রেজোলিউশন, ক্যাশে হিট এবং এজেএক্স উপাদানগুলির অনুরোধগুলি সহ।


বাহ, এই সম্পর্কে কখনই জানতাম না। আমি চেষ্টা করে দেখুন, ধন্যবাদ!
বীপ বীপ

অদ্ভুত ... আমি অবাক হয়েছি যে Chrome এর চেয়ে নিরাপদ সাইটগুলিতে ক্যাশিং পরিচালনা করে? ক্রোমের বিকাশকারীদের সরঞ্জামগুলিতে এটি এবং টাইমলাইনটি চালানোর পরে, এটি প্রদর্শিত হয় যে দীর্ঘতম সময়টি ক্যাশে থেকে স্থির ফাইলগুলি প্রক্রিয়াকরণে ব্যয় করা হচ্ছে। কোনও সুরক্ষিত সাইটে, এটি কেস নয় - এটি প্রায় তাত্ক্ষণিকভাবে ক্যাশে ফাইলগুলি টান দেয়। উদাহরণস্বরূপ, একটি ছোট পৃষ্ঠায় পৃষ্ঠা থেকে গতিশীল সামগ্রী পেতে 100 মিমি লেগেছিল, তবে ক্যাশে থেকে জাভাস্ক্রিপ্ট টানতে আরও 1.9 সেকেন্ড সময় লাগবে। আইই তে, এই পৃষ্ঠাটি .5 সেকেন্ডেরও কম সময়ে খোলে এবং আমি এসএসএলটি বন্ধ করে দিলে এটি ক্রোমে আরও দ্রুত খোলে।
বীপ বীপ

বৈশিষ্ট্য সরানো হয়েছে। ইভেন্টগুলি ট্যাবে নিম্নলিখিত পাঠ্যটি ছড়িয়ে দেওয়া হয়েছে: নেট-ইন্টারনাল ইভেন্ট ইভেন্ট এবং সম্পর্কিত কার্যকারিতা সরানো হয়েছে। নেটলোগগুলি সংরক্ষণ করতে দয়া করে ক্রোম: // নেট-রফতানি এবং সেগুলি দেখার জন্য বাহ্যিক ক্যাটালপাল নেটলগ_ভিউয়ার ব্যবহার করুন।
এমহেল্ড

8

tl; dr কীভাবে ক্রোম শংসাপত্রের পরীক্ষা এবং বাতিলকরণ পরিচালনা করে Check

আমি আগে যেখানে কাজ করেছিলাম এমন একটি সুবিধায় আমাদের খুব অনুরূপ সমস্যা ছিল তবে ফায়ারফক্সের সাথে। এটি ইস্যু হওয়ার জন্য, আপনাকে কেবল https পৃষ্ঠাগুলির সাথেই বিষয়টি নিশ্চিত করতে হবে। যদি তা না হয় তবে এতে সামান্য পার্থক্য হবে।

ফায়ারফক্সের সাথে (আমি জানি, আমি পড়তে পারি, আগামিটি নির্দেশ করতে পারি), ইন্টারনেট এক্সপ্লোরার ব্যবহারকারীরা (যদি আপনি এটি বিশ্বাস করতে পারেন) তা করেন নি, এমন সময় অনেক লোকের সমস্যা ছিল issues আমরা কুখ্যাত আইপিসিএ কর্তৃপক্ষ ব্যবহার করেছি কারণ তারা শিক্ষাপ্রতিষ্ঠানের জন্য নিখরচায় ছিল, তবে শেষ পর্যন্ত ফায়ারফক্সকে তাদের লজ্জায় আচ্ছন্ন করে দিয়েছিল এবং তাদের শংসাপত্রগুলির ওসিএসপি চেক করা অপরাধী ছিল । আমাদের SSL শংসাপত্রগুলির প্রকৃতির কারণে শংসাপত্র প্রত্যাহার তালিকাগুলি প্রক্রিয়াকরণের কারণে ব্রাউজারটি বিলম্বিত হচ্ছে। আপনি অবশ্যই আমাদের সেরা হিসাবে আপনার ক্রোম সংস্করণটির উল্লেখ করেন নি, তাই এটি কোনও সমস্যা ছিল কিনা তা বলা শক্তবা এখনও একটি বিষয়। তবে আমি ক্রোমে সিআরএল কনফিগারেশন চেক করব। ফায়ারফক্সে এটি করা সমস্যার সমাধান করে। এছাড়াও, আপনার শংসাপত্রগুলি ভাল অবস্থানে রয়েছে কিনা তা পরীক্ষা করুন, সেগুলি যদি স্ব-স্বাক্ষরিত হয়। এটি কী ব্যবহারে তা দিয়েছিল তা হ'ল আমরা স্ব-স্বাক্ষর থেকে সরে এসেছি কারণ আমাদের পরিষেবাগুলির বোকা ব্যবহারকারীরা প্রচুর পরিমাণে ঝকঝকে হয়েছিলেন এবং এটি নিখরচায় ছিল। আমরা ভেবেছিলাম যে আমরা নিজেরাই মাথাব্যথা রক্ষা করছি, তবে আমরা এটিকে আরও খারাপ করে দিয়েছি।


ভাল চিন্তা - আমাদের অভ্যন্তরীণ অ্যাপ্লিকেশনগুলি এখনও বিকাশে এবং স্ব-স্বাক্ষরিত রয়েছে, তাই সম্ভবত এটিই সমস্যা। আমরা একটি সত্যিকারের শংসাপত্র কিনব, সম্ভবত এটি কোনও পার্থক্য আনবে।
বীপ বীপ

ঠিক আছে, তাহলে উপেক্ষা করুন। এই সমস্যাটি সত্যিকারের সিএ থেকে স্বাক্ষরিত শংসাপত্রগুলির সাথে থাকবে, তবে সিএ কৃপণ হয়ে উঠেছে। সম্ভবত এটি তখন আপনার সমস্যা নয়।
songei2f

আমরা এখনও এটি চেষ্টা করব, আমি প্রতিক্রিয়াটির প্রশংসা করি
বীপ বীপ

2

আমরা কাস্টম উন্নত অ্যাপ্লিকেশনটিকে সমর্থন করার জন্য গুগল ক্রোমকে অভ্যন্তরীণভাবে মোতায়েন করেছি (এএসপি.নেট এমভিসি তে) তবে সাধারণ এইচটিটিপিতে চলছে।

ক্যাশে থাকায় আমাদের ধীর পৃষ্ঠাগুলি নিয়েও সমস্যা ছিল। দেখে মনে হচ্ছে ক্রোম প্রতিটি পৃষ্ঠা লোডে সমস্ত স্থিতিশীল ফাইলগুলি টানছিল এবং এটিকে তার ক্যাশে সংরক্ষণ করছে না। ক্যাশে বাধ্য করার জন্য আমরা আমাদের অ্যাপ্লিকেশনটিতে কেবল শিরোনামের মেয়াদ শেষ করে দিয়েছি এবং তা কাজ করেছে।

আপনি সেই রাস্তায় যেতে পারেন (প্রতিটি ধরণের ফাইলের জন্য ক্যাচিং কৌশল নির্দিষ্ট করতে আপনার ওয়েব অ্যাপ্লিকেশনগুলিকে সংশোধন করতে পারেন), বা ক্রোমের ডিফল্ট ক্যাচিং আচরণটি তদন্ত করতে পারেন।

অন্যদের কাছে একই সমস্যা রয়েছে বলে মনে হয় (যেমন: http://www.google.com/support/forum/p/Chrome/thread?tid=741fd9e03cfb7e7b&hl=en )।

এই নিবন্ধটি কার্যকর হতে পারে কারণ এটি ক্রোম ক্যাচিংয়ের ক্ষেত্রে প্রাইমার সরবরাহ করে: http://gent.ilcore.com/2011/02/chromes-10-caches.html


আমাদের সমস্যাটি এই নয় যে ফাইলগুলি পুনরায় সংক্রমণ করা হচ্ছে, বরং এটির পরিবর্তে ক্যাশেড ফাইলগুলি (ক্লায়েন্ট-সাইড মেমরির) থেকে আঁকা সত্যিই ধীর is আমি অনুমান করি যে আমাদের অভ্যন্তরীণ ব্যবহারকারীরা আইই ব্যবহার করতে পারবেন।
বীপ বীপ

2

আমি একই ইস্যুতে চলছিলাম। দীর্ঘ সময় অনুসন্ধানের পরে আমি প্রক্রিয়া মনিটরের সরঞ্জাম ( https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx ) দিয়ে জানতে পেলাম যে ক্রোম% TEMP% এ লেখার চেষ্টা করে অনেক সংঘর্ষে ছড়িয়ে পড়ে। এই ডিরেক্টরিটি সাফ করা আমার জন্য সমস্যাটি সমাধান করেছে।


1
আমার জন্যও সমস্যাটি স্থির করে
জাকব ক্রুস 24'17

1

শেষ পর্যন্ত, আমি এখানে একটি উত্তর খুঁজে পাইনি। সমস্ত পর্যবেক্ষণ এবং প্রোফাইলিং পরীক্ষাগুলি দেখায় যে গুগল ক্রোম স্থানীয় ক্লায়েন্ট ক্যাশে থেকে সুরক্ষিত স্ট্যাটিক সামগ্রী লোড করার ক্ষেত্রে খুব ধীর slow কেন জানি না। আমাদের সমস্ত অভ্যন্তরীণ ব্যবহারকারীদের আইই-তে স্যুইচ করতে হয়েছিল (যা ওয়েবে একই ধরণের সমস্যাযুক্ত বেশিরভাগ লোকেরা করেছিলেন)।


0

যদি ব্যাকএন্ড জাভা ভিত্তিক অ্যাপসভার হয় তবে একটি সাধারণ জাভা বাগ রয়েছে যার কারণে টিএলএস সেশন টিকিটগুলি একটি বিশাল বিলম্ব ঘটায়। আপনি একটি সত্যই নতুন ওপেনসেল এস_স্লায়েন্ট ব্যবহার করে এবং সেশন টিকিট সক্ষম / অক্ষম করতে বলার মাধ্যমে বাগটি অনুকরণ করতে পারেন।

আসল অপরাধী হ'ল জেএসএসই বনাম টিএলএস এক্সটেনশনগুলি নাল মান সহ, যা প্রথম অনুরোধে সেশন টিকিট ব্যবহার করে।


এর শেষ প্রান্তটি হ'ল এএসপি.নেট এমভিসি।
বীপ বীপ

0

আপনার সার্ভারের এলোমেলো ডেটা শেষ হওয়ার কোনও সম্ভাবনা নেই। লিনাক্সের অধীনে আপনি যদি /dev/randomএলোমেলো ডেটা ব্যবহার করেন এবং রান আউট করেন তবে আপনার সার্ভারটি ব্লক হয়ে যাবে এবং পৃষ্ঠাটির লোডটি হ্যাং হয়ে যাওয়ার মতো দেখাবে।

সাধারণত /dev/urandomযথেষ্ট ভাল। যদি এটি না হয় তবে কিছু হার্ডওয়্যার আপনি পেতে পারেন যা আপনার জন্য এলোমেলো ডেটা তৈরি করবে।

আমি দেখতে পাচ্ছি আপনি এএসপি। নেট চালাচ্ছেন - আমি উইন্ডোতে ইস্যু হওয়া ওয়েদার সম্পর্কে মন্তব্য করতে পারি না, তবে নজর দেওয়া উচিত।


এটি ভাববেন না, যেহেতু এটি কেবল ক্রোমে রয়েছে (এবং কিছুটা ফায়ারফক্সেও)। আইই বা আমাদের ব্রাউজারে এইচটিটিপিএস বন্ধ থাকলে আমাদের সাইটটি নির্লজ্জভাবে দ্রুত। এটি ক্লায়েন্ট-সাইড ক্যাশে থেকে ডেটা টানানোর সাথে সম্পর্কিত বলে মনে হচ্ছে। এইচটিটিপিএস সাইটের জন্য ক্রোম খুব ধীরে ধীরে কাজ করে তবে দ্রুত অনন-https এর জন্য। আমার কাছে কোনও ধারণা রাখে না।
বীপ বীপ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.