Apa penyimpanan sesi paling andal dalam PHP: Memcache, basis data atau file? [Tutup]


10

Apa cara terbaik dan teraman untuk menangani sesi PHP. Apakah cara terbaik untuk menyimpan sesi di:

  1. Basis data (lebih dapat diandalkan, tetapi bottleneck tinggi, kecepatan lambat, tidak bagus untuk situs web penggunaan basis data tinggi)?

  2. Memcache (super cepat, tetapi mendistribusikan lebih banyak masalah keamanan, kemungkinan kehilangan data saat server dimulai ulang dan kemungkinan kehilangan data saat cache penuh)?

  3. File (opsi default, saya kira lambat karena membaca dan menulis dari file I / O, keamanan kurang, dll).

Metode mana yang terbaik? Apa masalah dan hal-hal baik dari masing-masing pendekatan itu?


2
Saya percaya Anda harus menentukan apakah Anda hanya menggunakan satu mesin, atau jika aplikasi didistribusikan, karena akan sangat mempengaruhi jawaban.
Arseni Mourzenko

1
@haylem ini adalah tempat yang paling tepat untuk mengajukan pertanyaan ini, ini bukan pemrograman pertanyaannya masalah pemrograman konseptual,
user1179459

3
Ini benar-benar pertanyaan yang buruk karena 'terbaik' tergantung pada keadaan spesifik Anda. 'Terbaik' untuk Facebook mungkin tidak sama 'terbaik' untuk beranda pribadi Anda.
GrandmasterB

1
@ GrandmasterB saya tahu itu sebabnya saya jelas bertanya, "Apa masalah dan hal-hal baik dari masing-masing pendekatan itu?" untuk mencari tahu mana yang terbaik untuk saya.
user1179459

Jawaban:


6

Yang terbaik adalah menyimpan di Memcached karena kami dapat dengan mudah menyelesaikan masalah lain (ukuran cache, keamanan, dll.)

Facebook adalah konsumen memcached # 1 . Harap baca jika tertarik: http://www.facebook.com/note.php?note_id=39391378919

Bagaimana cara mengatasi masalah lainnya?


4

Untuk sebagian besar aplikasi sehari-hari, menyimpan sesi dalam basis data baik-baik saja. Volume & tingkat konkurensi yang dapat ditangani oleh server sql akan lebih dari cukup. Kuncinya adalah untuk menjaga setiap entri dalam ukuran kecil dan membersihkan baris yang tidak dibutuhkan dengan teratur. Dan pengindeksan yang tepat, tentu saja.

Sistem file - Saya belum pernah melihat perlunya melakukan itu. Saya lebih suka kesederhanaan mengelola baris dalam tabel daripada ribuan file kecil. Ditambah lagi, Anda tidak dapat meminta seluruh file jika Anda ingin menggali statistik sesi.

Perlu diingat, dengan PHP, mudah untuk menukar penangan sesi. Jadi Anda bisa mulai dengan satu format penyimpanan, dan bermigrasi ke format lain tanpa terlalu banyak kesulitan.


4

Bagaimana dengan menggunakan mesin penyimpanan MEMORY di MySQL?

Ini tidak secepat Memcache tetapi memiliki keuntungan bahwa Anda dapat menggunakan SQL biasa, dan Anda juga dapat menggunakan mesin penyimpanan normal ketika tidak akan diperlukan dan beralih ke MEMORY ketika jumlah pengguna / permintaan bertambah.

Saya menggunakannya untuk menyimpan data statistik dalam jumlah besar di aplikasi web yang sering berubah sehingga tidak digunakan untuk menangani sesi, tetapi saya pikir itu harus cocok untuk tujuan ini.


3

Posting blog ini menunjukkan hasil perbandingan kinerja mesin penyimpanan sesi yang berbeda dengan Magento dan mereka tampaknya menyimpulkan bahwa sekitar 75 pengguna bersamaan tidak benar-benar ada perbedaan kinerja di antara mereka.

Saya berpikir bahwa pada level ini (mereka memiliki sekitar 5 transaksi per detik, yang akan menjadi sekitar 430k hit selama periode 12 jam) overhead dalam segala hal yang lain mendominasi angka kinerja yang Anda lihat sejak file / DB / Memcache / Redis semuanya akan dengan senang hati menangani lalu lintas tanpa berkeringat jika digunakan dengan benar.

Itu meninggalkan faktor-faktor lain seperti skalabilitas, keandalan, dan keamanan.

Pertama-tama saya ingin mengatakan bahwa apa pun yang membahayakan penyimpanan file Anda juga kemungkinan besar akan mengkompromikan hal lain karena penyerang kemudian hanya dapat mengubah kode aplikasi Anda atau paling tidak menemukan kunci dan protokol akses penyimpanan / kredensial bahkan jika mereka hanya baca-saja mengakses. Penyimpanan file akan berfungsi dengan baik untuk situs volume rendah, mudah diatur dan mudah dipikirkan. Seperti yang Anda katakan Anda menekan disk, membaca DB juga akan memukul disk dan jika DB bisa men-cache itu, OS Anda juga kemungkinan telah cache file sesi. Juga, satu file yang dibaca, dan sistem file Anda brilian untuk sampai ke sana jika Anda sudah tahu namanya. Jika Anda menggunakan PHP, tahukah Anda berapa banyak file yang dibaca yang harus dilakukan sistem hanya untuk melayani aplikasi Anda? The downside adalah bahwa Anda bisa '

Memcache relatif cepat dan jika Anda mempertimbangkan solusi kelas Memcache secara lebih luas (Redis, dll) ada beberapa yang bahkan akan menjanjikan kegigihan dalam memori yang dibaca untuk kecepatan sehingga Anda mendapatkan yang terbaik dari kedua dunia. Mereka juga relatif mudah untuk dipikirkan dan nilai kunci dari sesi adalah apa yang telah dirancang untuk dilakukan. Apakah Anda tahu berapa banyak yang harus Anda masukkan ke dalam satu sesi untuk mengisi salah satunya? Bagaimanapun, semua pilihan Anda akan memaksa Anda untuk berkompromi jika Anda mencapai kapasitasnya. Disk diisi dengan file (jumlah dan faktor ukuran di sini), penyimpanan cache mengisi kapasitas dan database memiliki jumlah baris terbatas dan batas kapasitas disk yang sama dengan pendekatan file. Juga, sistem ini hanya didistribusikan jika Anda menjalankannya secara terdistribusi. Sebagian besar bekerja dengan baik dengan pengaturan server tunggal. Jika Anda mendistribusikannya maka Anda mungkin sudah memiliki server web terdistribusi / server database dll sehingga masalah sistem terdistribusi Anda tentu tidak akan muncul dari pilihan penyimpanan sesi Anda. Namun, ketika Anda ingin 10x traffic / kapasitas dll, mendapatkan ada jauh lebih alami dengan ini daripada dengan skema penyimpanan file. Beberapa toko kunci / nilai juga akan memungkinkan Anda untuk melakukan analisis sederhana dari data sesi relatif mudah tetapi kebanyakan tidak akan membuat Anda mendekati apa yang bisa dilakukan SQL.

Saya tidak yakin mengapa Anda mengusulkan bahwa database mungkin lebih dapat diandalkan daripada opsi lain, tetapi saya mendapatkan daya tarik dari database karena aplikasi PHP Anda mungkin sudah memanfaatkannya. Ini berarti Anda tidak menambahkan ketergantungan server lain dan Anda mungkin dapat menggunakan kembali koneksi yang sama yang Anda gunakan untuk mengambil data sesi untuk mendapatkan data pengguna sehingga Anda tidak perlu membuat satu untuk data, satu untuk Memcache, dll. Jika Anda mengindeks tabel dengan baik, itu juga akan melakukan cukup cepat dan memberikan semantik yang cukup sederhana Anda sudah terbiasa dengan menuai sesi lama atau bahkan menganalisis data sesi (saya tidak yakin mengapa Anda ingin dan jika Anda tidak baik, ini mungkin tidak ' sangat penting). Scaling ke skala besar tidak sepele seperti dengan sesuatu seperti Redis,

Saya pikir pilihan ini tidak begitu penting di awal. Setiap pendekatan memiliki tantangan dan kelebihan serta hal-hal yang harus Anda pikirkan. Secara umum, Anda mungkin bisa lolos hanya dengan menggunakan default PHP / kerangka apa pun yang Anda gunakan atau bahkan hanya hal termudah untuk melanjutkan. Jika pilihannya ternyata buruk nantinya, analisis kinerja Anda akan memberi tahu Anda dan Anda akan dipersenjatai dengan data yang Anda butuhkan untuk membuat pilihan yang tepat mengingat sifat spesifik dari lalu lintas yang Anda dapatkan. Di depan, yang dapat Anda miliki adalah spekulasi umum.


0

Semua tergantung dari kebutuhan Anda.

Ada beberapa perbedaan antara file dan penyimpanan basis data. Lihat pertanyaan ini .

Namun, Anda dapat melakukan apa yang dilakukan di Rails 3 secara default, dan hanya menggunakan cookie terenkripsi untuk sesi Anda. Jadi, Anda mengenkripsi semua nilai dengan cara yang hanya Anda yang dapat mendekripsinya nanti (mis. Kunci privat / publik), dan Anda membiarkan klien melakukan keadaan yang menjaga Anda.

Di satu sisi itu membatasi Anda untuk 4Kb, yang sebenarnya biasanya cukup (karena Anda biasanya ingin menyimpan ID, bukan seluruh objek), tetapi manfaat yang sangat bagus yang Anda dapatkan adalah bahwa Anda tidak perlu khawatir tentang pembersihan sesi. Anda menyerahkannya kepada klien, di mana seharusnya .


2
Kecuali Anda memisahkan sumber daya statis untuk berada di luar jalur cookie Anda, cookie adalah pajak tetap yang harus Anda bayar untuk setiap permintaan.
Joeri Sebrechts

jQuery dan Bootstrap sekitar 150kb digabungkan, dan itu tanpa perpustakaan lain. Cookie max adalah 4kb, dan biasanya di bawah 1Kb. Kecuali OP bertanya tentang keadaan ekstrim - siapa yang peduli tentang perpajakan semacam itu?
Yam Marcovic

@YamMarcovic ada beberapa masalah 1) cookie juga akan masuk ke server (pengguna biasanya memiliki unduhan yang lebih cepat kemudian mengunggah) 2) biasanya halaman memiliki 100-an permintaan file statis (gambar, js, css) sehingga dapat mencapai 100kb pada setiap permintaan naik
Miro Svrtan

@MiroSvrtan Jika Anda membuat pengguna Anda mengirim ratusan permintaan per halaman (di mana hal itu pernah terjadi?), Optimisasi jelas bukan masalah bagi Anda.
Yam Marcovic

Saya punya klien yang situsnya membuat ~ 170 permintaan HTTP untuk memuat halaman depan sebelum berkonsultasi dengan saya untuk optimasi kecepatan, jadi itu terjadi, percayalah. Namun, kunci privat / publik adalah konsep dari kriptografi asimetris, yang umumnya tidak diterapkan dalam skenario ini di mana setara dengan sandi simetris, hanya lebih rumit untuk diterapkan. Juga, sebagian besar implementasi penyimpanan sesi bergantung pada beberapa cookie yang dikelola oleh klien, sehingga manfaat yang dijelaskan dalam paragraf terakhir dari jawaban berlaku untuk semuanya.
Juni

0

Untuk situasi khusus saya, saya dapat memberi tahu Anda bahwa sesi dalam basis data adalah penyebab nomor satu server kami hang-up dengan margin yang baik. tabel sesi kami cukup sering rusak sehingga kami harus memangkasnya terlebih dahulu.

memcache terdengar menarik, tetapi kami memiliki terlalu banyak proses yang menghapus seluruh memcache, sehingga sesi pengguna akan terputus terlalu sering. dan sesi yang lebih lama akan dihapus saat memori menjadi penuh ... jadi tidak ada lagi login permanen.

Kami akan segera mencoba sesi berbasis file default.

Jika Anda khawatir tentang keamanan data sesi Anda, maka Anda tidak harus memasukkan data itu di sesi - dan jangan percayai sesi - memvalidasi pengguna pada setiap permintaan.


0

Anda dapat mencoba menyimpan sesi Anda di Redis . Redis cepat seperti Memcached tetapi juga memiliki beberapa opsi data-persistence. Selain itu, berbagai klien PHP didukung.

Selain itu, Anda dapat mencoba layanan pihak ketiga seperti Cloud Memcached yang memiliki kemampuan mesin replikasi dan penyimpanan bawaan

Pengungkapan, Saya adalah Pendiri Bersama dan CTO Data Garantia.


2
Terima kasih atas pengungkapannya! Pastikan Anda berpartisipasi di situs ini di luar pos di mana Anda dapat menyebutkan produk Anda sendiri, kami ingin Anda sebagai orang yang berkontribusi, bukan perusahaan Anda.
Martijn Pieters
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.