জিআরপিসি: জাভা / স্কালায় হাই-থ্রুপুট ক্লায়েন্ট তৈরি করুন


9

আমার একটি পরিষেবা আছে যা বেশ উচ্চ হারে বার্তা স্থানান্তর করে।

বর্তমানে এটি আক্কা-টিসিপি দ্বারা পরিবেশন করা হয় এবং এটি প্রতি মিনিটে 3.5M বার্তা দেয়। আমি জিআরপিসি চেষ্টা করে দেখার সিদ্ধান্ত নিয়েছি। দুর্ভাগ্যক্রমে এর ফলে অনেক ছোট থ্রুপুট হয়েছিল: প্রতি মিনিটে ~ 500k বার্তা আরও কম।

আপনি দয়া করে এটি কীভাবে অপ্টিমাইজ করবেন তা বলতে পারেন?

আমার সেটআপ

হার্ডওয়্যার : 32 কোর, 24 জিবি হিপ।

grpc সংস্করণ : 1.25.0

বার্তা বিন্যাস এবং শেষ পয়েন্ট

বার্তাটি মূলত একটি বাইনারি ব্লব। ক্লায়েন্ট একই অনুরোধে 100K - 1 এম এবং আরও বার্তা প্রবাহিত করে (অবিচ্ছিন্নভাবে), সার্ভারটি কোনও কিছুর সাথে সাড়া দেয় না, ক্লায়েন্ট কোনও অনির্বাচিত পর্যবেক্ষক ব্যবহার করে

service MyService {
    rpc send (stream MyMessage) returns (stream DummyResponse);
}

message MyMessage {
    int64 someField = 1;
    bytes payload = 2;  //not huge
}

message DummyResponse {
}

সমস্যা: আক্কা বাস্তবায়নের তুলনায় বার্তার হার কম। আমি কম সিপিইউ ব্যবহার পর্যবেক্ষণ করি তাই আমার সন্দেহ হয় যে জিপিসি কলটি অন্যথায় কিছু বলার পরেও অভ্যন্তরীণভাবে আটকাচ্ছে। কলিং onNext()সত্যই তত্ক্ষণাত্ ফিরে আসে না তবে টেবিলে জিসিও রয়েছে।

আমি এই সমস্যাটি প্রশমিত করার জন্য আরও প্রেরককে স্প্যান করার চেষ্টা করেছি কিন্তু খুব বেশি উন্নতি পাই নি।

আমার অনুসন্ধানগুলি Grpc প্রকৃতপক্ষে প্রতিটি বার্তায় একটি 8KB বাইট বাফার বরাদ্দ করে যখন এটি সিরিয়াল করে তোলে। স্ট্যাকট্রেস দেখুন:

java.lang.Thread.State: com.google.common.io.ByteStreams.createBuffer (ByteStreams.java:58) at com.google.common.io.ByteStreams.copy (বাইটস্ট্রিমস.জেভা: ব্লক (অবজেক্ট মনিটরে) 105) io.grpc.intern.MessageFramer.writeToOutputStream (MessageFramer.javaferences74) এ io.grpc.intern.MessageFramer.writeK পরিচিতLengthUncompressed (ম্যাসেজফ্রেমার.জাভা অধিকারসমূহ 30) এ io.grpc.intern.MessageFramer.witter.com Io.grpc.intern.MessageFramer.writPayload (বার্তা ফ্রেম.জভা 1411) এ io.grpc.intern.AbstractStream.writeMessage (AbstractStream.java:53) এ io.grpc.intern.FordingClientstreams.writingMessage (ফরওয়ার্ডক্লিনস্ট্রিম.কম) এ: 168)। java: 37) io.grpc.intern.DelayedStream.writeMessage (বিলম্বিত স্ট্রিম.জভা:252) এ io.grpc.intern এ।Io.grpc.intern.ClientCallImpl.sendMessage (ClientCallImpl.java:457) এ Io.grpc.ForderingClientCall.sendMessage.ConentClice.CenceCCesce7CCCententCall.sendMessage.CoentClia.Cenent.Cenent.Cenent.Cenent.Cenent.Cenent.Cend উপর (ফরওয়ার্ডিং ক্লায়েন্টক্যাল.জভা ৩:37) io.grpc.stub.ClientCalls $ কলটোস্ট্রিমঅবসরবার অ্যাডাপ্টার.অনেক্সট (ক্লায়েন্টকলস.জভা :34646))

উচ্চ-মাধ্যমে আউটপুট জিআরপিসি ক্লায়েন্ট তৈরির সর্বোত্তম অনুশীলনের সাথে যে কোনও সহায়তা প্রশংসিত।


আপনি কি প্রোটোবুফ ব্যবহার করছেন? এই কোড পাথটি কেবল তখনই নেওয়া উচিত যদি ইনপুট স্ট্রিমটি মেথডেস্ক্রিপ্টর দ্বারা ফিরে আসে M মার্শাল্লেয়ার স্ট্রিম () ড্রেনযোগ্যকে কার্যকর না করে। প্রোটোবুফ মার্শালার ড্রেনযোগ্যকে সমর্থন করে। আপনি যদি প্রোটোবুফ ব্যবহার করছেন তবে কী কোনও ক্লায়েন্টইন্টারসেপ্টর মেথডডেস্কিপ্টর পরিবর্তন করছে?
এরিক অ্যান্ডারসন

@ এরিক অ্যান্ডারসন আপনার প্রতিক্রিয়ার জন্য আপনাকে ধন্যবাদ। আমি গ্রেড (com.google.protobuf: প্রোটোক: 3.10.1, io.grpc: প্রোটোক-জেন-গ্রিপসি-জাভা: 1.25.0) সহ স্ট্যান্ডার্ড প্রোটোবফ চেষ্টা করেছি scalapb। সম্ভবত এই স্ট্যাকট্রেস প্রকৃতপক্ষে স্কেল্যাপবি-উত্পন্ন কোড থেকে শুরু করে। আমি স্কেল্যাপব সম্পর্কিত সমস্ত কিছু সরিয়ে ফেলেছি তবে এটি আর্টের পারফরম্যান্সে খুব একটা সহায়তা করে নি।
ইম্পাদাজো

@ এরিক অ্যান্ডারসন আমি আমার সমস্যার সমাধান করেছি। আপনাকে জিআরপিসি-র বিকাশকারী হিসাবে পিং করছে। আমার উত্তরটি কি কোনও অর্থবোধ করে?
সিমাদাজো

উত্তর:


4

ManagedChannelগন্তব্য প্রতি বেশ কয়েকটি দৃষ্টান্ত তৈরি করে আমি সমস্যার সমাধান করেছি । নিবন্ধগুলি সত্ত্বেও যে একটি ManagedChannelযথেষ্ট সংযোগ নিজেই তৈরি করতে পারে তাই একটি উদাহরণই যথেষ্ট যে এটি আমার ক্ষেত্রে সত্য ছিল না।

আক্কা-টিসিপি প্রয়োগের সাথে পারফরম্যান্স সমান।


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

ধন্যবাদ এরিক অ্যান্ডারসন আমার ক্ষেত্রে এমনকি একক ব্যাকএন্ড নোডে বেশ কয়েকটি চ্যানেল তৈরি করা সহায়তা করেছে
সাদাদাজো

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

0

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

উদাহরণস্বরূপ gRPCউপরে তৈরি করা হয় HTTP 1.1/2, যা অ্যাপ্লিকেশন স্তরের একটি প্রোটোকল , বা L7, এবং যেমন এর কর্মক্ষমতা এর পারফরম্যান্স দ্বারা আবদ্ধ HTTP। এখন HTTPনিজেই শীর্ষে তৈরি করা হচ্ছে TCP, যা পরিবহন স্তরে রয়েছে , বা L4তাই আমরা অনুমান করতে পারি যে স্তরটি পরিবেশন করা সমতুল্য কোডের চেয়ে gRPCথ্রুটপুট বৃহত্তর হতে পারে নাTCP

অন্য কথায়: আপনার সার্ভারটি যদি কাঁচা TCPপ্যাকেজগুলি পরিচালনা করতে সক্ষম হয় তবে কীভাবে জটিলতার নতুন স্তর যুক্ত করা ( gRPC) এর কার্যকারিতা উন্নত হবে?


ঠিক সেই কারণে আমি স্ট্রিমিং পদ্ধতির ব্যবহার করি: আমি কোনও HTTP সংযোগ স্থাপনের জন্য একবার অর্থ প্রদান করি এবং এটি ব্যবহার করে ~ 300M বার্তা প্রেরণ করি। এটি হুডের নীচে ওয়েবসকেট ব্যবহার করে যা আমি তুলনামূলকভাবে কম ওভারহেডের আশা করি।
সিমাদাজো

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

আক্কা পাশাপাশি কিছু ওভারহেড জুড়েছে। যাইহোক x5 স্লোডাউন খুব বেশি দেখায়।
সাদাদাজো

আমি মনে করি আপনি এটি আকর্ষণীয় খুঁজে পেতে পারেন: github.com/REASY/akka-http-vs-akka-grpc , তার ক্ষেত্রে (এবং আমি মনে করি এটি আপনার প্রসারিত হবে), প্রটবুফে উচ্চ মেমরির ব্যবহারের কারণে বাধাটি হতে পারে (ডি ) সিরিয়ালাইজেশন যা ফলস্বরূপ আবর্জনা সংগ্রহকারীকে আরও কল দেয়।
বাটাটো

ধন্যবাদ, আমি ইতিমধ্যে আমার সমস্যাটি সমাধান করার পরেও আকর্ষণীয়
সাদাদাজো

0

আক্কা টিসিপি এখানে কতটা ভাল পারফর্ম করেছে তাতে আমি বেশ মুগ্ধ হয়েছি: ডি

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

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

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