সাধারণ ব্রাউজার ক্যাচিংয়ের সুবিধা নিতে আমার পুরো ব্যবহারকারী চিত্রগুলির ফাইলের কাঠামোটি পরিবর্তন করা কি উপযুক্ত?

Question

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

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

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

সুতরাং আমার প্রশ্নটি হল, চিরকালীন ক্যাচিংয়ের সুবিধার্থে এবং নতুন আপলোডের পরে স্বয়ংক্রিয়ভাবে পুনরায় ডাউনলোডের সুবিধার জন্য আমার সাইটের পুরো ফাইল কাঠামোটি পরিবর্তন করা, প্লাস ডিবি উপাদান যুক্ত করা কি আমার পক্ষে উপযুক্ত?

এটি একটি বিশাল উদ্যোগ গ্রহণ, তবে এটি যদি যোগ্য হিসাবে বিবেচিত হয় তবে এই গুরুতর পরিবর্তন নিয়ে আমার এগিয়ে যাওয়ার কোনও সমস্যা নেই। আমি কেবল এটি নিশ্চিত করতে চাই যে "বড় ছেলেরা" এটি এটি করে যাতে আমাকে আর কখনও ফাইলের কাঠামো পরিবর্তন করতে হবে না।

ধন্যবাদ।

Answer 1

একটি সাধারণ ব্যবহৃত সমাধান হ'ল আপনার চিত্রের ইউআরএলগুলি এমন কিছু দেখায়:

http://www.example.com/path/to/images/1.jpg?v=123456

এখানে, /path/to/images/1.jpgচিত্রটির আসল ইউআরএল পাথ রয়েছে, যখন ?v=123456ইউআরএলটির শেষদিকে তাকানো কেবল একটি ডামি কোয়েরি। ক্যোয়ারী স্ট্রিংটি যে কোনও কিছু হতে পারে - সংস্করণ নম্বর, একটি টাইমস্ট্যাম্প, চিত্রের সামগ্রীর একটি হ্যাশ - যতক্ষণ আপনি চিত্রটি পরিবর্তন করেন না কেন এবং যখন না হয় তখন একই রাখবেন।

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

সুতরাং, আপনি আপনার ওয়েব সার্ভারটি প্রেরণের জন্য Expiresএবং Cache-Controlএইচটিটিপি শিরোনামগুলিকে অনির্দিষ্টকালের ক্যাশিংয়ের অনুমতি দেওয়ার জন্য কনফিগার করতে পারেন , এই জ্ঞানের মধ্যে নিরাপদ যে আপনি কোয়েরি স্ট্রিং পরিবর্তন করে পুনরায় লোড করতে বাধ্য করতে পারেন। এটি করার একটি উপায়, আপনি যদি Mod_expires দিয়ে অ্যাপাচি ব্যবহার করছেন .htaccessতবে লাইনগুলি সহ আপনার চিত্র ডিরেক্টরিতে একটি ফাইল রাখা:

ExpiresActive On
ExpiresDefault "access plus 1 year"

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

http://cdn.sstatic.net/stackoverflow/all.css?v=7cd8ea9d6f1e

এখানে, ?v=7cd8ea9d6f1eআমি উপরে বর্ণিত ঠিক যেমন একটি ডামি ক্যোয়ারী স্ট্রিং; আপনি এটি পরিবর্তন করে এবং সত্যই এটি এখনও একই ফাইলটি দেখায় তা নিশ্চিত করতে পারেন।

Comments

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

— প্রোগ্রামারগার্ল

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

— ইলমারি করোনেন

খুব, খুব, আকর্ষণীয়। সুতরাং আমি সম্ভবত ফাইলগুলির "সর্বশেষ সংশোধিত" সম্পত্তিটি আনতে পারি এবং ক্যোয়ারির মানটি সঠিক করে তুলতে পারি?

— প্রোগ্রামারগার্ল

হ্যাঁ, এটি কাজ করা উচিত।

— ইলমারি করোনেন

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

— ইলমারি করোনেন

Answer 2

ক্যাশে যাওয়ার একাধিক উপায় রয়েছে।

শর্তসাপেক্ষে জিইটি

আপনি যদি এই চিত্রগুলি ফাইল সিস্টেমে সংরক্ষণ করে এবং সরাসরি ওয়েব সার্ভারের মাধ্যমে সেগুলি সরবরাহ করে থাকেন তবে আপনি সম্ভবত ইতিমধ্যে শর্তযুক্ত গেট ব্যবহার করছেন । ওয়েব সার্ভার একটি স্বয়ংক্রিয়ভাবে ETAG শিরোনাম সেট করতে ফাইল সিস্টেম মেটাডেটা ব্যবহার করবে এবং ব্রাউজারের অনুরোধে শিরোনাম অন্তর্ভুক্ত থাকলে If-Modified-Sinceবা If-Matchesশিরোনামগুলি স্বয়ংক্রিয়ভাবে "304 সংশোধিত নয়" দিয়ে জবাব দেবে । (সমস্ত ব্রাউজারগুলি।)

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

নিজের ইমেজের জন্য Cache-Controlএকটি public,max-age=Nমান দিয়ে ওয়েবসারভার সেট করে দিয়ে আপনি ক্যাশে তাজাতে ব্যয় করে অনুরোধের সংখ্যাটি কিছুটা হ্রাস করতে পারেন । এটি বলে যে ক্যাশেগুলি রিসোর্সটি সর্বাধিক max-ageসেকেন্ডের জন্য রাখতে পারে তাদের আপডেট করা আছে কিনা তা পরীক্ষা করে দেখার আগে।

যাইহোক, এইচটিটিপি ক্যাশে প্রবেশকে অবৈধ করার জন্য কেবলমাত্র একটি উপায় নির্ধারণ করে, যা আপনার অ্যাপ্লিকেশনটির শব্দার্থবিজ্ঞানের সাথে মানানসই নয়: আপনি যদি কোনও পোস্টে পোষ্ট বা পুট করেন যা প্রোফাইল ফটো আপডেট করে, একটি Location: [url of photo]শিরোনাম দিয়ে উত্তর দেয় এবং সেই ইউআরএলটির ক্যাশে প্রবেশ বাতিল করা হবে।

(এই প্রক্রিয়া যে আপনার মন্তব্যের সঙ্গে একটি ওয়েবপেজ পৃষ্ঠা জোরপূর্বক ব্যবহারকারী পোস্টের পরে ব্রাউজার দ্বারা পুনরায় লোড ক্যাশে, এবং তারপর আছে মঞ্জুরি দেয় একটি নতুন মন্তব্য। ব্রাউজার একটি উত্তর হবে POST /commentসঙ্গে 303 See Otherএকটি Location: /page/with/comment। উল্লেখ্য যে, এই ব্যবহার করা হয়নি দীর্ঘদিনের ত্রুটির কারণে ফায়ারফক্সে কাজ করতে হবে ))

আপনার যদি প্রচুর ট্র্যাফিক না থাকে তবে ক্যাশিংয়ের জন্য এই পদ্ধতিটি ভাল।

ইউআরএল পরিবর্তন করা হচ্ছে

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

এর জন্য দুটি সাধারণ কৌশল রয়েছে।

ক্যারি স্ট্রিং

ওয়েব সার্ভারগুলি ফাইল সিস্টেম থেকে কোনও ফাইল পরিবেশন করার সময় ক্যোয়ারী স্ট্রিংগুলিকে উপেক্ষা করে। ক্যাশেগুলি অবশ্য তা করে না: /1.jpg?t=12345এবং /1.jpg?t=67890সার্ভারটি একইরকম মনে করে, যদিও এটি দুটি সম্পূর্ণ পৃথক, অপ্রাসঙ্গিক সংস্থান।

সুতরাং আপনি যে সহজ কাজটি করতে পারেন তা হ'ল যখনই আপনি আপনার এইচটিএমএল কোনও সংস্থার জন্য কোনও রেফারেন্স তৈরি করেন এবং একটি দীর্ঘ Expiresশিরোনাম সেট করে থাকেন তখন কোয়েরি স্ট্রিং হিসাবে ফাইল সিস্টেম টাইমস্ট্যাম্প যুক্ত করুন । তারপরে ব্রাউজারটি এই সংস্থানটি চিরতরে ক্যাশে করে দেবে এবং যতক্ষণ না কোয়েরি স্ট্রিং পরিবর্তন না হয় ততক্ষণ কোনও জিইটিগুলি করবে না।

একটি খারাপ দিক হ'ল যদি আপনি কোনও ক্যাশে জোর করে অকার্যকর করতে চান তবে কোনও আইটেমটির জন্য নতুন ইউআরএলটির ওয়েবসারভারকে নির্দেশ দেওয়া কঠিন বা অসম্ভব। উদাহরণস্বরূপ, যদি কোনও ব্রাউজারের কোনও /1.jpg?v=1রেফারেন্স সহ ক্যাশেড এইচটিএমএল পৃষ্ঠা থাকে তবে এর জন্য এন্ট্রিটি সাফ করার জন্য ঘটেছে /1.jpg?v=1(সম্ভবত এটি ফাইল বা মেমরির জায়গার বাইরে চলে গেছে), এটি একটি নতুন অনুরোধ জানাবে /1.jpg?v=1। এর মধ্যে যদি চিত্রটি পরিবর্তিত হয় /1.jpg?v=2তবে সঠিক প্রতিক্রিয়া হয়:

1. ফাইলটির পুরানো সংস্করণ পরিবেশন করুন। আপনি যদি এই মুহূর্তে একটি নির্দিষ্ট মুহুর্তে সমস্ত সংস্থানগুলি একে অপরের সাথে সামঞ্জস্যপূর্ণ থাকতে চান তবে আপনি এটি করতে পারেন। সিএসএস ফাইলগুলির সাথে আপনার এটি করা উচিত, উদাহরণস্বরূপ, কোনও পুরানো এইচটিএমএল ফাইল সহ একটি নতুন সিএসএস ফাইল সঠিকভাবে কাজ করতে পারে না!
2. ব্যবহার করে ফাইলের নতুন সংস্করণে পুনর্নির্দেশ করুন 301 Moved Permanently। আপনি যদি এটি চান যে সমস্ত সংস্থান যথাসম্ভব নতুন হতে পারে।

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

ফাইলের নাম

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

Answer 3

HTTP স্থিতি সম্পর্কে পড়ুন 304 Not Modified, আপনার 304 দিয়ে একটি ডাউনলোডের অনুরোধের প্রতিক্রিয়া জানাতে সক্ষম হওয়া উচিত এবং এটির মাধ্যমে সার্ভারকে ব্রাউজারে এটি পুনরায় পাঠানোর জন্য জোর দেওয়া ক্যাশেড ডেটা ব্যবহার করতে বলা উচিত। এবং এই প্রশ্নটি পড়ুন /programming/2978496/make-php-page-return-304-not-modified-if-it-hasnt-been- Modified

Comments

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

— প্রোগ্রামারগার্ল

আমি এর সাথে এতটা পরিচিত নই, ভাবুন ফ্রান্সিস

— অবিলা এ