Cara menggunakan mysql connection overhead

Versi merupakan hal yang penting untuk sebuah aplikasi, versi dapat mewakili fitur dan perkembangan aplikasi tersebut agar dapat dengan mudah diketahui oleh user. Selain itu versi dapat menjadi salah satu patokan kompatibilitas untuk mengintegrasikan dengan aplikasi lainnya, Salah satunya pada aplikasi Database MySQL, versi merupakan identitas penting untuk pengembang aplikasi dan Database Administrator.

Cara mengetahui versi Database MySQL

Database MySQL memiliki beberapa cara untuk melihat versi yang tertanam didalamnya. Cara mengetahui versi MySQL dapat menggunakan 2 metode, antara lain menggunakan Command line dan menggunakan aplikasi GUI (Aplikasi berbasis grafis).

Baca Juga :
Sesi Q&A tentang MySQL bersama Rois Korniawan

Menggunakan antarmuka CLI

1. Cara pertama adalah menggunakan CLI/Terminal, Pertama-tama pastikan instance database sudah berjalan. Untuk memastikan instance sudah berjalan di background process dapat menggunakan command berikut :

   systemctl status mysqld.service

    

2. Jika instance telah berjalan di background process maka akan menghasilkan tampilan CLI seperti berikut :
   

3. Langkah selanjutnya masuk kedalam mysql dengan menggunakan command sebagai berikut :

   systemctl status mysqld.service

   

4. Setelah menjalankan command di atas langkah selanjutnya adalah memasukkan password user yag digunakan. Jika password dan user yang digunakan tersedia maka akan masuk ke dalam mysql.
   
   
   Selanjutnya gunakan query dibawah ini untuk mengetahui versi mysql yang kita gunakan:

   Mysql> SELECT @@version;

   Atau :
   Ketika menjalankan query di atas maka hasilnya akan seperti berikut :

   
   Dari hasil yang di tampilkan oleh terminal yang saya gunakan dapat terlihat bahwa database MySQL yang saya gunakan adalah veri 8.0.11. Perbedaan pemanggilannya adalah jika yang versi “SELECT @@VERSION” kita memanggil sebuah variable yang berada di database yang isinya adalah versi database yang kita gunakan, jika versi “SELECT VERSION()” kita memanggil sebuah fungsi yang sudah MySQL sediakan untuk mengetahui versi server yang kita gunakan.

Menggunakan Antarmuka GUI

Yang kedua adalah dengan menggunakan aplikasi antarmuka berbasis GUI, aplikasi yang saya gunakan adalah MySQL Workbench.Jika anda belum memiliki MySQL Workbench maka anda dapat mendownload aplikasi tersebut melalui portal web MySQL : https://dev.mysql.com/downloads/workbench/?utm_source=tuicool Aplikasi MySQL workbench yang saya gunakan adalah MySQL Workbench dengan versi 6.3.

1. Cara pertama yang harus dilakukan adalah buat sebuah koneksi agar MySQL Workbench dapat membaca data dari server MySQL dengan cara Add Connections.
   

2. Jika connection telah berhasil di tambahkan maka akan muncul icon berupa informasi server yg kita tambahkan di aplikasi MySQL Workbench.
   

3. Klik konfigurasi yang telah dibuat berdasarkan nama server yang anda buat, contoh dari konfigurasi yang saya buat saya berikan nama new_connection.

Jika sudah berhasil maka halaman pertama yang akan di tuju adalah seperti gambar di bawah ini.

4. Untuk mengetahui versi MySQL yang sedang di gunakan caranya cukup dengan menekan Klik pada link “Server Status” yang berada di sebelah kiri aplikasi. Dan hasilnya adalah seperti berikut.

Baca Juga :
PostgreSQL vs MySQL: Mana yang Terbaik dan Cocok untuk Infrastruktur IT Anda?

Demikian trik untuk mengetahui versi database MySQL menggunakan MySQL Workbench Interface dan Command Line Interface.

Untuk kebutuhan manajemen data perusahaan Anda, Anda bisa dapat melihat informasi selengkapnya melalui solusi data management kami, atau kontak langsung tim sales kami untuk info lebih lanjut.

MySQL Community Edition manages connections in a one-thread-per-connection fashion. This means that each individual user connection receives a dedicated operating system thread in the mysqld process. Issues with this type of connection handling include:

• Relatively high memory use when there is a large number of user connections, even if the connections are completely idle

• Higher internal server contention and context switching overhead when working with thousands of user connections

Aurora MySQL supports a thread pool approach that addresses these issues. You can characterize the thread pool approach as follows:

• It uses thread multiplexing, where a number of worker threads can switch between user sessions (connections). A worker thread is not fixed or dedicated to a single user session. Whenever a connection is not active (for example, is idle, waiting for user input, waiting for I/O, and so on), the worker thread can switch to another connection and do useful work.

  You can think of worker threads as CPU cores in a multi-core system. Even though you only have a few cores, you can easily run hundreds of programs simultaneously because they're not all active at the same time. This highly efficient approach means that Aurora MySQL can handle thousands of concurrent clients with just a handful of worker threads.

• The thread pool automatically scales itself. The Aurora MySQL database process continuously monitors its thread pool state and launches new workers or destroys existing ones as needed. This is transparent to the user and doesn’t need any manual configuration.

Server thread pooling reduces the server-side cost of maintaining connections.

However, it doesn’t eliminate the cost of setting up these connections in the first place. Opening and closing connections isn't as simple as sending a single TCP packet. For busy workloads with short-lived connections (for example, key-value or online transaction processing (OLTP)), consider using an application-side connection pool.

The following is a network packet trace for a MySQL connection handshake taking place between a client and a MySQL-compatible server located in the same Availability Zone:

04:23:29.547316 IP client.32918 > server.mysql: tcp 0
04:23:29.547478 IP server.mysql > client.32918: tcp 0
04:23:29.547496 IP client.32918 > server.mysql: tcp 0
04:23:29.547823 IP server.mysql > client.32918: tcp 78
04:23:29.547839 IP client.32918 > server.mysql: tcp 0
04:23:29.547865 IP client.32918 > server.mysql: tcp 191
04:23:29.547993 IP server.mysql > client.32918: tcp 0
04:23:29.548047 IP server.mysql > client.32918: tcp 11
04:23:29.548091 IP client.32918 > server.mysql: tcp 37
04:23:29.548361 IP server.mysql > client.32918: tcp 99
04:23:29.587272 IP client.32918 > server.mysql: tcp 0

This is a packet trace for closing the connection:

04:23:37.117523 IP client.32918 > server.mysql: tcp 13
04:23:37.117818 IP server.mysql > client.32918: tcp 56
04:23:37.117842 IP client.32918 > server.mysql: tcp 0

As you can see, even the simple act of opening and closing a single connection involves an exchange of several network packets. The connection overhead becomes more pronounced when you consider SQL statements issued by drivers as part of connection setup (for example, SET variable_name = value commands used to set session-level configuration). Server-side thread pooling doesn’t eliminate this type of overhead.