আধুনিক কম্পিউটিংয়ের দিনগুলিতে, 'সাধারণ ব্যবসায়িক অ্যাপ্লিকেশনগুলিতে' - পারফরম্যান্স কেন গুরুত্বপূর্ণ? [বন্ধ]


29

এটি আপনার কারও কাছে একটি বিজোড় প্রশ্নের মতো মনে হতে পারে।

আমি শখের একজন জাভা প্রোগ্রামার। আমি বেশ কয়েকটি গেমস তৈরি করেছি, একটি এআই প্রোগ্রাম যা সংগীত তৈরি করে, পেইন্টিংয়ের জন্য অন্য প্রোগ্রাম এবং অনুরূপ স্টাফ। এটি আপনাকে বলার জন্য যে আমার কাছে প্রোগ্রামিংয়ে অভিজ্ঞতা আছে তবে ব্যবসায়িক অ্যাপ্লিকেশনগুলির পেশাদার বিকাশে নয়।

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

আমি যা বোঝার চেষ্টা করছি তা হ'ল: কেন এটি গুরুত্বপূর্ণ?

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

তবে সাধারণ, সাধারণ উচ্চ-স্তরের ব্যবসায়িক অ্যাপ্লিকেশনটির জন্য পারফরম্যান্স কেন গুরুত্বপূর্ণ?

কয়েক দশক আগে কেন এটি গুরুত্বপূর্ণ ছিল তা আমি বুঝতে পারি। কম্পিউটারগুলি অনেক ধীর ছিল এবং স্মৃতিশক্তি কম ছিল তাই আপনাকে এই বিষয়গুলি সম্পর্কে সাবধানে চিন্তা করতে হবে।

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

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

আমার প্রশ্নটি দুটি ভাগে বিভক্ত:

  1. অনুশীলনে, আজ একটি সাধারণ সাধারণ ব্যবসায়িক প্রোগ্রামে পারফরম্যান্স কী গুরুত্বপূর্ণ?
  2. যদি এটি হয় তবে দয়া করে আমাকে এমন অ্যাপ্লিকেশনের জায়গাগুলির বাস্তব-বিশ্বের উদাহরণ দিন, যেখানে কার্য সম্পাদন এবং অপ্টিমাইজেশন গুরুত্বপূর্ণ।


পারফরম্যান্স যদি এটি দুর্বল হয় তবে তা গুরুত্বপূর্ণ।
মাইক ডুনলাভে

উত্তর:


40

আপনি ঠিক বলেছেন, বেশিরভাগ প্রোগ্রামাররা যেভাবে আলোচনা করেছেন তাই ব্যবসায়ের অ্যাপ্লিকেশনগুলিতে পারফরম্যান্স আসলেই গুরুত্বপূর্ণ বিষয় নয় । সাধারণত, প্রোগ্রামারদের কাছ থেকে আমি পারফরম্যান্স-সম্পর্কিত আলোচনাগুলির বেশ কয়েকটি সমস্যা থাকে:

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

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

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

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

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

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

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

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

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

এটি বলা হচ্ছে, সাধারণভাবে পারফরম্যান্স গুরুত্বপূর্ণ :

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

  • ব্যবসায়িক অ্যাপ্লিকেশান, সেখানে অনেক ক্ষেত্রে যেখানে একটি অ্যাপ্লিকেশন যা হয় মতানুযায়ী এবং হয় ধীর ব্যবহারকারীদের দ্বারা ঘৃণার পাত্র হবে। আপনার উদ্বেগকে সামনে রেখে পারফরম্যান্স তৈরি করে আপনি তা চান না।


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

1
a simple animated transition may often be the difference between an app which feels terribly slow and the app which feels responsive- যদিও এগুলি অবশ্যই অল্প পরিমাণে ব্যবহার করা উচিত, যে অ্যাপসগুলির জন্য অ্যানিমেশনগুলি এবং সর্বত্র স্থানান্তরিত হয় এমন অ্যাপগুলির জন্য যদি এই ট্রানজিশনগুলি প্রতিদিনের ভিত্তিতে দেখলে হতাশ হতে পারে!
কসমিক অসিফ্রেজ

আপনার উক্তির উত্স কি?
অ্যাডাম জনস

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

@ মাইনমা ​​ওহ দুর্দান্ত। আমি আপনার বক্তব্যটির সেই ছোট্ট চিত্রণটি সত্যই উপভোগ করেছি।
অ্যাডাম জনস

44

হ্যাঁ। হ্যাঁ এটা করে. রান-টাইম গতি কেবল আপনার হওয়া উচিত নয় এবং এটি 1982-এর মতো চাপের মতো নয় বা এটি এখনও নিম্ন-চালিত এম্বেডেড সিস্টেমে রয়েছে তবে এটি সর্বদা উদ্বেগজনক এবং এটি আপনার বোঝা গুরুত্বপূর্ণ কেন এমন হয়।

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

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

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


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

14

হ্যাঁ এটা করে!

যেহেতু আপনি উদাহরণ চেয়েছিলেন তাই প্রতিদিনের বিভিন্ন পরিস্থিতিতে মাথায় আসে:

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

  2. প্রতিক্রিয়াশীলতা : ব্যবহারযোগ্যতা অধ্যয়ন হয়েছে (আমার যদি সময় থাকে তবে আমি ux.se সম্পর্কিত প্রাসঙ্গিক লিঙ্কগুলিতে যুক্ত করব ...) যে ব্যবহারকারীর সন্তুষ্টি অত্যন্ত সাড়া জাগানোর সাথে সম্পর্কিত। 400ms বনাম 400ms এর প্রতিক্রিয়া সময়ের মধ্যে একটি পার্থক্য সহজেই আপনার প্রতিযোগীদের জন্য আপনাকে ছেড়ে যাওয়া আপনার গ্রাহকদের একটি বড় শতাংশের জন্য সহজেই খরচ করতে পারে।

  3. এম্বেডেড সিস্টেমগুলি : কম্পিউটারগুলি দ্রুততর হচ্ছে না, তারা ধীর এবং কম হচ্ছে getting _ ^ মোবাইল বিকাশ অ্যাপ্লিকেশন বিকাশে বিশাল প্রভাব ফেলে a অবশ্যই আমরা আধুনিক ডেস্কটপ কম্পিউটারগুলিতে জেলি বিনের মতো মেমরি এবং সিপিইউ চক্র ছুঁড়ে ফেলতে পারি তবে এখন আপনার বস আপনাকে ফ্রাইকিন ঘড়িতে বা সিম-কার্ডে স্লিপ-অ্যানালাইজিং অ্যালগরিদমটি প্রয়োগ করতে বলে ...


4

অনুশীলনে, আজ একটি সাধারণ সাধারণ ব্যবসায়িক প্রোগ্রামে পারফরম্যান্স কী গুরুত্বপূর্ণ?

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

হ্যাঁ, পারফরম্যান্স, কমপক্ষে জটিলতার স্তরে গুরুত্বপূর্ণ matters জটিলতার শ্রেণীর ভিতরে থাকা মাইক্রো-অপ্টিমাইজেশন আসলেই কিছু যায় আসে না, যদি আপনি প্রতিযোগিতার চেয়ে দৃশ্যমানভাবে খারাপ হন (তবে কিছু বাজারে বেঞ্চমার্কে বা কাঁচা ধারণা দ্বারা - অগ্রগতিতে "তাত্ক্ষণিক", ​​"তাত্ক্ষণিক নয় তবে ব্যবহারকারী ক্লাস পরিবর্তন করে) "অন্য কিছুতে স্যুইচ করুন", "কর্মের প্রবাহকে বাধা দেওয়ার ঝুঁকিতে ব্যবহারকারী অন্য কোনও কিছুতে স্যুইচ করুন", "ব্যবহারকারী এতক্ষণে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে চিকিত্সা পরীক্ষা করবে" " যে ব্যবহারকারী দুপুরের খাবারের উপর, রাত্রে, সপ্তাহের শেষের দিকে এই টাস্কটি চালু করার পরিকল্পনা করছেন ") plan


4

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

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


3

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


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

3
আপনি কেবল একবারই অনুকূলিত হন, তবে আপনি প্রতি মাসে বিদ্যুতের বিল পরিশোধ করেন।
জয়দী

2
@ জানহুডেক: আপনি এখন সত্যিই কীভাবে বলতে পারবেন তা আমি পুরোপুরি দেখতে পাচ্ছি না যখন আপনি বর্তমানে যে ওয়েবসাইটটি (আমাদের প্রিয় স্ট্যাক এক্সচেঞ্জ) বিশ্বব্যাপী এক মাসে 560 এম পৃষ্ঠাগুলি পরিবেশন করে কেবল 25 সার্ভারে চলে তখন আপনি সরাসরি মুখটি দিয়ে কীভাবে বলতে পারেন ।
মেহরদাদ

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

3
... এবং সত্য কথা বলতে গেলে, ডাটাবেসটি যা বেশিরভাগ উদ্বেগজনক কাজটি করে, তা দ্রুত ওঠার জন্য রচিত এবং অনুকূলিত হয়েছিল।
ব্লারফ্লার

3

এটি অবশ্যই অনেক গুরুত্বপূর্ণ।

প্রধান সমস্যাটি এমনকি সম্পর্কে এমন অপ্রয়োজনীয় বিলম্বের সম্মুখীন যখন গুই উপাদানের দুই বা তিনবার করে (যা overdrawn হিসাবে ব্যবহারকারীর জন্য বিরক্তিকর হচ্ছে, নয় নয় ইন্টিগ্রেটেড গ্রাফিক্স বিষয়টি!) বা শুধু কারণ প্রোগ্রাম এতক্ষণ লাগে না ... যাই হোক না কেন এটা (বেশিরভাগই উদ্বেগজনক জিনিস) করে যদিও এটি অবশ্যই একটি বিষয় is

তিনটি গুরুত্বপূর্ণ ভুল ধারণা রয়েছে:

  1. বেশিরভাগ সাধারণ ব্যবসায়িক কম্পিউটারগুলি "এত বেশি শক্তিশালী" নয় । সাধারণ ব্যবসায়িক কম্পিউটারটি একটি কিক-গাধা গ্রাফিক্স কার্ড এবং 16 গিগাবাইট র‍্যাম সহ 8-কোর আই 7 নয় । এটি একটি মিড-ক্লাসের মোবাইল প্রসেসর, ইন্টিগ্রেটেড গ্রাফিক্স, 2 গিগাবাইট মূল মেমরি (আপনি যদি ভাগ্যবান হন 4 জিবি), একটি 5400 আরপিএম ডিস্ক, এবং বিভিন্ন রিয়েলটাইম অ্যান্টিভাইরাস এবং নীতি-প্রয়োগকারী সফ্টওয়্যার সহ উইন্ডোজের একটি এন্টারপ্রাইজ সংস্করণ রয়েছে the পটভূমি। বা, বেশিরভাগ পরামর্শদাতাদের জন্য, "কম্পিউটার" হ'ল আইফোন ...
  2. বেশিরভাগ "সাধারণ ব্যবসায়ের ব্যবহারকারীরা" প্রযুক্তিবিদ নন, তারা 10-12 ক্রস-রেফারেন্সিং ট্যাব, 150 কলাম এবং 30,000 সারি দিয়ে স্প্রেডশিট তৈরির প্রভাবগুলি বুঝতে পারে না (এই পরিসংখ্যানগুলি আপনার ধারণা হিসাবে অবাস্তব নয়!) এবং তারা না জানতে চাই না। তারা কেবল এটি করবে।
  3. দ্বিতীয় হারানো ব্যয় হয় না এটি একটি স্পষ্টতই ভুল ধারণা।

আমার স্ত্রী এই জাতীয় "সাধারণ ব্যবসায়ের পরিবেশ" এর উপরের প্রান্তে কাজ করেন। তিনি যে কম্পিউটারটি ব্যবহার করছেন তার কাজের সময়কালের প্রায় 3.5 ঘন্টা ব্যয় করতে হবে। মাইক্রোসফ্ট আউটলুক শুরু করা - একটি ভাল দিন লাগে - এটি প্রস্তুত হওয়া অবধি প্রায় 3 মিনিট (সার্ভারগুলি ভারী বোঝার মধ্যে থাকা কোয়ার্টার-এন্ডে 6-8 মিনিট) লাগে। উল্লিখিত এই 30 কে-সারি-স্প্রেডশিটগুলির মধ্যে কম্পিউটারটি "হিমায়িত" হয় এমন মান আপডেট করার জন্য 2-3 সেকেন্ড সময় নেয় (এক্সেলটি শুরু করতে এবং এগুলিকে প্রথম স্থানে খুলতে কত সময় লাগে তা উল্লেখ না করে!)। ডেস্কটপ ভাগ করে নেওয়ার সময় এটি আরও খারাপ। এমনকি আমাকে এসএপি চালিয়ে যাবেন না।
এটি অবশ্যই গুরুত্বপূর্ণ যে প্রতি একশো লোক কোনও কাজের দিন প্রতি 20-25 মিনিট হারাবে কিনা matters যারা হারিয়ে গেছে লক্ষ লক্ষযা আপনি এগুলি হারানোর পরিবর্তে লভ্যাংশ হিসাবে পরিশোধ করতে পারেন (বা বেশি মজুরি দিতে পারেন)।
অবশ্যই, বেশিরভাগ কর্মচারী বেতন স্কেলের নীচের প্রান্তে রয়েছেন, তবে নীচের শেষের দিকে অর্থও রয়েছে


3

কয়েক দশক আগে কেন এটি গুরুত্বপূর্ণ ছিল তা আমি বুঝতে পারি। কম্পিউটারগুলি অনেক ধীর ছিল এবং স্মৃতিশক্তি কম ছিল তাই আপনাকে এই বিষয়গুলি সম্পর্কে সাবধানে চিন্তা করতে হবে।

আপনার মনে হয় N^ 2 কত দ্রুত বৃদ্ধি পাবে und ধরা যাক আমাদের একটি কম্পিউটার আছে এবং আমাদের এন 10. ​​2 অ্যালগরিদমটি 10 ​​সেকেন্ড সময় নেয় যখন এন = 10 সময় পার হয়ে যায় আমাদের এখন একটি নতুন প্রসেসর রয়েছে যা আমাদের মূল থেকে 6 গুণ বেশি গতিযুক্ত তাই আমাদের 10 সেকেন্ডের গণনা এখন দুই সেকেন্ডের চেয়ে কম is আসল 10 সেকেন্ড রান সময় এন কত বড় হতে পারে এবং এখনও ফিট হতে পারে? আমরা এখন 24 টি আইটেমগুলি হ্যান্ডেল করতে পারি, দ্বিগুণ চেয়ে দ্বিগুণ। আমাদের সিস্টেমকে 10 গুণ বেশি আইটেম পরিচালনা করতে কত দ্রুত হতে হবে? ভাল এটি 100 গুণ দ্রুত হতে হবে। N ^ 2 অ্যালগরিদমের কম্পিউটারের হার্ডওয়্যার অগ্রগতি মুছে ফেলার চেয়ে ডেটা বেশ দ্রুত এবং আরও বেশি বৃদ্ধি পায়।


আরেকটি উদাহরণ: যদি কোনও উপাদানটির প্রক্রিয়াকরণে 30 সিপিইউ চক্র বা 10ns লাগে (যা বেশ সস্তা), তবে আপনার যদি 10000 উপাদান থাকে তবে অ্যালগরিদম ইতিমধ্যে সম্পূর্ণ সেকেন্ড নেবে। 10000 উপাদানগুলি অনেকগুলি প্রসঙ্গে নয়।
CodeInChaos

1

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

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

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


1

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

http://windowsitpro.com/windows-xp/svchost-and-windows-update-windows-xp-still-problem

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

আপডেট অ্যালগরিদম সূচকযুক্ত, যেখানে প্রতিটি নতুন আপডেট পূর্ববর্তী ( ) হিসাবে গণনা করতে দ্বিগুণ সময় নেয় । তালিকাগুলি 40 টি আপডেটের পরিসীমা (* দীর্ঘ ) এ উঠলে, আপডেটগুলি পরীক্ষা করতে 15 মিনিটের বেশি সময় নিয়ে পূর্ণ ক্ষমতা নিয়ে চলছে। আপডেটের সময় এটি বেশ কয়েকটি এক্সপি মেশিনকে কার্যকরভাবে লক করেছে। সবচেয়ে খারাপটি হলেও, যখন কেউ আপডেটগুলি ইনস্টল করতে যায় , অন্য 15 মিনিট সময় নিয়ে আবার অ্যালগোরিদম আবার চলবে । যেহেতু অনেকগুলি মেশিনের স্বয়ংক্রিয় আপডেটগুলি সেট ছিল, এটি প্রতিটি বুটে 15 মিনিটের জন্য মেশিনগুলিকে লক করতে পারে এবং একটি নির্দিষ্ট সময়কালে আবার সম্ভাব্য।O(n) = 2n

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

এখানে আমরা দেখতে পারি যে একটি অ্যালগরিদমের পছন্দটির সত্যই প্রভাব ছিল। পণ্যটির জীবনের বেশিরভাগ ক্ষেত্রেই সঠিক অ্যালগরিদম এখনও রাস্তায় নেতিবাচক প্রভাব ফেলতে পারে।


0

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

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


-1

আপনি "ভাল পারফরম্যান্স" কীভাবে সংজ্ঞায়িত করেন তার উপর এটি নির্ভর করে depends আপনার অ্যালগরিদমগুলি সর্বদা সর্বোত্তম সম্ভাব্য জটিলতা ব্যবহার করা উচিত। আপনার গড় খাঁচার গতি বাড়ানোর জন্য দুর্বলতা অবলম্বন করুন। ইন্টারেক্টিভ প্রোগ্রামে যেখানেই সম্ভব বাফার এবং প্রিললোড / প্রাকম্পাইল ile

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

সেই সময়ে জাভা / হাস্কেল / সি ++ ব্যবহার করা অন্য একটি ডিজাইনের সিদ্ধান্তে পরিণত হয়। নম্বর ক্রাঞ্চিং আপনার জিপিইউতে ওপেনসিএল এর মাধ্যমে করা যেতে পারে। ব্যবহারকারীর ইন্টারফেসগুলির স্থির সময় অ্যালগরিদম প্রয়োজন এবং সেগুলি ভাল're 20% ভাল ক্যাশে ব্যবহারের জন্য আপনার শ্রেণিগুলিকে সারিবদ্ধ করার চেয়ে আউটপুট এবং মডুলারালিটি আরও গুরুত্বপূর্ণ। মাল্টিথ্রেডিং গুরুত্বপূর্ণ হয়ে ওঠে, কারণ লোকেরা একটি দ্রুত অ্যাপ্লিকেশন চায় না, তারা একটি প্রতিক্রিয়াশীল চায়। আপনার অ্যাপ্লিকেশনটি যেটুকু গুরুত্বপূর্ণ তা নয় তার চেয়ে নিয়মিত 10% ধীর হয়ে যাওয়া। এমনকি 50% ঠিক আছে (তবে লোকেরা তখন প্রশ্ন জিজ্ঞাসা করতে শুরু করে)। নির্ভুলতা, প্রতিক্রিয়াশীলতা এবং মডুলারালিটির প্রতি মনোনিবেশ করুন।

আমি হাস্কেল বা কমপক্ষে একটি কার্যকরী আকারে (এমনকি সি ++ তেও) প্রোগ্রামিং পছন্দ করি। আপনার পুরো প্রোগ্রামের জন্য সহজেই পরীক্ষাগুলি লিখতে সক্ষম হওয়া ব্যাচের চাকরিতে সামান্য দ্রুত হওয়ার চেয়ে আরও গুরুত্বপূর্ণ way


-1

বেশ সহজ: ব্যয়

আমার পূর্ববর্তী নিয়োগকর্তার একটি লার্নিং ম্যানেজমেন্ট সিস্টেম ছিল যা সাঃ মডেল হিসাবে শারীরিক সার্ভারগুলিতে হোস্ট করা হয়েছিল। জেভিএমের হিপগুলি পুরানো মেশিনগুলির জন্য 2 জিবি এবং নতুন মেশিনগুলির জন্য 3 গিগাবাইটে কনফিগার করা হয়েছিল এবং আমরা প্রতি মেশিনে বেশ কয়েকটি দৃষ্টান্ত দৌড়েছিলাম। আপনি মনে করেন যে যথেষ্ট হবে।

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

সমস্যাটি হচ্ছে, আমাদের সাথে কাজ করার জন্য 2 জিবি ছিল। সুতরাং স্পষ্ট সমাধান হ'ল ঘন ঘন পড়া সমস্ত ডেটা ক্যাশে শুরু করা। তারপরে আমাদের স্মৃতি সংক্রান্ত সমস্যা ছিল, আমি বোর্ডে আসার আগেই শুরু হয়েছিল।

এটি নিয়ে 2 টি বিদ্যালয় ছিল:

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

দ্বিতীয় যুক্তিটি জিতে গেল এবং আমি আমাদের স্মৃতি ব্যবহারের জন্য এক বছর ধরে কাটিয়েছি।

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

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

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

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

টি এল; ডিআর

আপনি যদি একটি সম্পূর্ণ ব্যয় / উপকার বিশ্লেষণ করেন তবে দেখবেন যে কেবল কোডটি ঠিক করা এটি সস্তা। একটি পরিচিত কার্য-সম্পাদনার সমস্যা আপনি উপেক্ষা মধ্যে দেখা যাচ্ছে যে প্রযুক্তিগত ঋণ


1
প্রতিটি খরচ / সুবিধা বিশ্লেষণের ফলে "কোডটি ঠিক করা" হবে না। প্রোগ্রামাররা খুব ব্যয়বহুল, এবং আপনি যদি কোনও প্রোগ্রামারের ব্যয়ের চেয়ে কম পরিমাণে র্যাম যোগ করতে পারেন এবং এখনও সমস্যার সমাধান করতে পারেন ...
রবার্ট হার্ভে

এটা দুর্দান্ত যে মেঘ-হোস্টিং পরিস্থিতিতে এতটা স্থান নিয়ে আপনি দেখতে পাচ্ছেন যে আসলে আপনি পাওয়ারের জন্য কতটা অর্থ প্রদান করছেন paying উদাহরণস্বরূপ আমরা ডাটাবেসের জন্য অ্যামাজন আরডিএস ব্যবহার করি। বৃহত্তম এবং দ্বিতীয় বৃহত্তম উদাহরণের মধ্যে পার্থক্যটি প্রায়। Year 3500 প্রতি বছর। এটি এমন একটি সংখ্যা যা আপনি দেখতে এবং বিচার করতে পারেন যে এটির জন্য উপযুক্ত প্রোগ্রামার সময়টি উপযুক্ত।
কারসন 63000

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

-2

আমি আপনার প্রশ্নটি এইভাবে বুঝতে পেরেছিলাম: ভাল-পর্যাপ্ত পারফরম্যান্স অর্জনের জন্য (অর্থাত্ ব্যবহারকারীরা খুশি এবং আমার ব্যাকএন্ড ক্রিংস হয় না), আমার কি অ্যালগোরিদমিক জটিলতার তত্ত্বটি বোঝার দরকার আছে?

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

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

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


-2

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

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