অনেক ক্লায়েন্টের মধ্যে বিশাল সংগ্রহ ভাগ করে নেওয়ার ক্ষেত্রে মেটিয়ার কতটা দক্ষ হতে পারে?


100

নিম্নলিখিত ক্ষেত্রেটি কল্পনা করুন:

  • "সামস্টাফ" সংগ্রহের বিষয়বস্তু প্রদর্শন করে 1,000 টি ক্লায়েন্ট একটি উল্কা পৃষ্ঠার সাথে সংযুক্ত আছেন।

  • "সামস্টাফ" হ'ল এক হাজার আইটেম ধারণ করে।

  • কেউ কেউ "সামস্টাফ" সংগ্রহের মধ্যে একটি নতুন আইটেম সন্নিবেশ করান

কি হবে:

  • সকল Meteor.Collectionক্লায়েন্ট গুলি সন্নিবেশ তাদের সব (যা 1000 ক্লায়েন্ট পাঠানো এক সন্নিবেশ বার্তা মানে) পাঠানো অর্থাত আপডেট করা হবে

কোন ক্লায়েন্ট আপডেট করা প্রয়োজন তা নির্ধারণ করার জন্য সার্ভারের সিপিইউ-এর মেয়াদে কত খরচ হবে?

এটি কি সঠিক যে কেবল সন্নিবেশিত মানটি ক্লায়েন্টদের কাছে পাঠানো হবে, এবং পুরো তালিকাটি নয়?

বাস্তব জীবনে এই কাজ করে কীভাবে? এই জাতীয় স্কেলের কোনও মানদণ্ড বা পরীক্ষা-নিরীক্ষা কি পাওয়া যায়?

উত্তর:


119

সংক্ষিপ্ত উত্তরটি হ'ল কেবল নতুন ডেটা কেবল তারের মাধ্যমে প্রেরণ হয়। এখানে কিভাবে এটা কাজ করে.

মেটিওর সার্ভারের তিনটি গুরুত্বপূর্ণ অংশ রয়েছে যা সাবস্ক্রিপশন পরিচালনা করে: প্রকাশের ফাংশন , সাবস্ক্রিপশনটি কী ডেটা সরবরাহ করে তা যুক্তির সংজ্ঞা দেয়; মোঙ্গো চালক , যা পরিবর্তনের জন্য ডাটাবেসের ঘড়ির; এবং মার্জ বাক্স , যা ক্লায়েন্টের সমস্ত সক্রিয় সাবস্ক্রিপশনগুলির সাথে একত্রিত হয় এবং তাদের ক্লায়েন্টকে নেটওয়ার্কের বাইরে প্রেরণ করে।

ফাংশন প্রকাশ করুন

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

যদিও বেশিরভাগ প্রকাশিত ফাংশনগুলিকে নিম্ন-স্তরের added, changedএবং removedএপিআই -এর সাথে ঘৃণা করতে হবে না । একটি ফাংশন আয় একটি মোঙ্গো কার্সার প্রকাশ পারেন, উল্কা সার্ভার স্বয়ংক্রিয়ভাবে মোঙ্গো ড্রাইভার (আউটপুট সংযোগ insert, updateএবং removedএকত্রীকরণ বাক্সের ইনপুট callbacks) ( this.added, this.changedএবং this.removed)। এটি বেশ ঝরঝরে যে আপনি কোনও প্রকাশনা ফাংশনে সমস্ত অনুমতি পরীক্ষা করে নিতে পারেন এবং তারপরে কোনও ব্যবহারকারীর কোড ছাড়াই ডাটাবেস ড্রাইভারটিকে সরাসরি মার্জ বাক্সে সংযুক্ত করতে পারেন। এবং যখন অটোপলিশ চালু হয়, তখনও এই সামান্য কিছুটা লুকানো থাকে: সার্ভারটি স্বয়ংক্রিয়ভাবে প্রতিটি সংগ্রহের সমস্ত নথির জন্য একটি কোয়েরি সেট করে এবং সেগুলি মার্জ বাক্সে ঠেলা দেয়।

অন্যদিকে, আপনি ডাটাবেস অনুসন্ধানগুলি প্রকাশের মধ্যে সীমাবদ্ধ নন। উদাহরণস্বরূপ, আপনি এমন একটি প্রকাশিত ফাংশন লিখতে পারেন যা কোনও এর অভ্যন্তরে কোনও ডিভাইস থেকে জিপিএস পজিশন পড়তে পারে Meteor.setInterval, বা অন্য ওয়েব পরিষেবা থেকে একটি উত্তরাধিকার সূত্রে পুনরায় পোস্ট করুন API সেই ক্ষেত্রে, আপনি নিম্ন স্তরের কল করে একত্রীকরণ বক্স পরিবর্তন নির্গত চাই added, changedএবং removedDDP API- টি।

মঙ্গো ড্রাইভার

মোঙ্গো ড্রাইভারের কাজ লাইভ প্রশ্নের পরিবর্তনের জন্য মোঙ্গো ডাটাবেসের দেখার জায়গা। এই প্রশ্নের ক্রমাগত চালাতে এবং কল করে ফলাফল পরিবর্তন আপডেট আসতে added, removedএবং changedcallbacks।

মঙ্গো কোনও আসল সময়ের ডাটাবেস নয়। সুতরাং ড্রাইভার পোল। এটি প্রতিটি সক্রিয় লাইভ ক্যোয়ারির জন্য শেষ ক্যোয়ারী ফলাফলের একটি মেমরি অনুলিপি রাখে। প্রতিটি পোলিং চক্র, এটি পূর্ববর্তী সংরক্ষিত ফলাফল নিয়ে নতুন ফলাফল তুলনা, কম্পিউটিং ন্যূনতম সেট added, removedএবং changed ঘটনা পার্থক্য বর্ণনা। যদি একাধিক কলার একই লাইভ ক্যোয়ারির জন্য কলব্যাকগুলি নিবন্ধভুক্ত করে, ড্রাইভার কেবল একই ফলাফলের সাথে প্রতিটি নিবন্ধিত কলব্যাককে কল করে ক্যোয়ারীর একটি অনুলিপি দেখে।

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

মার্জ বক্স

কাজ একত্রীকরণ বক্স ফলাফল (একত্রিত হয় added, changedএবং removed একটি একক তথ্য প্রবাহ মধ্যে একটি ক্লায়েন্টের সক্রিয় ফাংশন প্রকাশ সমস্ত কল)। প্রতিটি সংযুক্ত ক্লায়েন্টের জন্য একটি একত্রীকরণ বাক্স রয়েছে। এটিতে ক্লায়েন্টের মিনিমোঙ্গো ক্যাশেটির একটি সম্পূর্ণ অনুলিপি রয়েছে।

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

কেননা মার্জ বক্সটি ক্লায়েন্টের রাজ্য ধারণ করে, এটি প্রতিটি ক্লায়েন্টকে টু ডেট রাখার জন্য সর্বনিম্ন পরিমাণের ডেটা প্রেরণ করতে পারে, কোনও প্রকাশনা ফাংশনই তা খাওয়ায় তা বিবেচনা করে না।

একটি আপডেটে কি ঘটে

সুতরাং এখন আমরা আপনার দৃশ্যের জন্য মঞ্চ নির্ধারণ করেছি।

আমাদের 1000 টি সংযুক্ত ক্লায়েন্ট রয়েছে। প্রত্যেকে একই লাইভ মঙ্গো ক্যোয়ারিতে সাবস্ক্রাইব করা হয়েছে ( Somestuff.find({}))। যেহেতু প্রতিটি ক্লায়েন্টের জন্য ক্যোয়ারি একই, তাই ড্রাইভারটি কেবল একটি লাইভ কোয়েরি চালাচ্ছে। সক্রিয় মার্জ বাক্সে রয়েছে 1,000 এবং প্রতিটি ক্লায়েন্টের প্রকাশনা ফাংশনটি একটি added, changedএবং removedসেই লাইভ কোয়েরিতে নিবন্ধিত হয়েছে যা মার্জ বাক্সগুলির মধ্যে একটিতে ফিড করে। মার্জ বাক্সগুলির সাথে অন্য কোনও কিছু সংযুক্ত নেই।

প্রথমে মঙ্গো ড্রাইভার। যখন ক্লায়েন্টগুলির মধ্যে একটিতে একটি নতুন দস্তাবেজ সন্নিবেশ করানো হয় Somestuff, তখন এটি পুনরুদ্ধারকে ট্রিগার করে। মঙ্গো ড্রাইভার সমস্ত নথির জন্য ক্যোয়ারী পুনরায় চালু করে Somestuff, ফলাফলটিকে স্মৃতিতে পূর্ববর্তী ফলাফলের সাথে তুলনা করে, একটি নতুন নথি রয়েছে বলে খুঁজে পেয়েছে এবং এক হাজারে নিবন্ধিত insertকলব্যাকের প্রত্যেকটিকে কল করে ।

এর পরে, প্রকাশিত ফাংশনগুলি। এখানে খুব সামান্যই ঘটছে: 1,000 টি insertকলব্যাকের প্রত্যেকটি কল করে ডিলিট করা বাক্সে ডেটা ঠেলে দেয় added

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

মোট সিপিইউ ব্যয় হ'ল একটি মঙ্গো ক্যোয়ারিকে আলাদা করার জন্য খরচ, পাশাপাশি তাদের ক্লায়েন্টদের রাজ্য পরীক্ষা করে নেওয়া এবং একটি নতুন ডিডিপি বার্তা পেইলড তৈরির জন্য 1000 মার্জ বাক্সের ব্যয়। কেবলমাত্র ডাটা যা তারের উপর দিয়ে প্রবাহিত হয় তা হল 1000 টি ক্লায়েন্টের প্রত্যেককে একক JSON অবজেক্ট, ডাটাবেসে নতুন নথির সাথে সম্পর্কিত, এবং ক্লায়েন্টের কাছ থেকে সার্ভারে একটি আরপিসি বার্তা যা মূল সন্নিবেশ তৈরি করেছিল।

নিখুঁতকরণ

আমরা অবশ্যই যা পরিকল্পনা করেছি তা এখানে।

  • আরও দক্ষ মোঙ্গো চালক। আমরা 0.5.1 সালে ড্রাইভারকে অনুকূলিত করেছি কেবলমাত্র পৃথক ক্যোয়ারী অনুসারে একটি একক পর্যবেক্ষক চালাতে।

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

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

  • অনেকগুলি ডাটাবেস সারি আপডেট করা হলে পুরানো এবং নতুন সারি সরবরাহ করে fire এই বৈশিষ্ট্যটি সহ, একটি ডাটাবেস ড্রাইভার পরিবর্তনের জন্য ভোট দেওয়ার পরিবর্তে একটি ট্রিগার নিবন্ধন করতে পারে।


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

@ টনি: এটি ডকুমেন্টেশনে রয়েছে। রুম গণনা উদাহরণ পরীক্ষা করুন।
মিটার

এটি লক্ষণীয় যে 0.7, 0.7.1, 0.7.2 রিলিজগুলিতে সিপিইউ লোড, নেটওয়ার্ক ব্যান্ডউইদথ এবং নেটওয়ার্কিং ব্যান্ডউইথের তুলনায় আরও কার্যকর দক্ষতার জন্য সর্বাধিক ক্যোয়ারীগুলি (ব্যতিক্রমগুলি skip, $nearএবং $whereক্যোয়ারী রয়েছে) জন্য ওপলগ পর্যবেক্ষণ ড্রাইভারের কাছে উল্কাপ্রদল সরে গেছে সার্ভার।
imslavko

প্রত্যেক ব্যবহারকারী একই ডেটা না দেখলে কী হয়। 1. তারা বিভিন্ন বিষয়ে সাবস্ক্রাইব করে .2। তাদের বিভিন্ন ভূমিকা রয়েছে তাই একই মূল বিষয়ের মধ্যে, কয়েকটি বার্তা রয়েছে যা তাদের কাছে পৌঁছানোর কথা নয়।
tgkprog

@debergalis ক্যাশে অবৈধতা সংক্রান্ত, সম্ভবত আপনি আমার কাগজ থেকে ধারনা পাবেন vanisoft.pl/~lopuszanski/public/cache_invalidation.pdf উপযুক্ত
qbolec

29

আমার অভিজ্ঞতা থেকে, উল্লিখিত একটি বিশাল সংগ্রহ ভাগ করে নেওয়ার সাথে অনেক ক্লায়েন্ট ব্যবহার করা মূলত সংস্করণ 0.7.0.1 হিসাবে অকার্যকর। আমি কেন তা বোঝানোর চেষ্টা করব।

উপরের পোস্টে এবং https://github.com/meteor/meteor/issues/1821 এ বর্ণিত হিসাবে উল্কা সার্ভারকে মার্জড বাক্সে প্রতিটি ক্লায়েন্টের জন্য প্রকাশিত ডেটার একটি অনুলিপি রাখতে হবে । এটিই মেটের জাদুটিকে ঘটতে দেয়, তবে নোড প্রক্রিয়াটির স্মৃতিতে কোনও বড় ভাগ করা ডাটাবেস বারবার রাখা হয়। এমনকি স্থিতিশীল সংগ্রহগুলির ক্ষেত্রে যেমন সম্ভাব্য অপ্টিমাইজেশন ব্যবহার করার সময়ও ( কোনও সংগ্রহকে স্থির করে দেওয়ার কোনও উপায় কি স্থির (কখনও পরিবর্তন হবে না? )), আমরা সিপিইউ এবং নোড প্রক্রিয়াটির মেমরির ব্যবহারের ক্ষেত্রে একটি বিশাল সমস্যা অনুভব করেছি।

আমাদের ক্ষেত্রে, আমরা প্রতিটি ক্লায়েন্টের কাছে 15 কে ডকুমেন্টের একটি সংগ্রহ প্রকাশ করছিলাম যা সম্পূর্ণ স্থিতিশীল ছিল। সমস্যাটি হ'ল এই নথিগুলি কোনও ক্লায়েন্টের সংযুক্তির বাক্সে (মেমরির ক্ষেত্রে) মূলত নোড প্রক্রিয়াটি প্রায় এক সেকেন্ডের জন্য 100% সিপিইউতে নিয়ে আসে এবং এর ফলে মেমরির বিশাল অতিরিক্ত ব্যবহার ঘটে। এটি অন্তর্নিহিতভাবে অপ্রত্যাশিত, কারণ যে কোনও সংযোগকারী ক্লায়েন্ট সার্ভারকে তার হাঁটুতে আনবে (এবং একযোগে সংযোগগুলি একে অপরকে অবরুদ্ধ করবে) এবং ক্লায়েন্টের সংখ্যায় মেমরির ব্যবহার রৈখিকভাবে বাড়বে go আমাদের ক্ষেত্রে, প্রতিটি ক্লায়েন্ট অতিরিক্ত ~ 60MB মেমরি ব্যবহার করে, যদিও স্থানান্তরিত কাঁচা ডেটা কেবল প্রায় 5MB ছিল।

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

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


@ হ্যারি ওপলগ এই পরিস্থিতিতে গুরুত্বপূর্ণ নয়; তথ্য স্থির ছিল।
অ্যান্ড্রু মাও

কেন এটি সার্ভারের পক্ষের মিনিমংগো অনুলিপিগুলি আলাদা করে না? 1.0 এ কি সব পরিবর্তন হয়েছে? আমার অর্থ সাধারণত তারা আশা করি একই রকম, এমনকি যে ফাংশনগুলি এটি আবার কল করে তাও একই রকম হবে (যদি আমি এটি অনুসরণ করি তবে সেখানে সংরক্ষণ করা কিছু সম্ভাবনা রয়েছে এবং সম্ভাব্য ভিন্ন))
MistereeDevlord

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

@ অ্যান্ড্রুমাও আপনি কীভাবে নিশ্চিত করতে পারেন যে জিপিড ফাইলগুলি ক্লায়েন্টের কাছে পাঠানোর সময় সুরক্ষিত আছে, অর্থাত্ কেবল কোনও লগইন ক্লায়েন্টই এটি অ্যাক্সেস করতে পারে?
ফুলস্ট্যাক

4

এই প্রশ্নের উত্তর দেওয়ার জন্য আপনি যে পরীক্ষাটি ব্যবহার করতে পারেন:

  1. একটি পরীক্ষার উল্কা ইনস্টল করুন: meteor create --example todos
  2. ওয়েবকিট ইন্সপেক্টর (ডাব্লুকেআই) এর অধীনে এটি চালান।
  3. ওয়্যার জুড়ে চলে যাওয়া এক্সএইচআর বার্তাগুলির সামগ্রীগুলি পরীক্ষা করুন ।
  4. লক্ষ্য করুন যে পুরো সংগ্রহটি তারের জুড়ে সরানো হয়নি।

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


2
পোলিং প্রক্রিয়াটির ব্যাখ্যা: eventedmind.com/posts/meteor-liveresultsset
cmather

3

এটি এখনও এক বছরের পুরনো এবং অতএব আমি "উল্কা ০.০" জ্ঞান ভাবি, তাই জিনিসগুলি আবার পরিবর্তিত হতে পারে? আমি এখনও এটি খতিয়ে দেখছি। http://meteorhacks.com/does-meteor-scale.html একটি "উল্কা স্কেল কিভাবে করবেন?" নিবন্ধ http://meteorhacks.com/how-to-scale-meteor.html

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