সত্তা ফ্রেমওয়ার্ক খুব ধীর। আমার বিকল্পগুলি কি কি? [বন্ধ]

Question

আমি "অসময়ে অপ্টিমাইজ করবেন না" মন্ত্রটি অনুসরণ করেছি এবং সত্তা ফ্রেমওয়ার্ক ব্যবহার করে আমার ডাব্লুসিএফ পরিষেবাটি কোড আপ করেছি।

যাইহোক, আমি পারফরম্যান্সটির প্রোফাইল দিয়েছি এবং সত্তা ফ্রেমওয়ার্কটি খুব ধীর। (আমার অ্যাপ্লিকেশনটি প্রায় ১.২ সেকেন্ডের মধ্যে ২ টি বার্তা প্রক্রিয়াকরণ করে, যেখানে আমি যে লিগ্যাসি অ্যাপটি পুনরায় লিখছি তা একই সাথে 5-6 বার্তাগুলি করে।

আমার প্রোফাইলটি বার্তা প্রতি সময় বেশিরভাগ সময় নিয়ে সত্তা ফ্রেমওয়ার্কের দিকে নির্দেশ করে।

তাই আমার অপশন কি?

• সেখানে কি আরও ভাল ওআরএম আছে?
  (এমন কিছু যা কেবলমাত্র সাধারণ পড়া এবং অবজেক্টগুলির লেখাকে সমর্থন করে এবং এটি দ্রুত করে ..)

• সত্তা ফ্রেমওয়ার্ক দ্রুত করার কোনও উপায় আছে?
  ( দ্রষ্টব্য : আমি যখন দ্রুত বলে থাকি তবে প্রথম কলটি নয়, প্রথম কলটি not প্রথম কলটি ধীরে ধীরে (একটি বার্তার জন্য 15 সেকেন্ড)) তবে এটি কোনও সমস্যা নয় I বাকীটির জন্য আমার দ্রুত হওয়া দরকার just বার্তাগুলির।)

• কিছু রহস্যজনক 3 য় বিকল্প যা আমার পরিষেবা থেকে আরও গতি পেতে আমাকে সহায়তা করবে।

দ্রষ্টব্য: আমার বেশিরভাগ ডিবি ইন্টারঅ্যাকশন তৈরি এবং আপডেট। আমি খুব কম নির্বাচন এবং মুছে ফেলা করি।

Comments

এটি 'লিনক স্লো' এর রিহ্যাশের মতো শোনাচ্ছে আপনি কীভাবে জানবেন যে এটি ইএফ? আপনি কি আপনার সমস্ত পরিবর্তনকে প্রোফাইল করেছেন?

— মেইস

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

— অ্যান্টনি পেগ্রাম

@ মেইস - আমি ভেবেছিলাম আমি ইঙ্গিত দিয়েছি যে আমি প্রোফাইল দিয়েছি এবং দেখেছি এটি ইএফ / ডিবি ধীর ছিল was যেভাবেই হোক, হ্যাঁ আমি করেছি। আমি এটির প্রোফাইল দিয়েছি এবং এটি ইএফ / ডিবি ইন্টারঅ্যাকশন যা প্রধান অপরাধী।

— ভ্যাকাকানো

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

— অ্যান্টনি পেগ্রাম 21

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

— MC9000

Answer 1

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

উদাহরণ:

Product product = db.Products.SingleOrDefault(p => p.Id == 10);
// executes SELECT * FROM Products WHERE Id = 10

ProductDto dto = new ProductDto();
foreach (Category category in product.Categories)
// executes SELECT * FROM Categories WHERE ProductId = 10
{
    dto.Categories.Add(new CategoryDto { Name = category.Name });
}

এর সাথে প্রতিস্থাপন করা যেতে পারে:

var query = from p in db.Products
            where p.Id == 10
            select new
            {
                p.Name,
                Categories = from c in p.Categories select c.Name
            };
ProductDto dto = new ProductDto();
foreach (var categoryName in query.Single().Categories)
// Executes SELECT p.Id, c.Name FROM Products as p, Categories as c WHERE p.Id = 10 AND p.Id = c.ProductId
{
    dto.Categories.Add(new CategoryDto { Name = categoryName });
}

আমি কেবল এটি আমার মাথার বাইরে টাইপ করেছি, সুতরাং এটি ঠিক কীভাবে কার্যকর করা হবে তা নয়, তবে আপনি যদি ক্যোয়ারী সম্পর্কে আপনার জানা সমস্ত কিছু জানান তবে EF আসলে কিছু সুন্দর অপ্টিমাইজেশন করে থাকে (এই ক্ষেত্রে আমাদের বিভাগের প্রয়োজন হবে- নাম)। তবে এটি আগ্রহী-লোডিংয়ের মতো নয় (db.Products.Inc شمولیت ("বিভাগগুলি")) কারণ অনুমানগুলি আরও লোডের জন্য ডেটা পরিমাণ হ্রাস করতে পারে।

Comments

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

— ডগ

এর ফলে আমার গতি 15x-20x বৃদ্ধি পেয়েছে।

— ডেভ কাজিনো

আকর্ষণীয় এবং সহায়ক জবাব, বেশ কিছুক্ষণ পরে বৈধ। @ ডউগ: যা আসলেই বুলিশিট নয় যেহেতু আপনি কেবলমাত্র সেই অতিরিক্ত কয়েকটি সুবিধাটি ব্যবহার করার প্রয়োজন সেই কয়েকটি প্রশ্নের (অনুকূলিতকরণগুলি ব্যবহার করে) optim EF এবং POCO আপনাকে যুক্তিসঙ্গত ডিফল্ট দেয়, যা খুব সুন্দর!

— ভিক্টর

@ ডউগ বেশিরভাগ অ্যাপ্লিকেশনগুলিতে কেবল দেখার জন্য দৃশ্যমান মডেল রয়েছে, তাই না? আপনি যতটা ম্যাপিং ডেটা বের করেন ততই ম্যাপিংও করতে পারে।

— কেসি

আমার মনে হয় ORM এর ভবিষ্যত ছিল। আমি তাদের ব্যবহার শুরু না করা অবধি তারা ঠিক বুঝেছিল। তারপরে আমি ড্যাপারকে পেলাম । এখন, এর মতো সমাধানগুলি দেখার সময়, কীভাবে জটিলতা দ্রুত বাড়ানো যায় তা আমি ক্রিঙ্ক করি। সি # তে অ্যাবস্ট্রাক্ট এসকিউএল লেখা জীবনের কোনও উপায় নয়।

— মাইকেল সিলভার

Answer 2

বিষয়টির সত্যতা হ'ল এন্টি ফ্রেমওয়ার্কের মতো পণ্যগুলি সবসময় ধীর এবং অদক্ষ হতে পারে কারণ তারা আরও অনেক কোড চালায়।

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

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

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

এবং এটিই আপনার সমস্যার সমাধান।

Comments

এটি স্নানের জল দিয়ে বাচ্চাকে বাইরে ফেলে দিচ্ছে। আপনি বাধাগুলি অপ্টিমাইজ করেছেন, EF কে ছুঁড়ে ফেলার মতো নির্বুদ্ধিতা কারণ এটি বেশ কয়েকটি জায়গায় খুব ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে ধীরে বেড়ে যায় most উভয় ব্যবহার করবেন না কেন? EF সঞ্চিত পদ্ধতি এবং কাঁচা এসকিউএল ঠিকঠাক পরিচালনা করে। আমি মাত্র একটি লিনিক্যু-টু-এসকিউএল ক্যোয়ারী রূপান্তর করেছি যা 10+ সেকেন্ড সময় নিয়ে একটি এসপিতে পরিণত হয় যা second 1 সেকেন্ড লাগে, কিন্তু আমি সমস্ত লিনিক-টু-এসকিউএলকে ফেলে দিতে যাচ্ছি না। এটি অন্যান্য সহজ ক্ষেত্রে প্রচুর সময় সাশ্রয় করেছে, কম কোড এবং ত্রুটির জন্য কম জায়গা রয়েছে এবং কোয়েরিগুলি সংকলিত হয় যাচাই করা হয় এবং ডেটাবেসটির সাথে মেলে। কম কোড হ'ল সহজ রক্ষণাবেক্ষণ এবং ত্রুটির জন্য কম জায়গা।

— জুলিয়ানআর

সামগ্রিকভাবে আপনার পরামর্শ যদিও ভাল, তবে আমি মনে করি না যে EF বা অন্যান্য বিমূর্তিগুলি ত্যাগ করা সঠিক কারণ তারা 10% সময় নিয়ে ভাল কাজ করে না।

— জুলিয়ানআর

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

— মেমডেভোপার

+ 10 ^ 100 খুব বিমূর্ততা একটি খারাপ 'প্যাটার্ন'

— মাকাচ

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

— ডেসপারটার

Answer 3

একটি পরামর্শ হ'ল লিনিকিউ থেকে সত্তা ফ্রেমওয়ার্ককে কেবল একক-রেকর্ড সিআরইউডি স্টেটমেন্টের জন্য ব্যবহার করা।

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

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

Comments

Db.athlete.find (id) ইত্যাদির মতো স্ক্যাফোল্ডিংয়ে ব্যবহৃত পদ্ধতিগুলি সম্পর্কে কী আপনার ধারণা আছে তারা ADO.NET বা ড্যাপারের সাথে কীভাবে তুলনা করে ??

— এটি একটি ফাঁদ

Answer 4

আপনি যদি বিশুদ্ধরূপে ডেটা আনছেন, আপনি যখন EF- কে এনেছেন সেগুলির সন্ধানের জন্য নজর রাখবেন না তখন এটি সম্পাদন করতে বড় সহায়তা। MergeOption.NoTracking ব্যবহার করে এটি করুন। EF সবেমাত্র ক্যোয়ারী উত্পন্ন করবে, এটিকে সম্পাদন করবে এবং ফলাফলগুলিকে বস্তুগুলিতে deserialize করবে, কিন্তু সত্তা পরিবর্তনগুলি বা সেই প্রকৃতির কোনও কিছুর উপর নজর রাখার চেষ্টা করবে না। যদি কোনও কোয়েরিটি সহজ হয় (ডাটাবেসে ফিরে যাওয়ার জন্য অপেক্ষা করতে খুব বেশি সময় ব্যয় করে না), আমি খুঁজে পেয়েছি যে এটি নো ট্র্যাকিংয়ে সেট করা কোয়েরি কার্যকারিতা দ্বিগুণ করতে পারে।

মার্জআপশন এনামে এই এমএসডিএন নিবন্ধটি দেখুন:

সনাক্তকরণ রেজোলিউশন, রাজ্য পরিচালনা, এবং পরিবর্তন ট্র্যাকিং

এটি ইএফ সম্পাদনের উপর একটি ভাল নিবন্ধ বলে মনে হচ্ছে:

পারফরম্যান্স এবং সত্তা ফ্রেমওয়ার্ক

Comments

যে কেউ এটি করার আগে এখানে পড়া ভাল হতে পারে। stackoverflow.com/questions/9259480/...

— leen3o

Answer 5

আপনি বলেছেন যে আপনি অ্যাপ্লিকেশনটি প্রোফাইল করেছেন। আপনি কি ওআরএমকে প্রোফাইল করেছেন? আয়েন্দির একজন ইএফ প্রোফাইলার রয়েছে যা হাইলাইট করবে যেখানে আপনি আপনার EF কোডটি অনুকূলিত করতে পারবেন। আপনি এখানে পেতে পারেন:

http://efprof.com/

মনে রাখবেন যে যদি আপনার পারফরম্যান্স অর্জন করতে হয় তবে আপনি নিজের ওআরএমের পাশাপাশি একটি aতিহ্যবাহী এসকিউএল পদ্ধতির ব্যবহার করতে পারেন।

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

ড্যাপার সাইটটি কিছু তুলনামূলক মানদণ্ড প্রকাশ করে যা আপনাকে অন্যান্য ওআরএম এর সাথে কীভাবে তুলনা করে তা আপনাকে ধারণা দেবে। তবে এটি লক্ষণীয় যে মাইক্রো-ওআরএমগুলি EF এবং NH এর মতো পূর্ণ ORM- র সমৃদ্ধ বৈশিষ্ট্য সেটটিকে সমর্থন করে না।

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

Answer 6

জিনিসগুলি দ্রুততর করার জন্য আমি এখানে @ স্লুমার উত্তরটি খুব দরকারী বলে খুঁজে পেয়েছি । আমি সন্নিবেশ এবং আপডেট উভয়ের জন্য একই ধরণের প্যাটার্ন ব্যবহার করেছি - এবং পারফরম্যান্স রকেটেড।

Answer 7

আমার অভিজ্ঞতা থেকে, সমস্যাটি ইএফের সাথে নয়, নিজেই ওআরএমের সাথে যোগাযোগের।

সাধারণভাবে সমস্ত ওআরএম N + 1 সমস্যায় ভুগছে না অনুকূলিত প্রশ্নগুলি ইত্যাদি My ইত্যাদি best

Comments

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

— সিনায়েস্টিক

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

— কেসি

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

— কেসি

Answer 8

এটি সাধারণ নন-ফ্রেমওয়ার্ক, নন-ওআরএম বিকল্প যা ৩০ টি ক্ষেত্র বা তার সাথে 10,000 / সেকেন্ডে লোড হয়। একটি পুরানো ল্যাপটপ চালানো, সম্ভবত একটি বাস্তব পরিবেশের চেয়ে সম্ভবত দ্রুত।

https://sourceforge.net/projects/dopersistance/?source=directory

Answer 9

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

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

আপনি যদি আমার ওআরএম চেষ্টা করতে চান তবে লিঙ্ক এবং ওয়েবসাইটটি এখানে রয়েছে:

https://github.com/jdemeuse1204/OR-M- ডেটা- এজেন্সি

অথবা আপনি যদি নাগেট ব্যবহার করতে চান:

প্রধানমন্ত্রী> ইনস্টল-প্যাকেজ OR বা M_DataEntities

ডকুমেন্টেশন পাশাপাশি আছে

Answer 10

আপনি প্রোফাইল দেওয়ার পরে এটি অনুকূলিতকরণে কেবল অর্থবোধ করে। আপনি যদি ডিবি অ্যাক্সেসটি ধীর গতিতে খুঁজে পান তবে আপনি সঞ্চিত পদ্ধতি ব্যবহার করে রূপান্তর করতে পারেন এবং EF রাখতে পারেন। আপনি যদি জানতে পারেন যে এটি নিজেই ইএফটি ধীর গতির হয়ে থাকে তবে আপনাকে অন্য কোনও ORM এ যেতে হবে বা কোনও ORM ব্যবহার করতে হবে না।

Answer 11

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

Comments

আমার কোডের 98% হ'ল কল তৈরি এবং আপডেট করুন। আমি জানি না যে এটি কোনও পার্থক্য করে কিনা, তবে এটি প্রতি সেকেন্ডে 120 এর চেয়ে অনেক ধীর।

— ভ্যাকাকানো 21

হ্যাঁ এটি একটি সাধারণ অ্যাপ্লিকেশন না হবে, আমি আপনাকে আপনার অ্যাপ্লিকেশনটির প্রোফাইল দেওয়ার পরামর্শ দেব। আমাদের জন্য এটি বেশিরভাগই পড়ে ...

— এনপি-হার্ড

Answer 12

আমি এসএকিউএল এবং ড্যাপার থেকে ইএফ, লিনকিউ ব্যবহার করেছি। ডিপার দ্রুততম। উদাহরণ: আমার প্রতিটি প্রতি 4 টি রেকর্ড সহ 1000 টি প্রধান রেকর্ডের প্রয়োজন। আমি স্কিল থেকে লিনকিউ ব্যবহার করেছি, এটি প্রায় 6 সেকেন্ড সময় নিয়েছিল। আমি তখন ড্যাপারে স্যুইচ করেছি, একক সঞ্চিত পদ্ধতি থেকে 2 টি রেকর্ড সেট পেয়েছি এবং প্রতিটি রেকর্ডের জন্য উপ রেকর্ড যুক্ত করেছে। মোট সময় 1 সেকেন্ড।

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

আমার পরামর্শটি হবে এসকিউএল এ EF বা লিনিকিউ ব্যবহার করা এবং নির্দিষ্ট পরিস্থিতিতে ড্যাপারে স্যুইচ করা।

Answer 13

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