🥇تحديد الحجم المناسب لمجموعة كافكا في Kubernetes

ملحوظة. ترجمة.: في هذه المقالة، تشارك Banzai Cloud مثالاً لكيفية استخدام أدواتها المخصصة لتسهيل استخدام Kafka داخل Kubernetes. توضح الإرشادات التالية كيف يمكنك تحديد الحجم الأمثل للبنية الأساسية لديك وتكوين Kafka نفسه لتحقيق الإنتاجية المطلوبة.

Apache Kafka عبارة عن منصة بث موزعة لإنشاء أنظمة بث موثوقة وقابلة للتطوير وعالية الأداء في الوقت الفعلي. يمكن توسيع قدراتها الرائعة باستخدام Kubernetes. لهذا قمنا بتطوير مشغل كافكا مفتوح المصدر وأداة تسمى الأنابيب الفائقة. إنها تسمح لك بتشغيل Kafka على Kubernetes واستخدام ميزاته المتنوعة، مثل ضبط تكوين الوسيط، والقياس على أساس المقياس مع إعادة التوازن، والوعي بالحامل، والأدوات "الناعمة" (رشيقة) نشر التحديثات وما إلى ذلك.

جرب Supertubes في مجموعتك:
curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>
أو الاتصال توثيق. يمكنك أيضًا أن تقرأ عن بعض إمكانيات Kafka، والتي يتم العمل بها تلقائيًا باستخدام Supertubes ومشغل Kafka. لقد كتبنا بالفعل عنهم على المدونة:

أوه لا! مشغل كافكا آخر لـ Kubernetes;

مراقبة وتشغيل كافكا بناءً على مقاييس بروميثيوس;

الوعي برف كافكا على Kubernetes;

تشغيل Apache Kafka على Istio - المعيار;

تمت مصادقة المستخدم والوصول إلى المجموعات التي يتم التحكم فيها من خلال مشغل Kafka;

ترقية Kafka المتداولة والتكوين الديناميكي على Kubernetes;

مرشح بروتوكول المبعوث لكافكا، متشابك.

عندما تقرر نشر مجموعة كافكا على Kubernetes، فمن المحتمل أن تواجه التحدي المتمثل في تحديد الحجم الأمثل للبنية التحتية الأساسية والحاجة إلى ضبط تكوين كافكا الخاص بك لتلبية متطلبات الإنتاجية. يتم تحديد الحد الأقصى للأداء لكل وسيط من خلال أداء مكونات البنية التحتية الأساسية، مثل الذاكرة والمعالج وسرعة القرص وعرض النطاق الترددي للشبكة وما إلى ذلك.

ومن الناحية المثالية، ينبغي أن يكون تكوين الوسيط بحيث يتم استخدام جميع عناصر البنية التحتية إلى أقصى قدراتها. ومع ذلك، في الحياة الحقيقية، هذا الإعداد معقد للغاية. من المرجح أن يقوم المستخدمون بتكوين الوسطاء لتعظيم استخدام مكون واحد أو مكونين (القرص أو الذاكرة أو المعالج). بشكل عام، يُظهر الوسيط الحد الأقصى من الأداء عندما يسمح تكوينه باستخدام المكون الأبطأ إلى أقصى حد. بهذه الطريقة يمكننا الحصول على فكرة تقريبية عن العبء الذي يمكن أن يتعامل معه وسيط واحد.

من الناحية النظرية، يمكننا أيضًا تقدير عدد الوسطاء المطلوبين للتعامل مع حمولة معينة. ومع ذلك، من الناحية العملية، هناك العديد من خيارات التكوين على مستويات مختلفة، مما يجعل من الصعب جدًا (إن لم يكن من المستحيل) تقييم الأداء المحتمل لتكوين معين. بمعنى آخر، من الصعب جدًا التخطيط لتكوين بناءً على أداء معين.

بالنسبة لمستخدمي Supertubes، نتبع عادةً النهج التالي: نبدأ ببعض التكوينات (البنية التحتية + الإعدادات)، ثم نقيس أدائها ونضبط إعدادات الوسيط ونكرر العملية مرة أخرى. ويحدث هذا حتى يتم الاستفادة الكاملة من أبطأ مكون في البنية التحتية.

بهذه الطريقة، نحصل على فكرة أوضح عن عدد الوسطاء الذين تحتاجهم المجموعة للتعامل مع حمل معين (يعتمد عدد الوسطاء أيضًا على عوامل أخرى، مثل الحد الأدنى لعدد النسخ المتماثلة للرسائل لضمان المرونة، وعدد الأقسام القادة، الخ). بالإضافة إلى ذلك، نحصل على نظرة ثاقبة حول مكونات البنية التحتية التي تتطلب التوسع الرأسي.

ستتحدث هذه المقالة عن الخطوات التي نتخذها لتحقيق أقصى استفادة من المكونات الأبطأ في التكوينات الأولية وقياس إنتاجية مجموعة كافكا. يتطلب التكوين عالي المرونة ثلاثة وسطاء على الأقل (min.insync.replicas=3)، موزعة على ثلاث مناطق وصول مختلفة. لتكوين البنية التحتية لـ Kubernetes وتوسيع نطاقها ومراقبتها، نستخدم منصة إدارة الحاويات الخاصة بنا للسحابات المختلطة - خط أنابيب. وهو يدعم الأنظمة الداخلية (المعدنية، وVMware) وخمسة أنواع من السحابة (Alibaba، وAWS، وAzure، وGoogle، وOracle)، بالإضافة إلى أي مجموعة منها.

أفكار حول البنية التحتية وتكوين مجموعة كافكا

بالنسبة للأمثلة الواردة أدناه، اخترنا AWS كموفر السحابة وEKS كتوزيع Kubernetes. يمكن تنفيذ تكوين مماثل باستخدام بي كي إي - توزيع Kubernetes من Banzai Cloud، معتمد من CNCF.

أسطوانة

تقدم أمازون مختلف أنواع وحدات تخزين EBS. في الصميم gp2 и io1 ومع ذلك، توجد محركات أقراص SSD لضمان إنتاجية عالية gp2 يستهلك الاعتمادات المتراكمة (اعتمادات الإدخال / الإخراج)لذلك فضلنا النوع io1، والذي يوفر إنتاجية عالية متسقة.

أنواع المثيلات

يعتمد أداء كافكا بشكل كبير على ذاكرة التخزين المؤقت لصفحة نظام التشغيل، لذلك نحتاج إلى مثيلات ذات ذاكرة كافية للوسطاء (JVM) وذاكرة التخزين المؤقت للصفحة. مثال c5.2xlarge - بداية جيدة، حيث أنها تحتوي على 16 جيجابايت من الذاكرة و الأمثل للعمل مع EBS. عيبه هو أنه قادر فقط على توفير أقصى قدر من الأداء لمدة لا تزيد عن 30 دقيقة كل 24 ساعة. إذا كان عبء العمل الخاص بك يتطلب ذروة الأداء على مدى فترة زمنية أطول، فقد ترغب في التفكير في أنواع مثيلات أخرى. وهذا بالضبط ما فعلناه، توقفنا عنده c5.4xlarge. يوفر أقصى قدر من الإنتاجية في 593,75 ميجابايت/ثانية. الحد الأقصى من الإنتاجية لوحدة تخزين EBS io1 أعلى من المثال c5.4xlarge، لذلك من المحتمل أن يكون أبطأ عنصر في البنية التحتية هو إنتاجية الإدخال/الإخراج لهذا النوع من المثيل (وهو ما يجب أن تؤكده اختبارات التحميل لدينا أيضًا).

Сеть

يجب أن تكون سرعة نقل الشبكة كبيرة بما يكفي مقارنة بأداء مثيل VM والقرص، وإلا ستصبح الشبكة عنق الزجاجة. في حالتنا، واجهة الشبكة c5.4xlarge يدعم سرعات تصل إلى 10 جيجابت/ثانية، وهو أعلى بكثير من إنتاجية الإدخال/الإخراج لمثيل VM.

نشر الوسيط

يجب نشر الوسطاء (مجدولين في Kubernetes) على العقد المخصصة لتجنب التنافس مع العمليات الأخرى على موارد وحدة المعالجة المركزية والذاكرة والشبكة والقرص.

نسخة جافا

الخيار المنطقي هو Java 11 لأنه متوافق مع Docker، بمعنى أن JVM يحدد بشكل صحيح المعالجات والذاكرة المتوفرة للحاوية التي يعمل بها الوسيط. مع العلم أن حدود وحدة المعالجة المركزية مهمة، يقوم JVM بتعيين عدد سلاسل عمليات GC وسلاسل JIT داخليًا وبشفافية. استخدمنا صورة كافكا banzaicloud/kafka:2.13-2.4.0، والذي يتضمن إصدار Kafka 2.4.0 (Scala 2.13) على Java 11.

إذا كنت ترغب في معرفة المزيد حول Java/JVM على Kubernetes، فراجع منشوراتنا التالية:

لماذا تم قتل تطبيق Java الخاص بي؟;

كيفية تحديد حجم الحاويات لتطبيقات Java 10 بشكل صحيح.

إعدادات ذاكرة الوسيط

هناك جانبان رئيسيان لتكوين ذاكرة الوسيط: إعدادات JVM وحجرة Kubernetes. يجب أن يكون حد الذاكرة المعين للكبسولة أكبر من الحد الأقصى لحجم الكومة بحيث يكون لدى JVM مساحة لمساحة تعريف Java الموجودة في ذاكرته الخاصة ولذاكرة التخزين المؤقت لصفحة نظام التشغيل التي يستخدمها Kafka بشكل نشط. في اختباراتنا أطلقنا وسطاء كافكا مع المعلمات -Xmx4G -Xms2Gوكان حد الذاكرة للجراب 10 Gi. يرجى ملاحظة أنه يمكن الحصول على إعدادات الذاكرة الخاصة بـ JVM تلقائيًا باستخدام -XX:MaxRAMPercentage и -X:MinRAMPercentage، استنادًا إلى الحد الأقصى للذاكرة الخاصة بالكبسولة.

إعدادات معالج الوسيط

بشكل عام، يمكنك تحسين الأداء عن طريق زيادة التوازي عن طريق زيادة عدد الخيوط التي يستخدمها كافكا. كلما زاد عدد المعالجات المتوفرة لكافكا، كان ذلك أفضل. في اختبارنا، بدأنا بحد أقصى 6 معالجات ثم رفعنا عددها تدريجيًا (من خلال التكرارات) إلى 15. بالإضافة إلى ذلك، قمنا بتعيين num.network.threads=12 في إعدادات الوسيط لزيادة عدد الخيوط التي تستقبل البيانات من الشبكة وترسلها. واكتشفوا على الفور أن الوسطاء التابعين لم يتمكنوا من استلام النسخ المتماثلة بالسرعة الكافية، وقاموا برفعها num.replica.fetchers إلى 4 لزيادة السرعة التي يقوم بها الوسطاء المتابعون بنسخ الرسائل من القادة.

أداة توليد التحميل

يجب عليك التأكد من عدم نفاد سعة مولد التحميل المحدد قبل أن تصل مجموعة كافكا (التي يتم قياسها) إلى الحد الأقصى للتحميل. بمعنى آخر، من الضروري إجراء تقييم أولي لقدرات أداة توليد التحميل، وكذلك تحديد أنواع المثيلات لها بعدد كاف من المعالجات والذاكرة. في هذه الحالة، ستنتج أداتنا حملًا أكبر مما تستطيع مجموعة كافكا التعامل معه. وبعد تجارب كثيرة استقرينا على ثلاث نسخ c5.4xlarge، وكان لكل منها مولد يعمل.

المرجعية

قياس الأداء هو عملية متكررة تتضمن المراحل التالية:

إعداد البنية التحتية (مجموعة EKS، ومجموعة Kafka، وأداة توليد التحميل، بالإضافة إلى Prometheus وGrafana)؛
توليد حمل لفترة معينة لتصفية الانحرافات العشوائية في مؤشرات الأداء المجمعة؛
تعديل البنية التحتية للوسيط وتكوينه بناءً على مؤشرات الأداء الملحوظة؛
تكرار العملية حتى يتم تحقيق المستوى المطلوب من إنتاجية مجموعة كافكا. وفي الوقت نفسه، يجب أن يكون قابلاً للتكرار بشكل ثابت وأن يُظهر الحد الأدنى من الاختلافات في الإنتاجية.

يصف القسم التالي الخطوات التي تم تنفيذها أثناء عملية قياس الأداء لمجموعة الاختبار.

أدوات

تم استخدام الأدوات التالية لنشر التكوين الأساسي بسرعة وإنشاء الأحمال وقياس الأداء:

خط أنابيب بانزاي كلاود لتنظيم مجموعة EKS من أمازون ج محب العمل (لجمع مقاييس كافكا والبنية التحتية) و جرافانا (لتصور هذه المقاييس). لقد استفدنا مدمج в خط أنابيب الخدمات التي توفر المراقبة الموحدة وجمع السجلات المركزية وفحص الثغرات الأمنية والتعافي من الكوارث والأمان على مستوى المؤسسة وغير ذلك الكثير.
سانغرينيل - أداة لاختبار التحميل لمجموعة كافكا.
لوحات معلومات Grafana لتصور مقاييس كافكا والبنية التحتية: كوبيرنيتيس كافكا, مصدر العقدة.
Supertubes CLI لأسهل طريقة لإعداد مجموعة Kafka على Kubernetes. تم تثبيت Zookeeper ومشغل Kafka وEnvoy والعديد من المكونات الأخرى وتكوينها بشكل صحيح لتشغيل مجموعة Kafka الجاهزة للإنتاج على Kubernetes.
- من أجل التثبيت supertubes CLI استخدم التعليمات المقدمة هنا.

مجموعة EKS

قم بإعداد مجموعة EKS مع العقد العاملة المخصصة c5.4xlarge في مناطق توافر مختلفة للقرون مع وسطاء كافكا، بالإضافة إلى العقد المخصصة لمولد الأحمال والبنية التحتية للمراقبة.

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

بمجرد تشغيل مجموعة EKS، قم بتمكين دمجها خدمة المراقبة - ستقوم بنشر بروميثيوس وجرافانا في مجموعة.

مكونات نظام كافكا

تثبيت مكونات نظام Kafka (Zookeeper، kafka-operator) في EKS باستخدام supertubes CLI:

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

كتلة كافكا

افتراضيًا، يستخدم EKS وحدات تخزين EBS من النوع gp2، لذلك تحتاج إلى إنشاء فئة تخزين منفصلة بناءً على وحدات التخزين io1 لمجموعة كافكا:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

قم بتعيين المعلمة للوسطاء min.insync.replicas=3 ونشر حجرات الوسيط على العقد في ثلاث مناطق توافر مختلفة:

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

المواضيع

قمنا بتشغيل ثلاث مثيلات لمولد الأحمال بالتوازي. كل واحد منهم يكتب لموضوعه الخاص، أي أننا نحتاج إلى ثلاثة مواضيع في المجمل:

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

بالنسبة لكل موضوع، يكون عامل النسخ المتماثل هو 3 — وهو الحد الأدنى للقيمة الموصى بها لأنظمة الإنتاج المتوفرة بشكل كبير.

أداة توليد التحميل

أطلقنا ثلاث نسخ من مولد الأحمال (كل واحدة مكتوبة في موضوع منفصل). بالنسبة لكبسولات المولدات التحميلية، تحتاج إلى تعيين تقارب العقدة بحيث تتم جدولتها فقط على العقد المخصصة لها:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

بعض النقاط يجب ملاحظتها:

يقوم منشئ التحميل بإنشاء رسائل يبلغ طولها 512 بايت وينشرها إلى كافكا على دفعات مكونة من 500 رسالة.
باستخدام حجة -required-acks=all يعتبر النشر ناجحًا عندما يتم استلام جميع النسخ المتماثلة المتزامنة للرسالة وتأكيدها بواسطة وسطاء كافكا. وهذا يعني أننا في المعيار لم نقم فقط بقياس سرعة تلقي القادة للرسائل، ولكن أيضًا تكرار متابعيهم للرسائل. الغرض من هذا الاختبار ليس تقييم سرعة قراءة المستهلك (المستهلكون) الرسائل المستلمة مؤخرًا والتي لا تزال موجودة في ذاكرة التخزين المؤقت لصفحة نظام التشغيل، ومقارنتها بسرعة قراءة الرسائل المخزنة على القرص.
يقوم مولد الحمل بتشغيل 20 عاملاً بالتوازي (-workers=20). يحتوي كل عامل على 5 منتجين يتشاركون في اتصال العامل بمجموعة كافكا. ونتيجة لذلك، فإن كل مولد لديه 100 منتج، وكلهم يرسلون رسائل إلى مجموعة كافكا.

مراقبة صحة الكتلة

أثناء اختبار التحميل لمجموعة Kafka، قمنا أيضًا بمراقبة صحتها للتأكد من عدم وجود عمليات إعادة تشغيل للكبسولة، وعدم وجود نسخ متماثلة غير متزامنة، والحد الأقصى من الإنتاجية بأقل قدر من التقلبات:

يكتب منشئ التحميل إحصائيات قياسية حول عدد الرسائل المنشورة ومعدل الخطأ. يجب أن يظل معدل الخطأ كما هو 0,00%.
التحكم في السرعة، الذي تم نشره بواسطة مشغل kafka، يوفر لوحة معلومات حيث يمكننا أيضًا مراقبة حالة المجموعة. لعرض هذه اللوحة قم بما يلي:
```
supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>
```
مستوى الاستخبارات والمراقبة والاستخبارات (عدد النسخ المتماثلة "المتزامنة") الانكماش والتوسع يساوي 0.

نتائج القياس

3 وسطاء، حجم الرسالة - 512 بايت

مع توزيع الأقسام بالتساوي عبر ثلاثة وسطاء، تمكنا من تحقيق الأداء ~500 ميجا بايت/ثانية (حوالي 990 ألف رسالة في الثانية):

لم يتجاوز استهلاك ذاكرة الجهاز الظاهري JVM 2 جيجابايت:

وصلت إنتاجية القرص إلى الحد الأقصى من إنتاجية عقدة الإدخال/الإخراج في جميع الحالات الثلاث التي كان الوسطاء يعملون عليها:

من البيانات المتعلقة باستخدام الذاكرة بواسطة العقد، يترتب على ذلك أن التخزين المؤقت للنظام والتخزين المؤقت استغرق حوالي 10 إلى 15 جيجابايت:

3 وسطاء، حجم الرسالة - 100 بايت

مع انخفاض حجم الرسالة، تنخفض الإنتاجية بنسبة 15-20% تقريبًا: ويؤثر عليها الوقت المستغرق في معالجة كل رسالة. بالإضافة إلى ذلك، تضاعف حمل المعالج تقريبًا.

نظرًا لأن عقد الوسيط لا تزال تحتوي على مراكز غير مستخدمة، فيمكن تحسين الأداء عن طريق تغيير تكوين كافكا. هذه ليست مهمة سهلة، لذا لزيادة الإنتاجية فمن الأفضل العمل مع رسائل أكبر حجمًا.

4 وسطاء، حجم الرسالة - 512 بايت

يمكنك بسهولة زيادة أداء مجموعة كافكا ببساطة عن طريق إضافة وسطاء جدد والحفاظ على توازن الأقسام (وهذا يضمن توزيع الحمل بالتساوي بين الوسطاء). في حالتنا، بعد إضافة وسيط، زادت إنتاجية المجموعة إلى ~580 ميجا بايت/ثانية (~1,1 مليون رسالة في الثانية). تبين أن النمو أقل من المتوقع: ويرجع ذلك أساسًا إلى عدم توازن الأقسام (لا يعمل جميع الوسطاء في ذروة قدراتهم).

ظل استهلاك الذاكرة لجهاز JVM أقل من 2 جيجابايت:

تأثر عمل الوسطاء الذين لديهم محركات أقراص بسبب عدم توازن الأقسام:

النتائج

يمكن توسيع النهج التكراري الموضح أعلاه ليشمل سيناريوهات أكثر تعقيدًا تشمل مئات المستهلكين، وإعادة التقسيم، والتحديثات المتجددة، وإعادة تشغيل الكبسولة، وما إلى ذلك. كل هذا يسمح لنا بتقييم حدود قدرات مجموعة كافكا في مختلف الظروف، وتحديد الاختناقات في عملها وإيجاد طرق لمكافحتها.

لقد صممنا Supertubes لنشر مجموعة بسرعة وسهولة، وتكوينها، وإضافة/إزالة الوسطاء والموضوعات، والاستجابة للتنبيهات، والتأكد من أن Kafka بشكل عام يعمل بشكل صحيح على Kubernetes. هدفنا هو مساعدتك على التركيز على المهمة الرئيسية ("إنشاء" و"استهلاك" رسائل كافكا)، وترك كل العمل الشاق لـ Supertubes ومشغل كافكا.

إذا كنت مهتمًا بتقنيات Banzai Cloud والمشاريع مفتوحة المصدر، فاشترك في الشركة على GitHub جيثب:, لينكدين: أو تويتر.

PS من المترجم

اقرأ أيضًا على مدونتنا:

المصدر: www.habr.com

حدد الحجم المناسب لعنقود كافكا في Kubernetes

أفكار حول البنية التحتية وتكوين مجموعة كافكا

أسطوانة

أنواع المثيلات

Сеть

نشر الوسيط

نسخة جافا

إعدادات ذاكرة الوسيط

إعدادات معالج الوسيط

أداة توليد التحميل

المرجعية

أدوات

مجموعة EKS

مكونات نظام كافكا

كتلة كافكا

المواضيع

أداة توليد التحميل

مراقبة صحة الكتلة

نتائج القياس

3 وسطاء، حجم الرسالة - 512 بايت

3 وسطاء، حجم الرسالة - 100 بايت

4 وسطاء، حجم الرسالة - 512 بايت

النتائج

PS من المترجم

إضافة تعليق إلغاء الرد