কোনও ওয়েব এপিআই-এর জন্য একটি নেটওয়ার্ক কল দিয়ে কী মাল্টিপল ডাটাবেস কলগুলি সত্যই তাৎপর্যপূর্ণ?


16

আমার নিয়োগকর্তাদের একজনের কাছে আমরা একটি রেস্টে (তবে এটি এসওএপি-তেও প্রযোজ্য) API তে কাজ করেছি। ক্লায়েন্ট, যা অ্যাপ্লিকেশন ইউআই, ওয়েবে ওয়েব এ কল করতে হবে (টিপিকাল প্রোডাক্ট ডিপ্লোয়মেন্টগুলিতে ল্যান) এপিআইতে। এপিআই ডাটাবেসে কল করবে।

আমাদের আলোচনায় পুনরাবৃত্তি হওয়া একটি থিম হ'ল পারফরম্যান্স: দলের কিছু লোক বিশ্বাস করে যে পারফরম্যান্সের কারণে আপনার একক এপিআই কল থেকে একাধিক ডাটাবেস কল (সাধারণত পড়া) করা উচিত নয়; আপনার সেগুলি অপ্টিমাইজ করা উচিত যাতে প্রতিটি এপিআই কলটিতে কেবলমাত্র (ঠিক) একটি ডাটাবেস কল থাকে।

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

টিএলডিআর: ল্যানের মাধ্যমে আমরা ইতিমধ্যে কোনও নেটওয়ার্ক কল করার সময় একাধিক ডাটাবেস কলগুলি নিয়ে চিন্তিত হওয়া কি সত্যই গুরুত্বপূর্ণ? যদি তাই হয় তবে কেন?

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

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


এপিআই স্তর এবং ডাটাবেসের মধ্যে আর কোনও নেটওয়ার্ক কল নেই?
সাইন ইন করুন

4
আপনার সময় পরীক্ষাগুলি কী দেখায়?
ড্যান পিচেলম্যান

@ সাইন করুন API এবং DB এর মধ্যে কোনও নেটওয়ার্ক কল নেই। আমি যা বুঝি সেগুলি থেকে তারা একই মেশিনে থাকার গ্যারান্টিযুক্ত।
ashes999

@ ড্যানিপিসেলম্যান এটিই আমি জিজ্ঞাসা করছি। কেউ পারফরম্যান্স গ্রহণ এবং সময় নিচ্ছে বলে মনে হয় না; আমরা কেবলমাত্র "সমস্ত ডিবি কলকে একক কলের সাথে সংযুক্ত করে এক্সের পারফরম্যান্স ঠিক করতে" প্রয়োজনীয়তা পেয়েছি।
ashes999

উত্তর:


25

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

যুক্তিটা

তত্ত্বগতভাবে, আপনি সঠিক। তবে এই যুক্তি সহ কয়েকটি ত্রুটি রয়েছে:

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

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

  3. এই চিন্তাভাবনাটি একবারে একটি একক প্রক্রিয়া ধরে নেয় বা অন্যভাবে রাখে, কোনও সহানুভূতি হয় না। এটি ধরে নেওয়া হয় যে একটি অনুরোধ অন্য অনুরোধের কার্য সম্পাদন করতে পারে না। সংস্থানগুলি ভাগ করা হয়, যেমন ডিস্ক আই / ও, নেটওয়ার্ক ব্যান্ডউইথ, সংযোগ পুল, মেমরি, সিপিইউ চক্র ইত্যাদি Therefore অতএব, একটি ডেটাবেস কল একটি ভাগ করা উত্সের ব্যবহার হ্রাস করা অন্যান্য অনুরোধগুলি ধীর হওয়ার কারণ হতে পারে। আমি যখন আমার বর্তমান নিয়োগকর্তার সাথে প্রথম যোগদান করেছি, পরিচালনা বিশ্বাস করেছিল যে 3 সেকেন্ডের ডাটাবেস কোয়েরি টিউন করা সময়ের অপচয় ছিল waste 3 সেকেন্ড এত কম, কেন এতে সময় নষ্ট করবেন? আমরা কি সিডিএন বা সংক্ষেপণ বা অন্য কিছু দিয়ে আরও ভাল থাকব না? তবে আমি যদি 1 সেকেন্ডে 3 সেকেন্ডের ক্যোয়ারী চালাতে পারি তবে একটি সূচক যুক্ত করে বলুন, এটি 2/3 কম ব্লকিং, কোনও থ্রেড দখল করতে 2/3 কম সময় ব্যয় করেছে এবং আরও গুরুত্বপূর্ণ, ডিস্ক থেকে কম ডেটা পড়েছে,

তত্ত্বটি

একটি প্রচলিত ধারণা রয়েছে যে সফ্টওয়্যার কর্মক্ষমতা কেবল গতি সম্পর্কে ।

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

যাইহোক, উপরোক্ত হিসাবে, আমি আশা করি আপনি কীভাবে রিসোর্স কনটেন্ট, ইনডেক্সিং এর অভাব, খারাপ লিখিত কোড ইত্যাদি পারফরম্যান্সে আশ্চর্যজনক পার্থক্য তৈরি করতে পারেন তা দেখতে পাবেন।

অনুমান

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

যেখানে এটি মুরকি পায়

এই পুরো প্রশ্নটি "একাধিক" বনাম "একক" ডাটাবেস কল সম্পর্কে। তবে এটি স্পষ্ট নয় যে কয়টি একাধিক। উপরে আমি যা বলেছিলাম তার কারণে, সাধারণ নিয়ম হিসাবে, আমি প্রয়োজনীয় হিসাবে কম কয়েকটি ডাটাবেস কল করার পরামর্শ দিই। তবে এটি কেবল একটি আঙ্গুলের নিয়ম।

এখানে কেন:

  1. ডেটাবেসগুলি ডেটা পড়তে দুর্দান্ত। এগুলি স্টোরেজ ইঞ্জিন eng যাইহোক, আপনার ব্যবসার যুক্তি আপনার প্রয়োগে বাস করে lives আপনি যদি এমন কোনও নিয়ম তৈরি করেন যে প্রতিটি API কল ঠিক এক ডাটাবেস কলটিতে ফলাফল দেয় তবে আপনার ব্যবসায়িক যুক্তি ডাটাবেসে শেষ হতে পারে। হতে পারে যে ঠিক আছে। প্রচুর সিস্টেম এটি করে। কিন্তু কিছু না। এটি নমনীয়তা সম্পর্কে।
  2. কখনও কখনও ভাল decoupling অর্জন করতে, আপনি 2 ডাটাবেস কল পৃথক করতে চান। উদাহরণস্বরূপ, সম্ভবত প্রতিটি এইচটিটিপি অনুরোধ জেনেরিক সুরক্ষা ফিল্টারের মাধ্যমে প্রবর্তিত যা ডিবি থেকে যাচাই করে যে ব্যবহারকারীর সঠিক অ্যাক্সেসের অধিকার রয়েছে। যদি তারা তা করে থাকে তবে সেই URL এর জন্য উপযুক্ত ফাংশনটি সম্পাদন করতে এগিয়ে যান। এই ফাংশনটি ডাটাবেসের সাথে যোগাযোগ করতে পারে।
  3. একটি লুপে ডাটাবেস কল করা। একারণে আমি জিজ্ঞাসা করেছি যে কতগুলি একাধিক। উপরের উদাহরণে, আপনার কাছে 2 টি ডাটাবেস কল থাকবে। 2 ঠিক আছে। 3 ভাল হতে পারে। এন ভাল না। আপনি যদি লুপটিতে ডাটাবেসকে কল করেন তবে আপনি এখন পারফরম্যান্স লিনিয়ার তৈরি করেছেন যার অর্থ লুপের ইনপুটটিতে আরও বেশি সময় লাগবে। সুতরাং স্পষ্টতই বলা যায় যে, API নেটওয়ার্ক সময়টি ধীরতম সম্পূর্ণরূপে আপনার 1% ট্র্যাফিকের মতো অনাবৃতকে পর্যবেক্ষণ করে না-এমনটি এখনও আবিষ্কার হয়নি এমন একটি লুপের কারণে যে ডাটাবেসটিকে 10,000 বার কল করে।
  4. কখনও কখনও এমন কিছু জিনিস রয়েছে যেমন কিছু জটিল গণনার মতো আপনার অ্যাপ্লিকেশনটি আরও ভাল। আপনাকে ডাটাবেস থেকে কিছু তথ্য পড়তে হবে, কিছু গণনা করতে হবে, তারপরে ফলাফলের উপর ভিত্তি করে, দ্বিতীয় ডাটাবেস কলটিতে প্যারামিটারটি পাস করতে হবে (সম্ভবত কিছু ফলাফল লিখতে হবে)। যদি আপনি কেবলমাত্র ডাটাবেসগুলিকে একবার কল করার প্রয়োজনে সেগুলিকে একক কল (সঞ্চিত পদ্ধতির মতো) সাথে সংযুক্ত করে থাকেন তবে আপনি নিজেকে এমন কোনও কিছুর জন্য ডাটাবেস ব্যবহার করতে বাধ্য করেছেন যা অ্যাপ্লিকেশন সার্ভারের চেয়ে ভাল হতে পারে।
  5. লোড ব্যালেন্সিং: আপনার কাছে 1 টি ডাটাবেস (সম্ভবত) এবং একাধিক লোড ভারসাম্যযুক্ত অ্যাপ্লিকেশন সার্ভার রয়েছে। অতএব, অ্যাপ্লিকেশন যত বেশি কাজ করে এবং ডাটাবেস তত কম করে, স্কেল করা সহজতর কারণ সেটআপ ডাটাবেসের প্রতিরূপের চেয়ে অ্যাপ্লিকেশন সার্ভার যুক্ত করা সহজ easier পূর্বের বুলেট পয়েন্টের উপর ভিত্তি করে, এসকিউএল ক্যোয়ারী চালানোর জন্য এটি বোধগম্য হতে পারে, তারপরে অ্যাপ্লিকেশনটিতে সমস্ত গণনা করুন যা একাধিক সার্ভারে বিতরণ করা হয়েছে, এবং তারপরে ফলাফলটি লেখার পরে লিখুন। এটি আরও ভাল থ্রুপুট দিতে পারে (সামগ্রিক লেনদেনের সময় একই থাকলেও)।

টি এল; ডিআর

টিএলডিআর: ল্যানের মাধ্যমে আমরা ইতিমধ্যে কোনও নেটওয়ার্ক কল করার সময় একাধিক ডাটাবেস কলগুলি নিয়ে চিন্তিত হওয়া কি সত্যই গুরুত্বপূর্ণ? যদি তাই হয় তবে কেন?

হ্যাঁ, তবে কেবল একটি নির্দিষ্ট পরিমাণে। ব্যবহারিক ব্যবহারের সময় আপনার ডাটাবেস কলগুলির সংখ্যা হ্রাস করার চেষ্টা করা উচিত তবে কলগুলি একত্রিত করবেন না যা কেবল একে অপরের সাথে সংযুক্ত করার জন্য কিছু নয় of এছাড়াও, যে কোনও মূল্যে ডাটাবেসটিকে একটি লুপে কল করা এড়ানো উচিত।


3

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

যেভাবেই ডেটা ব্যাক আপ করার জন্য অপ্টিমাইজেশনের সিদ্ধান্ত নেওয়া উচিত নয়। এটি পরিমাপ করুন এবং আপনার অ্যাপ্লিকেশনটির জন্য সেরা কি তা নির্ধারণ করুন।


1
এটি আমাদের দুর্বল পারফরম্যান্স অনুশীলনগুলি সম্পর্কে একটি ভাল মন্তব্য, তবে আমার কাছে ইতিমধ্যে একটি নেটওয়ার্ক কল এসেছে যখন ডিবি কলগুলি চিন্তার কিছু আছে কিনা সে সম্পর্কে আমার প্রশ্নের উত্তর দেয় না।
ashes999

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

এটি (প্রয়োজনীয়ভাবে) নির্দিষ্টকরণের উপর নির্ভর করা উচিত নয়, কারণ আমি প্রস্থের ক্রমের কথা বলছি।
ashes999

খালি মোটামুটি অনুমান (আপনার মাপতে হবে): ওয়েব সার্ভার থেকে ডিবি সংযোগ করার গড় সময়: 2 এমএস ক্লায়েন্ট থেকে ওয়েব সার্ভারের সাথে সংযোগ স্থাপনের গড় সময়: 20 মিমি তাই আমি যে নম্বরগুলি এলোমেলোভাবে বায়ু থেকে টেনে এনেছি তা সঠিক বলে ধরে নেওয়া, আপনি 10 করতে পারেন একটি ওয়েব পরিষেবা কল করতে সময় লাগে এমন ডাটাবেস কল। ধরে নেওয়া যে ডাটাবেস অনুসন্ধানগুলি একই পরিমাণে সময় নেয়। পরিবেশের উপর অত্যন্ত নির্ভরশীল এই সংখ্যাগুলি Those ওয়েব সার্ভিস কল করার ক্লায়েন্ট যদি স্থানীয় হয় তবে এটি কয়েকটি মাত্রার অর্ডারে ফেলে দিতে পারে।
bianfeucht

2

আমরা আপনাকে বলতে পারি না।

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

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


এ ছাড়া, আপেক্ষিক নিশ্চিততার সাথে আমি কেবল একটি জিনিস যুক্ত করতে পারি:

একটি একক অনুরোধের মধ্যে, আপনার প্রতিক্রিয়া তৈরি করার জন্য আপনার প্রয়োজনীয় সমস্ত প্রশ্নগুলি সম্পাদন করা উচিত।

অন্য কথায়, সমস্ত এন কোয়েরি না করা পর্যন্ত যদি প্রতিক্রিয়া তৈরি করা না যায় তবে এগুলি আলাদা করা সাধারণত বুদ্ধিমানের কাজ নয়। আপনি যদি প্রতিটি প্রশ্নের পরে মধ্যবর্তী বা সম্পূর্ণ, অর্থবহ ফলাফল তৈরি করতে পারেন তবে বেঞ্চমার্কিং শুরু করুন।


1

দুটি চিন্তা:

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

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

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


আমি পারফরম্যান্স পরিমাপ সম্পর্কে আপনার সাথে একমত, যা কেউ করছে না বলে মনে হচ্ছে। এটি দ্রুত যে কোনও প্রমাণ নেই, তবে এটি কেবল সামনে আসে keeps পারফরম্যান্স একটি সমস্যা হিসাবে উপস্থিত হয় যখন আমাদের কাছে কিছু কল আসে যা বলে, 1000 ডিবি SELECTএস।
ashes999

@ অ্যাশেস৯৯৯৯ আপনি যখন ডিবি কলগুলির সংখ্যা দেখে গতি অর্জন করতে পারেন, ততক্ষণে এটি সূচীকরণ কৌশলতে পাওয়া যাবে ইত্যাদি কলগুলির সংখ্যা নয়। সবাই যেমন ইঙ্গিত করেছে, পারফরম্যান্স ডেটা দেখুন।
রিচার্ড

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

@ ashes999 দুঃখিত, সম্ভবত নেটওয়ার্ক কল সম্পর্কে আপনার আরও কিছুটা বিশদ নেওয়া উচিত, যেহেতু এটি সুস্পষ্ট বলে মনে হচ্ছে, আমি বুঝতে পারি যে আপনার প্রশ্নের আরও কিছুটা আছে। আমি মনে করি আমরা আপনার প্রশ্নে কিছু অনুপস্থিত। আপনি সর্বদা কিছুটা জাতীয় বিলম্বিত আচরণ করবেন, এবং প্রতিটি কল সম্ভাব্যভাবে প্রতিটি কলের জন্য "x" বার বৃদ্ধি করে (সহজ শর্তে)। ফেস ভ্যালুতে বিবৃতিটি সত্য, একাধিক নেটওয়ার্ক কল ডিবিতে একটি নেটওয়ার্ক কলের চেয়ে ধীর হবে। এজন্য আমি সঞ্চিত পদ্ধতিতে একটি কল করার পরামর্শ দিই, তারপরে, এটি মাল্টি নেটওয়ার্ক কল ছাড়াই ডিবিতে একাধিক কল করতে পারে।
রিচার্ড

1

যদি ডাটাবেস আপনার আরএসটি পরিষেবার চেয়ে আলাদা সার্ভারে থাকে তবে প্রতিটি ডাটাবেস কল একটি নেটওয়ার্ক রাউন্ডট্রিপের ফলস্বরূপ এবং এটি কার্য সম্পাদনকে উল্লেখযোগ্যভাবে আঘাত করতে পারে :

আমি একবার একবার দেখেছি যে একক ওয়েব সার্ভিস কলটি প্রায় 500 টি ডাটাবেস ক্যোয়ারীতে অনুবাদ করা হয়েছে - যখন ওয়েবসার্ভিস এবং ডাটাবেস উভয়ই একই মেশিনে অবস্থিত তখন এটি কোনও সমস্যাই ছিল না, তবে যখন তারা আলাদা ছিল তখন 6-7 সেকেন্ডের প্রতিক্রিয়ার সময়ে পরিণত হয়েছিল মেশিন।

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


1

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

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


0

উপস্থাপিত অপ্টিমাইজেশনের পথটি কেবল জিনিসগুলিকে দেখার ভুল উপায়।

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

কখনও কখনও একটি একক কর্ম বরং জটিল। উদাহরণস্বরূপ, বেশ কয়েকটি উত্স থেকে একত্রিত হওয়া ডেটা আনয়ন: আবারও এটি একক কল হওয়া উচিত। হয় পুরো জিনিসটি কাজ করে বা পুরো জিনিস ব্যর্থ হয়।

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

আমি তাদের বক্তব্যটি কিছুটা বুঝতে পারি যে একটি একক ক্যোয়ারী চালানো বেশ কয়েকটির চেয়ে দ্রুততর হতে পারে; তবে এটি একটি মোটামুটি ডিবি এবং নেটওয়ার্ক লোডকে উপেক্ষা করার কারণে একটি মিথ্যা ছাপ দেয়। কেবলমাত্র ডিবি থেকে ডেটা বের করার বিভিন্ন উপায়ে প্রোফাইলিংয়ের মাধ্যমে আপনি বুঝতে পারবেন যে সমস্যাটি আসলে কী। আমি নিশ্চিত যে প্রত্যেকেরই একটি গল্প আছে যেখানে একটি নির্দিষ্ট ক্যোয়ারী প্রত্যাশার চেয়ে ১০০ গুণ বেশি কার্যকর করা হয় যতক্ষণ না যথাযথ সূচক স্থাপন না করা হয় ...

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

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