আমার এইচটিএমএল লোড হওয়ার আগে 'অপেক্ষা' সময়টির কারণ কী?


12

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

আপনি হলুদ 'অপেক্ষার সময়' বারগুলির নীচে ছবিটিতে দেখতে পারেন:

এইচটিএমএল ফাইলটি লোড করাতে 5 সেকেন্ডেরও বেশি সময় লেগেছিল, অন্যদিকে অন্যান্য সম্পদের বেশিরভাগই 1 সেকেন্ডের নিচে লোড হয়

পৃষ্ঠার এইচটিএমএল বিষয়বস্তু কী তা বিবেচনা করেই এটি সংবেদনশীল বলে মনে হচ্ছে।

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

কেউ কি জানতে পারে কী কারণে এটি ঘটছে এবং আমি কীভাবে এটির গতি বাড়িয়ে দিতে পারি?


এই একটি নতুন জিনিস? অর্থাত, এই পৃষ্ঠাগুলি আগে সাধারণত সম্পাদিত হয়েছিল এবং এখন খারাপ অভিনয় করে? অথবা এটি কি নতুন ইনস্টল / সাইট? আপনি আমাদের আরো বলতে পারেন?
ক্লোজটোক

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

1
আইএমও সমস্যাটি মূলত সেই এক পৃষ্ঠার সাথে থাকে - আপনার সার্ভার / সিএমএস প্রতিক্রিয়া তৈরি করতে অনেক সময় নিচ্ছে বলে মনে হচ্ছে। অপর্যাপ্ত এসকিউএল কোয়েরি ?? আপনার সাইটের অন্যান্য পৃষ্ঠা অপেক্ষাকৃত দ্রুত বলে মনে হচ্ছে। (?)
মিঃ হোয়াইট

উত্তর:


13

অপেক্ষার জন্য প্রযুক্তিগত শব্দটি প্রথম বাইট করার সময় হিসাবে উল্লেখ করা হয় এবং একটি ওয়েব সার্ভার বা অন্যান্য নেটওয়ার্ক সংস্থানগুলির প্রতিক্রিয়াশীলতা নির্ধারণ করে।

কিছু সাধারণ কারণ যা আপনি প্রথমে বাইট করার জন্য একটি উচ্চ সময় দেখতে পারেন:

  • ওভারলোডেড নেটওয়ার্ক (সাধারণত শেয়ারিং হোস্টিং)
  • ভুল কনফিগারেশন সার্ভার
  • আপনার এবং সার্ভারের থেকে দূরত্ব (জিও অবস্থানটি একটি গৌণ ভূমিকা পালন করে)
  • সার্ভার ত্রুটি (হप्स)

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

একটি নতুন হোস্ট পেতে সময় হতে পারে

অতীতে আমাকে সার্ভার থেকে সার্ভারে যেতে হয়েছিল কারণ প্রথম বাইটে সময় পিছিয়ে যাওয়ার কারণে আপনি একটি নতুন ওয়েব হোস্ট চয়ন করতে বা আপনার বর্তমান প্যাকেজটি আপগ্রেড করার পরিস্থিতিতে থাকতে পারেন।

নির্ভরযোগ্য পরীক্ষা

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

সার্ভারটিতে পিংিং এবং ট্রেস রুট

আপনি যদি সার্ভারে পিং চালানোর চেষ্টা করেন তবে ফলাফলগুলি প্রদর্শিত হতে পারে বা নাও পারে, পিং ইউডিপি বা টিসিপির পরিবর্তে আইসিএমপি ব্যবহার করে যার অর্থ এটি আপনার পোর্ট ৮০ এ সার্ভারের অনুসন্ধানের মতো নয় যা আপনার httpd চালু থাকবে। প্রথম বাইট বাড়ানোর কারণ হতে পারে এমন রুটে যে কোনও সার্ভার শনাক্ত করার জন্য আপনি ট্রেস রুট ব্যবহার করতে পারেন ... এটি পোর্ট ৮০ তে httpd সার্ভারটি জিজ্ঞাসাবাদ করে না এবং উইন্ডোজ ব্যবহার করে যদি ট্রেস্রোয়েট ব্যবহার করে এটি আইসিএমপি এবং ম্যাক / লিনাক্স ব্যবহার করবে মেশিনগুলি ইউডিপি ব্যবহার করবে। এটি পরীক্ষা করার মতো কারণ এটির মতো দ্রুত এবং সহজ কাজ তবে ফলাফল যদি ভালভাবে ফিরে আসে তবে প্রয়োজনীয়তা নেই কোথাও কোনও সমস্যা নেই।


হাই হাই সুনডকিম আপনি আমার জিজ্ঞাসা দিয়ে আমার উত্তর আপডেট করেছেন। আমার উত্তরের নীচে তাকান।
সাইমন হাইটার

আমি প্রথম বাইট করার জন্য আপনার সাধারণ কারণে একমত। এই উদাহরণে, তবে; আমি বিশ্বাস করি জাভাস্ক্রিপ্ট কোডটির সাথে এর আরও অনেক কিছু আছে।
সান

প্রথম বাইটটি বিস্তৃত জিনিসের কারণে ঘটতে পারে তবে জাভাস্ক্রিপ্ট সেগুলির মধ্যে একটি নয় কারণ শিরোনামের প্রতিক্রিয়াটি জাভাস্ক্রিপ্ট, সিএসএস, চিত্রগুলি ইত্যাদির মতো ইনলাইন উপাদানগুলির আগে। প্রথম বাইটকে প্রকৃত উপাদান এবং ফাইলগুলির সাথে গুলিয়ে ফেলবেন না ..
সাইমন হায়টার

আমি দুজনকে বিভ্রান্ত করছি না। আপনি যদি mbff.com.au পরিদর্শন করেছেন এবং নিজের জন্য দেখে থাকেন তবে আপনি নিশ্চিত হতে পারেন যে এটি প্রথম বাইট করা সময়ের বিষয় নয়। প্রথম শিরোনামের প্রতিক্রিয়ার পরে বিলম্ব হচ্ছে।
সূর্য

1
The delay is occurring after the first header responseতারপর যে প্রথম বাইট না। প্রথম বাইট প্রথম প্রতিক্রিয়া।
সাইমন হাইটার

4

1) আপনার কাছে অ্যাডোব টাইপকিট রয়েছে যা বর্তমান কোডের সাথে অবিচ্ছিন্নভাবে লোড হচ্ছে না। উন্নত অ্যাসিনক্রোনাস কোড দিয়ে এটি প্রতিস্থাপনের চেষ্টা করুন: http://help.typekit.com/customer/portal/articles/649336-ebed- কোড

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

2) নতুন টাইপকিট দিয়ে পরীক্ষা করুন। এখন লোডিংয়ের সময় কেমন? উত্তম? পদক্ষেপ 3 এ যান।

3) আপনার গুগল অ্যানালিটিক্সগুলিকে আপডেট হওয়া জাভাস্ক্রিপ্ট দিয়ে প্রতিস্থাপন করুন যা সর্বশেষতম অ্যাসিনক্রোনাস সিনট্যাক্স সরবরাহ করে: https://developers.google.com/analytics/devguides/collection/gajs/

4) পরীক্ষা। পৃষ্ঠাটি লোড করা এখনও আরও ভাল?

৫) অবশেষে, প্যাটার্ন.জেপিজির মতো চিত্রগুলি অনুকূল করে তোলার বিষয়ে বিবেচনা করুন। আমি এটিকে পিএনজিতে রূপান্তর করেছি এবং 199kB থেকে 56 কেবি ফাইলের আকার হ্রাস করতে সক্ষম হয়েছি। এটি ফাইলটি পাওয়ার সময়টি হ্রাস করে: https://www.DPboxbox.com/s/i06jx509bmprhhh/pattern.png?dl=0

আশা করি এটা কাজে লাগবে.


3

পিএইচপি বনাম-পিএইচপি উপাদানসমূহ

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

এটি সাধারণত আপনার পিএইচপি স্ক্রিপ্টের অভ্যন্তরীণ সমস্যাগুলি নির্দেশ করে।

সমস্যাটি পিএইচপি স্তর বা ডাটাবেসের মধ্যে থাকতে পারে। এক্সডেবগ বা নিউরেলিকের মতো উন্নত ডিবাগিং সরঞ্জামগুলি ব্যবহার করা আপনাকে দ্রুত বাধাটি খুঁজে পেতে সহায়তা করতে পারে।

হার্ডওয়্যার সীমাবদ্ধতা, দুর্বল কনফিগারেশন বা অক্ষম কোডের কারণে প্রথম বাইট সমস্যার সময় হতে পারে। ভাগ করা হোস্টিংয়ে, হার্ডওয়্যার সীমাবদ্ধতা এবং দুর্বল কনফিগারেশন সম্ভবত are

যাই হোক না কেন, সমস্যা সমাধানের অর্থ সাধারণত এক বা সমস্ত:

  • আরও হার্ডওয়্যার
  • আরও ভাল প্রোগ্রামিং
  • ক্যাচিং যুক্ত করুন

যদি আপনি ইতিমধ্যে উত্সর্গীকৃত উত্সগুলিতে থাকেন তবে দ্রুত হার্ডওয়্যার একটি সুস্পষ্ট তবে প্রায়শই ব্যয়বহুল সমাধান।

আপনি যদি বিকাশকারী সংস্থানগুলি বজায় না রাখেন না বা অভাবের কোডের অভ্যন্তরীণ সমস্যাটি থাকে তবে আরও ভাল প্রোগ্রামিং সম্ভব না possible

ক্যাচিং অনুরোধের সংখ্যা হ্রাস করে সহায়তা করে যা অবশ্যই অন্তর্নিহিত, দুর্বল সম্পাদনকারী সংস্থানগুলিতে আঘাত করতে হবে।

পরীক্ষামূলক

পরীক্ষার সরঞ্জামগুলি ব্যবহার করার সময় একাধিক রান করতে ভুলবেন না। নেটওয়ার্ক এবং অস্থায়ী সার্ভার স্পাইকগুলি আপনাকে সহজেই ভুল পথে পরিচালিত করতে পারে, তাই আপনি এগুলি গড়ার চেষ্টা করতে চান।

হোস্টিং

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


-1

তৃতীয় পক্ষের কুকিগুলি কেবলমাত্র দেখার জন্য সেট করার চেষ্টা করুন।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.