Berapa banyak pilihan per detik yang dapat dijalankan oleh server mysql?

19

Saya sedang menulis rencana bisnis dan saya harus mensimulasikan biaya ketika situs web saya akan mencapai dari 500.000 pengunjung unik.

pengunjung: 500.000
tampilan halaman: 1.500.000
tayangan laman laba-laba: 500.000
total tampilan halaman: 2.000.000

Setiap halaman melakukan 50 pertanyaan + -

pertanyaan per hari: 100 Juta
per jam: 4 Juta
per menit: 70.000
per detik: 1.200
puncak: 3.000

Melakukan perhitungan ini, saya perlu 3.000 pertanyaan kedua ... jenis server apa yang bisa mengatasinya?

Masalahnya adalah: sebenarnya situs saya melakukan 2.000 kunjungan hari, dan memiliki - + 150/200 kueri / detik ... mulai dari titik ini saya akan mengharapkan 50.000 kueri / detik.

Berapa banyak server yang saya butuhkan di cluster atau replikasi mengelola pekerjaan ini?

mysql linux

— Pasang kembali Monica
sumber

5

Situs seperti apa yang dikunjungi 8k + permintaan kunjungan?

— Ignacio Vazquez-Abrams

5

Anda memerlukan tinjauan desain sistem segera.

— Chopper3

1

Tidak ada informasi yang cukup dekat, karena Anda tidak memberi tahu kami apa yang sebenarnya penting - pertanyaan itu sendiri. Juga tidak harus memberi tahu kami tentang mesin yang Anda jalankan. Apakah ini 486? Komputer super terbaru dan terhebat atau sesuatu di antaranya? Semua angka yang Anda daftarkan tidak relevan dengan pertanyaan. Harap berikan informasi RELEVAN.

— John Gardeniers

> Situs seperti apa yang dikunjungi 8k + permintaan kunjungan? saya menerima 2000 pengunjung unik tetapi setiap pengunjung membuka banyak halaman, + saya punya banyak spider di dalamnya. 2000 pengguna unik menghasilkan 6000 ips unik yang membuka lebih dari 120.000 halaman yang dibuka setiap hari. terima kasih

22

Saya dulu bekerja untuk perusahaan e-commerce dengan situs web yang memiliki beberapa juta klik halaman per hari. Kami memiliki DELL PE 1750 tunggal dengan 2 CPU single core dan 2GB RAM, ukuran perkiraan basis data. 4GB. Pada masa puncaknya server ini menangani hingga 50rb + kueri per detik.

Setelah mengatakan ini: database terstruktur dengan baik, semua kueri disetel dengan halus (kami memiliki sesi mingguan menganalisis log kueri lambat dan memperbaiki kueri dan indeks) dan pengaturan server juga disetel dengan baik. Caching jelas merupakan ide yang bagus, tetapi MySQL tetap melakukannya, Anda hanya perlu menganalisis kinerjanya dan kemudian menyelaraskan bagaimana memori Anda digunakan (cache permintaan vs opsi lain).

Dari pengalaman itu saya dapat memberi tahu Anda bahwa dampak tertinggi disebabkan oleh indeks yang hilang, indeks yang salah, dan desain basis data yang buruk (misalnya bidang string panjang sebagai kunci utama dan omong kosong serupa).

— wolfgangsz
sumber

8

Itu semua tergantung pada seberapa kompleks kueri itu, dan berapa banyak memori yang dimiliki server, dan seberapa cepat disk.

Jika kueri sangat sederhana, atau disetel dengan sangat baik maka satu server database besar dapat mengatasinya. Namun jika pertanyaannya sangat kompleks (atau sederhana tetapi tidak disetel dengan benar) maka Anda akan memerlukan beberapa server.

— mrdenny
sumber

Atau beberapa perubahan skema serius dan pengindeksan ulang ...

— Massimo

3

Tuning SELALU lebih disukai daripada menambahkan lebih banyak perangkat keras. Menambahkan lebih banyak perangkat keras hanya menutupi masalah sampai saat masalah itu jauh lebih sulit untuk dipecahkan.

— mrdenny

Terima kasih atas jawabannya, jadi saya pikir 2 server secara paralel + 1 pasif untuk redundansi seharusnya ok, kan? Saya berbicara tentang server 2x quad core dengan 32 g ram dan drive cepat. Apakah saya benar? ingat bahwa saya butuh pertunjukan!

1

semuanya disetel dengan baik dan diindeks, saya punya 1 atau 2 permintaan lambat per minggu (dan lambat-permintaan-waktu hanya 2 detik) pula saya sedang menulis rencana bisnis, dan saya ingin tahu seperti apa jenis pool server dapat kelola 12.000.000 halaman yang dibuka setiap hari dengan 8000 kueri / detik

8000 kueri per detik tidak terlalu banyak. Server 16 core tunggal mungkin akan melakukan trik. 64 Gigs of RAM (atau lebih atau kurang tergantung pada seberapa besar database dan berapa banyak data yang perlu disimpan dalam cache pada satu waktu) harus melakukan trik. DB saya (diberikan SQL Server-nya) adalah 1 TB pada server RAM 16 core 64 Gig dengan 40-50k pengguna memukulnya setiap hari hingga beberapa kali per menit (masing-masing) sepanjang hari.

— mrdenny

3

Ini benar-benar tidak dapat diperkirakan tanpa mengetahui apa pun tentang kueri spesifik yang Anda jalankan, skema database dan ukurannya.

SELECT sederhana pada kolom yang diindeks adalah binatang yang sangat berbeda dari beberapa BERGABUNG berdasarkan yang tidak diindeks ... dan tentu saja banyak yang berubah jika tabel yang terlibat berisi catatan 1K atau 1M.

Juga:

Apa konfigurasi perangkat keras Anda saat ini?
Seberapa besar daya (CPU, RAM, Disk I / O) yang digunakan server Anda di bawah beban saat ini?

— Massimo
sumber

sebenarnya saya punya server dengan 2x quad core dengan ram 8 GB. Saya menggunakan ram penuh dan 100% prosesor (sepertinya saya dapat menggunakan 800%, lihat di sini :) cpu: img834.imageshack.us/img834/3483/downloadv.png ram: img442.imageshack.us/i/ download2p.png disk: img213.imageshack.us/i/download1x.png terima kasih

Berdasarkan grafik tersebut, Anda hanya menggunakan satu (atau paling banyak dua) core CPU Anda; jadi aplikasi Anda jelas tidak terikat CPU ... atau memang demikian, tetapi tidak dapat memanfaatkan beberapa CPU. Juga, semua memori yang digunakan untuk "cache" tidak sepenuhnya diperlukan oleh siapa pun, hanya saja OS mengambil keuntungan darinya karena "itu ada".

— Massimo

bagaimana saya bisa menemukan informasi tentang cara menggunakan semua core cpu? Saya menggunakan lampu ...

Pertama-tama, Anda harus memeriksa apakah Anda tidak menggunakannya karena tidak ada kebutuhan untuk mereka (= beban rendah), karena operasi Anda tidak dapat diparalelkan dengan benar, atau karena MySQL dan / atau Apache Anda tidak dikonfigurasi untuk gunakan itu. Dan, karena kedua program biasanya multithreaded secara default, saya akan melihat ke dalam beban server Anda dan ke dalam pertanyaan SQL Anda ...

— Massimo

3

Seperti yang dikatakan Ignacio, Anda mungkin ingin melihat caching. Dalam cm atau bahkan di depan tumpukan. 50+ pertanyaan untuk setiap (setiap!) Halaman benar-benar banyak.

— Joris
sumber

ya ini adalah situs web yang kompleks, ini adalah komunitas, saya tidak bisa menembolok apa pun, itu berubah setiap detik. saya mencoba untuk me-cache halaman, tetapi cache hitrate hampir 0, karena setiap kali saya cache halaman, itu tidak pernah bisa dibaca lagi, atau itu bisa berubah sebelum dibuka lagi. terima kasih

4

Ada sangat sedikit situs yang tidak bisa dijangkau; jika itu hanya berubah setiap detik Anda masih bisa melakukan cache selama satu detik, seperti 10 tampilan halaman ;-) Sudahkah Anda menganggap tidak melakukan caching halaman sepenuhnya, tetapi lebih pada blok atau nilai tertentu dll? Anda dapat melakukan cache di luar database, pada segmen memori bersama, sistem file, memcached. Juga, biasanya dalam situasi seperti itu ESI bisa berguna

— Joris

0

Menilai dari komentar Anda, faktor terbesar adalah ukuran kumpulan data Anda, atau setidaknya ukuran kumpulan data "panas". 3,000qps atau bahkan 8,000qps pada server 16-inti tidak menjadi masalah sama sekali selama server jarang harus pergi ke disk untuk memenuhi permintaan. Setelah kumpulan data aktif melebihi jumlah memori yang digunakan InnoDB untuk menyimpannya, kinerja Anda akan menurun dengan cepat.

— Elliott
sumber

0

Untuk kumpulan data "panas" besar, mungkin bernilai investasi pada waktunya untuk dikonversi ke skema "data besar", itu adalah untuk apa mereka. Misalnya, jika Anda memiliki sejumlah besar data untuk diambil, tetapi Anda tidak pernah menulis ulang, tetapi hanya menambahkan data baru, lihat Apache Hive. Jelajahi sekitar, mereka biasanya rasa Anda dapat antarmuka cukup mudah untuk kode yang ada, yang juga akan mencegah mulas kehabisan ruang cache.

— BHGalyean
sumber

0

Ada terlalu banyak hal yang dapat mempengaruhi kueri Anda per detik, jangan percaya data saya tanpa menguji diri Anda. Saya memposting hasil tes kecepatan saya di sini untuk membantu seseorang memperkirakan qps dengan basis data dan mesin mysql (2018-09) saat ini. Dalam pengujian saya ukuran data kurang dari memori server (yang secara dramatis mengurangi IO dan meningkatkan banyak kinerja).

Saya menggunakan memori 3.75GB satu cpu, 100GB SSD, server cloud mysql gcp dan mendapatkan:

1 klien, satu sql satu baris dibaca: 799 sql / detik.
50 klien, satu sql satu baris dibaca: 6403 sql / detik.
50 klien, satu sql satu baris tulis: 4341 baris ditulis, qps. 4341 sql / detik.
1 klien, tulis 30k baris per sql: 92109 baris tertulis / s.

— pria perunggu
sumber

tulis hasil tes qps (2018-11) gcp mysql 2cpu memori 7.5GB 150GB ssd serialisasi tulis 10 utas, tulis 30k baris per sql, tabel 7.0566GB, panjang kunci data adalah 45 byte dan panjang nilai 9 byte, dapatkan baris tertulis 154KB per detik, cpu 97,1% tulis qps 1406 / s di gcp console.

— pria perunggu