في الجزء الأول من هذه المقالة، تعلمنا كيفية تحسين أداء تطبيقاتنا، واستبدال Tomcat بـ Undertow، وهو خادم ويب عالي الأداء، بالإضافة إلى تمكين وتكوين ضغط البيانات، لتقليل حجم استجابات HTTP التي تنتقل عبر الشبكة.

الآن، سنتحدث عن كيفية تحسين أداء تطبيق Spring Boot في جزء الثبات، لكن نحتاج أولاً إلى فهم ما JPA، Hibernate و Hikari.

JPA

JPA أو Java Persistence API ، والتي تمت إعادة تسميتها لاحقًا إلى Jakarta Persistence ، هو معيار لغة جافا يصف معيارًا شائعًا واجهة لأطر استمرارية البيانات

تحدد مواصفات

JPA التعيين العلائقي للكائن داخليًا، بدلاً من الاعتماد على تطبيقات التعيين الخاصة بالبائع.

السبات

السبات هو أحد أطر عمل ORM التي تجعل التنفيذ الملموس لمواصفات JPA . أي، إذا تم وصف في هذه المواصفات أن الطرق مطلوبة للاستمرار، إزالة ، التحديث و جلب البيانات ، فمن سيفعل ذلك في الواقع، يتم بناء هذه السلوكيات بواسطة Hibernate ، بالإضافة إلى EclipseLink ، وهو ORM .

هيكاري

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

تكوين Hikari، JPA والإسبات

التكوين الذي يمكننا إجراؤه لتحسين الأداء هو ما يلي:

استخدام application.yml:

ربيع: هيكاري: الالتزام التلقائي: خطأ مهلة الاتصال: 250 الحد الأقصى للعمر: 600000 الحد الأقصى لحجم المسبح: 20 الحد الأدنى للخمول: 10 اسم التجمع: سيد جبا: مفتوحة في الرأي: كاذبة عرض SQL: صحيح السبات: ddl-auto: لا يوجد ملكيات: hibernate.connection.provider_disables_autocommit: صحيح hibernate.generate_statistics: صحيح

spring:
  hikari:
    auto-commit: false
    connection-timeout: 250
    max-lifetime: 600000
    maximum-pool-size: 20
    minimum-idle: 10
    pool-name: master

  jpa:
    open-in-view: false
    show-sql: true
    hibernate:
      ddl-auto: none
    properties:
      hibernate.connection.provider_disables_autocommit: true
      hibernate.generate_statistics: true

استخدام خصائص التطبيق:

spring.datasource.hikari.auto-commit=false Spring.datasource.hikari.connection-timeout=50 Spring.datasource.hikari.max-lifetime=600000 Spring.datasource.hikari.maximum-pool-size=20 Spring.datasource.hikari.minimum-idle=10 Spring.datasource.hikari.pool-name=master Spring.datasource.jpa.open-in-view=false Spring.datasource.jpa.show-sql=true Spring.datasource.jpa.hibernate.ddl-auto=none Spring.jpa.properties.hibernate.generate_statistics=true Spring.jpa.properties.hibernate.connection.provider_disables_autocommit=true

spring:
  hikari:
    auto-commit: false
    connection-timeout: 250
    max-lifetime: 600000
    maximum-pool-size: 20
    minimum-idle: 10
    pool-name: master

  jpa:
    open-in-view: false
    show-sql: true
    hibernate:
      ddl-auto: none
    properties:
      hibernate.connection.provider_disables_autocommit: true
      hibernate.generate_statistics: true

الآن دعونا نقدم ملخصًا مختصرًا للخيارات:

هيكاري

• spring.datasource.hikari.auto-commit: إذا كان خطأ، فإن كل اتصال يتم إرجاعه بواسطة

  تجمع الاتصال سيأتي مع تعطيل الالتزام التلقائي.

  ]
• spring.datasource.hikari.connection-timeout: الوقت، بالمللي ثانية، الذي سينتظره العميل للاتصال من

  pool. من الأفضل تعيين مهلة قصيرة للفشل بسرعة وإرجاع رسالة خطأ، بدلاً من إبقاء العميل ينتظر إلى أجل غير مسمى.

• spring.datasource.hikari.max-lifetime: الحد الأقصى للوقت الذي يمكن أن يظل فيه الاتصال نشطًا. يعد تكوين هذه المعلمة أمرًا بالغ الأهمية لتجنب الفشل بسبب الاتصالات التي بها مشاكل ولزيادة الأمان، حيث أن الاتصالات التي كانت نشطة لفترة طويلة تكون أكثر عرضة للهجمات.

• spring.datasource.hikari.maximum-pool-size: الحد الأقصى لحجم التجمع

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

  من المهم العثور على قيمة مناسبة، حيث يعتقد الكثير من الأشخاص أنهم سيحصلون على أداء رائع من خلال ضبطها على 50 أو 70 أو حتى 100. والمثالي هو أن يكون الحد الأقصى 20، وهو عدد
  الخيوط
  • بالتوازي باستخدام الاتصالات. كلما ارتفعت القيمة، زادت صعوبة إدارة قاعدة البيانات لهذه الاتصالات وعلى الأرجح لن نتمكن من الحصول على ما يكفي من
  الإنتاجية
  • لاستخدام كل هذه الاتصالات. من المهم أن نفهم أنه من وجهة نظر
  RDBMS
  • (نظام إدارة قواعد البيانات العلائقية) من الصعب الحفاظ على اتصال مفتوح مع نفسه، تخيل عددًا n من الاتصالات .
spring.datasource.hikari.minimum-idle: الحد الأدنى لعدد الاتصالات التي يحتفظ بها المجمع عندما يكون الطلب منخفضًا. يمكن للمجمع تقليل الاتصالات حتى 10 وإعادة إنشائها حسب الحاجة. ومع ذلك، للحصول على أقصى أداء واستجابة أفضل لارتفاع الطلب، يوصى بعدم تعيين هذه القيمة، مما يسمح لـ Hikari بالعمل كمجموعة ذات حجم ثابت. الافتراضي: نفس Spring.datasource.hikari.maximum-pool-size.
spring.datasource.hikari.pool-name: اسم محدد من قبل المستخدم للاتصال
• تجمع

  ويظهر بشكل أساسي في وحدات تحكم إدارة التسجيل وJMX لتحديد حمامات السباحة وتكويناتها.

JPA

spring.datasource.jpa.open-in-view: عند تمكين
• OSIV

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

spring.datasource.jpa.show-sql: يعرض سجل SQL الذي يتم تنفيذه في تطبيقنا. بشكل عام، نتركها ممكنة في التطوير، ولكن معطلة في الإنتاج.
spring.datasource.jpa.hibernate.ddl-auto: تكوين سلوك

• الإسبات فيما يتعلق بمخطط لقاعدة البيانات. يمكن أن تحتوي على القيم التالية:

  لا شيء: لا يفعل شيئا. نحن ندير مخطط البنك يدويًا.
  • التحقق من الصحة: ​​التحقق من صحة مخطط
  قاعدة البيانات، دون إجراء أي تغييرات. يعد هذا مفيدًا للتأكد من أن مخطط
  • الحالي يتوافق مع الكيانات التي قمنا بتعيينها. التحديث: تحديث مخطط قاعدة البيانات ليعكس التغييرات التي تم إجراؤها على الكيانات.
  • إنشاء: إنشاء مخطط لقاعدة البيانات. إذا كان
  المخطط
  • موجودًا بالفعل، فسيتم إزالته وإنشائه مرة أخرى. create-drop: إنشاء المخطط من قاعدة البيانات، وعندما ينتهي التطبيق، يزيل
  المخطط
  • . مفيد للاختبار، حيث نريد قاعدة بيانات نظيفة لكل اختبار.
  spring.jpa.properties.hibernate.generate_statistics: يعمل على جمع معلومات تفصيلية حول السبات، مثل أوقات تنفيذ الاستعلام، وعدد الاستعلامات المنفذة، والمقاييس الأخرى.

• spring.jpa.properties.hibernate.connection.provider_disables_autocommit: يُعلم

الإسبات

• بأننا قمنا بتعطيل الالتزام التلقائي لمقدمي (PostgreSQL، MySQL، إلخ). يؤثر هذا على الأداء لأن Hibernate سيحتاج إلى الحصول على اتصال من pool لمعرفة ما إذا كان الالتزام التلقائي ممكّنًا أم لا ، عن كل معاملة يقوم بها. وبهذا نغلق الجزء الثاني من المقال. لم تكن جميع الإعدادات الموجودة تتعلق بالأداء، ولكن الإعدادات التي تؤثر حقًا هي إعدادات

مثل

الالتزام التلقائي و حجم التجمع ، تلك الخاصة بـ JPA و السبات مثل OSIV (فتح الجلسة في العرض) ونبلغك بأننا قمنا بتعطيل الالتزام التلقائي لمقدمي . في الجزء التالي سنتحدث عن الاستثناءات وكيف يمكن تهيئتها لحفظ الموارد من JVM (Java Virtual Machine

).

مراجع: https://en.wikipedia.org/wiki/Jakarta_Persistence

https://www.ibm.com/docs/pt-br/was/8.5.5?topic=SSEQTP_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/cejb_persistence.htm

https://github.com/brettwooldridge/HikariCP
https://github.com/corona-warn-app/cwa-server/issues/556
https://medium.com/@rafaelralf90/open-session-in-view-is-evil-fd9a21645f8e