Apache vs Prestasi Nginx: Teknik Pengoptimuman

mata utama

Apache dan Nginx adalah pelayan web yang kuat, tetapi ciri-ciri prestasi mereka berbeza-beza;
Pengoptimuman utama Apache termasuk penalaan modul multi-proses (MPMS), seperti prefork, pekerja, dan acara untuk mengendalikan sambungan dengan lebih cekap, dan melumpuhkan .htaccess di mana mungkin untuk mengurangkan overhead prestasi sistem fail.
Untuk nginx, peningkatan prestasi utama termasuk menetapkan proses pekerja yang betul dan kiraan sambungan, memanfaatkan sambungan menyimpan untuk mengurangkan overhead TCP, dan melaksanakan dasar caching untuk menyampaikan kandungan lebih cepat.
Kedua -dua pelayan boleh dioptimumkan lagi dengan menyesuaikan konfigurasi perkakasan pelayan (seperti menambah RAM dan menggunakan SSD) untuk menyesuaikan diri dengan keperluan proses perkhidmatan web.
Menggunakan Apache dan Nginx dalam persediaan proksi terbalik boleh mengambil kesempatan daripada kedua -dua pelayan, Nginx mengendalikan kandungan statik dan mengimbangi beban, sementara Apache mengendalikan kandungan dinamik.
Pemantauan dan ujian berterusan menggunakan HTOP, perisian ujian beban baru dan spesifik adalah penting untuk mengenal pasti kesesakan dan mengoptimumkan prestasi pelayan dengan berkesan.

Beberapa tahun yang lalu, pelayan Web Yayasan Apache (dirujuk sebagai "Apache") sangat biasa sehingga menjadi sinonim dengan perkataan "Web Server". Daemonnya pada sistem Linux dinamakan

httpd (hanya bermakna proses http ) dan dipasangkan dalam taburan Linux utama.

Ia pada asalnya diterbitkan pada tahun 1995 dan memetik Wikipedia sebagai berkata, "Ia memainkan peranan penting dalam perkembangan awal World Wide Web." Menurut W3Techs, ia masih merupakan perisian pelayan web yang paling biasa digunakan. Walau bagaimanapun, bahagian pasarannya merosot berdasarkan laporan yang menunjukkan beberapa trend sepanjang dekad yang lalu dan perbandingan dengan penyelesaian lain. Netcraft dan Builtwith menyediakan laporan yang sedikit berbeza, tetapi kedua -duanya bersetuju bahawa bahagian pasaran Apache berada pada trend menurun, sementara bahagian pasaran Nginx berkembang.

nginx (disebut

enjin x ) telah dikeluarkan oleh Igor Sysoev pada tahun 2004, dengan matlamatnya yang jelas untuk melepasi Apache. Laman web Nginx mempunyai artikel yang patut dibaca yang membandingkan kedua -dua teknologi ini. Pada mulanya ia digunakan terutamanya sebagai pelengkap kepada Apache, terutamanya untuk menyampaikan fail statik, tetapi ia telah berkembang dengan mantap kerana ia terus berkembang untuk mengendalikan pelbagai tugas pelayan web. Ia biasanya digunakan sebagai proksi terbalik, pengimbang beban, dan cache HTTP. Penyedia streaming CDN dan video menggunakannya untuk membina sistem penyampaian kandungan yang penting untuk prestasi mereka.

Apache telah lama wujud dan mempunyai banyak modul untuk dipilih. Pengurusan pelayan Apache diketahui mesra pengguna. Pemuatan modul dinamik membolehkan modul yang berbeza untuk disusun dan ditambah ke timbunan Apache tanpa mengulang semula binari pelayan utama. Biasanya, modul akan berada di repositori pengedaran Linux, dan selepas ia dipasang, mereka boleh ditambah ke timbunan dengan anggun menggunakan arahan seperti A2Enmod melalui Pengurus Pakej Sistem. Nginx belum melihat fleksibiliti ini lagi. Apabila kita melihat panduan untuk menubuhkan Nginx untuk menyokong HTTP/2, modulnya adalah apa yang perlu dibina oleh Nginx - dikonfigurasi pada masa membina.

Satu lagi ciri yang menyumbang kepada dominasi pasaran Apache ialah fail .htaccess. Ia adalah pembunuh Apache, menjadikannya penyelesaian pilihan untuk persekitaran hosting yang dikongsi, kerana ia membolehkan kawalan konfigurasi pelayan di peringkat direktori. Setiap direktori pada pelayan yang disediakan oleh Apache boleh mempunyai fail .htaccess sendiri.

nginx bukan sahaja tidak mempunyai penyelesaian yang setara, tetapi juga menghalang penggunaan ini disebabkan oleh kesan prestasi.

Saham Pasaran Pengilang Pelayan dari tahun 1995 hingga 2005. Data dari Netcraft

Litespeed atau LSWS adalah pesaing pelayan yang tahap fleksibiliti setanding dengan Apache tanpa mengorbankan prestasi. Ia menyokong gaya Apache .htaccess, mod_security, dan mod_rewrite, dan patut dipertimbangkan untuk berkongsi tetapan. Ia dirancang sebagai pengganti langsung untuk Apache dan boleh digunakan dengan cPanel dan Plesk. Ia telah menyokong HTTP/2 sejak 2015.

Litespeed mempunyai tiga tahap lesen: OpenLitespeed, LSWS Standard, dan LSWS Enterprise. Standard dan Enterprise datang dengan penyelesaian caching pilihan yang menyaingi varnis, lscache, yang dibina ke dalam pelayan itu sendiri dan boleh dikawal menggunakan peraturan menulis semula dalam fail .htaccess (setiap direktori). Ia juga mempunyai beberapa "bateri" pengurangan DDOS yang dibina. Ini digabungkan dengan seni bina yang didorong oleh peristiwa menjadikannya pesaing yang kuat, mensasarkan penyedia hosting yang berfokus pada prestasi, tetapi ia patut ditubuhkan walaupun untuk pelayan atau laman web yang lebih kecil.

Langkah berjaga -jaga perkakasan

Apabila mengoptimumkan sistem, kita tidak dapat mengatasi perhatian terhadap tetapan perkakasan. Tidak kira penyelesaian yang kita pilih untuk persediaan, mempunyai RAM yang cukup penting. Apabila proses pelayan web atau jurubahasa seperti PHP tidak mempunyai RAM yang cukup, mereka mula bertukar, dan bertukar sebenarnya bermakna menggunakan cakera keras untuk menambah memori RAM. Kesan ini adalah untuk meningkatkan latensi setiap kali memori ini diakses. Ini mengingatkan kita tentang ruang kedua - ruang cakera keras. Menggunakan penyimpanan SSD yang cepat adalah satu lagi faktor utama dalam kelajuan laman web. Kami juga perlu memberi perhatian kepada ketersediaan CPU dan jarak fizikal antara pusat data pelayan dan penonton sasaran.

Memiliki pemahaman yang lebih mendalam tentang aspek perkakasan penalaan prestasi, Dropbox mempunyai artikel yang baik.

pemantauan

Cara praktikal untuk memantau prestasi timbunan pelayan semasa secara terperinci ialah HTOP, yang sesuai untuk Linux, Unix, dan MacOS dan memberikan gambaran keseluruhan mengenai proses kami.

Alat pemantauan lain termasuk relik baru (penyelesaian canggih dengan set alat penuh) dan netdata (penyelesaian sumber terbuka yang menyediakan skalabilitas yang sangat baik, metrik halus dan papan pemuka web yang disesuaikan untuk sistem VPS kecil dan pemantauan rangkaian pelayan). Ia boleh menghantar makluman untuk sebarang aplikasi atau proses sistem melalui e -mel, kendur, pushbullet, telegram, twilio, dll.

Monit adalah satu lagi alat sumber terbuka tanpa kepala yang memantau sistem dan boleh dikonfigurasikan untuk memberi amaran kepada kami apabila syarat -syarat tertentu dipenuhi, atau memulakan semula proses tertentu, atau memulakan semula sistem.

Sistem ujian

AB (Apache Benchmark) adalah alat ujian beban mudah dari Yayasan Apache, dan pengepungan adalah satu lagi program ujian beban. Artikel ini menerangkan bagaimana untuk menetapkannya, berikut adalah beberapa petua yang lebih maju mengenai AB, dan pemahaman yang lebih mendalam tentang pengepungan boleh didapati di sini.

Jika anda lebih suka antara muka web, Locust adalah alat berasaskan python yang sangat mudah untuk menguji prestasi laman web.

Setelah memasang Locust, kita perlu membuat locustfile dalam direktori yang mana kita akan melancarkannya:

maka kita hanya memulakannya dari baris arahan:

<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

Amaran tentang alat ujian beban ini: Mereka mempunyai kesan serangan DDoS, jadi disarankan agar anda mengehadkan ujian anda ke laman web anda sendiri.

Laraskan Apache

<code>locust --host=https://my-website.com
</code>

Modul MPM Apache

Apache bermula pada tahun 1995 dan pada awal Internet, apabila cara yang boleh diterima bagi pelayan dijalankan adalah untuk menghasilkan proses baru pada setiap sambungan TCP yang masuk dan membalasnya. Jika lebih banyak sambungan masuk, lebih banyak proses pekerja dibuat untuk mengendalikannya. Kos menghasilkan proses baru adalah sangat tinggi, dan pemaju Apache direka mod

prefork

di mana pra-membuat bilangan proses tertentu. Jurubahasa bahasa dinamik yang tertanam dalam setiap proses (seperti mod_php) masih mahal, dan tetapan lalai Apache menyebabkan pelayan jatuh. Setiap proses hanya boleh memproses satu sambungan masuk.

Model ini dipanggil mpm_prefork_module dalam sistem MPM (modul multi-proses) Apache. Menurut laman web Apache, mod ini memerlukan sedikit konfigurasi, kerana ia dapat mengawal selia, dan yang paling penting, Arahan MaxRequestworkers cukup besar untuk mengendalikan seberapa banyak permintaan serentak seperti yang anda harapkan untuk menerima, tetapi cukup kecil untuk memastikan Semua proses mempunyai RAM fizikal yang cukup

.

Ujian beban belalang kecil yang menunjukkan sejumlah besar proses Apache yang dihasilkan untuk mengendalikan trafik masuk.

kita boleh menambah bahawa corak ini mungkin menjadi sebab utama reputasi terkenal Apache. Ia boleh menjadi sumber yang tidak cekap.

Versi 2.0 Apache membawa dua MPM lain yang cuba menyelesaikan masalah mod Prefork . Mereka adalah modul pekerja atau mpm_worker_module dan modul acara .

Modul pekerja tidak lagi berasaskan proses; Petikan laman web Apache:

Proses kawalan tunggal (proses induk) bertanggungjawab untuk memulakan proses kanak -kanak. Setiap proses kanak -kanak mencipta bilangan benang pelayan tetap berdasarkan nombor yang ditentukan dalam Arahan Threadsperchild, dan benang mendengar yang mendengar sambungan dan lulusnya ke benang pelayan untuk diproses apabila sambungan tiba.

Mod ini menjimatkan lebih banyak sumber.

versi Apache 2.4 membawa kita MPM ketiga - modul acara. Ia berdasarkan kepada MPM pekerja dan menambah benang mendengar berasingan yang menguruskan sambungan Keepalive yang mengantuk selepas permintaan HTTP selesai. Ia adalah mod tak segerak yang tidak menyekat dengan jejak memori yang lebih kecil. Maklumat lanjut mengenai peningkatan versi 2.4 di sini.

Kami memuatkan pemasang wooCommerce ujian dengan kira -kira 1200 catatan pada pelayan maya dan mengujinya pada Apache 2.4 dengan mod prefork lalai dan mod_php.

Pertama, kami mengujinya menggunakan libapache2-mod-php7 dan mmpm_prefork_module pada https://tools.pingdom.com:

Kami kemudian menguji modul MPM acara.

kita perlu menambah multiverse ke /etc/apt/sources.list kami:

<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

Kemudian kami melaksanakan kemas kini sudo apt-get dan pasang libapache2-mod-fastcgi dan php-fpm:

<code>locust --host=https://my-website.com
</code>

Oleh kerana php-fpm adalah perkhidmatan berasingan dari Apache, ia perlu dimulakan semula:

<code>deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu xenial partner</code>

maka kami melumpuhkan modul prefork dan mod acara yang diaktifkan dan proxy_fcgi:

<code>sudo apt-get install libapache2-mod-fastcgi php7.0-fpm
</code>

kami menambah coretan ini ke host maya Apache kami:

<code>sudo service start php7.0-fpm
</code>

Port ini perlu selaras dengan konfigurasi PHP-FPM di /etc/php/7.0/fpm/pool.d/www.conf. Maklumat lanjut mengenai tetapan PHP-FPM ada di sini.

maka kami menyesuaikan konfigurasi mpm_event di /etc/apache2/mods-available/mpm_event.conf, ingat bahawa sumber Mini VPS yang kami miliki untuk ujian ini terhad - jadi kami hanya mengurangkan beberapa nombor lalai. Butiran setiap arahan di laman web Apache, dan petua untuk MPM acara di sini. Ingatlah bahawa pelayan permulaan

akan memakan memori tertentu, tidak kira betapa sibuknya mereka. Arahan MaxRequestworkers menetapkan bilangan permintaan serentak yang dibenarkan: Menetapkan MaxConnectionSperchild ke nilai bukan sifar adalah penting kerana ia menghalang kebocoran memori yang mungkin.

<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

Kemudian kami menggunakan perkhidmatan sudo apache2 mulakan semula untuk memulakan semula pelayan (jika kita menukar beberapa arahan, seperti Threadlimit, kita perlu berhenti secara eksplisit dan memulakan perkhidmatan, menggunakan perkhidmatan sudo apache2 berhenti; Sudo Service Apache2 Start).

Ujian kami di Pingdom kini menunjukkan bahawa masa pemuatan halaman telah dikurangkan dengan lebih daripada separuh:

Petua lain untuk menyesuaikan Apache:

disable.htaccess: HTAccess membolehkan menyediakan konfigurasi khusus untuk setiap direktori dalam direktori akar pelayan tanpa memulakan semula. Oleh itu, meleleh melalui semua direktori untuk mencari fail .htaccess pada setiap permintaan akan mengakibatkan kerugian prestasi.

dipetik dari dokumentasi Apache:

Secara umum, fail .htaccess hanya perlu digunakan jika anda tidak mempunyai kebenaran untuk mengakses fail konfigurasi pelayan utama. ... Secara umumnya, fail .htaccess harus dielakkan sebanyak mungkin. Anda boleh melakukan apa sahaja konfigurasi yang anda fikir anda mahu masukkan dalam fail .htaccess dengan cekap menggunakan bahagian

dalam fail konfigurasi pelayan utama.

Penyelesaiannya adalah untuk melumpuhkannya di /etc/apache2/apache2.conf:

<code>locust --host=https://my-website.com
</code>

Jika kita memerlukannya untuk direktori tertentu, maka kita boleh mengaktifkannya di bahagian

bahagian host maya:

Petua lain termasuk:

<code>deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu xenial partner</code>

Gunakan mod_expires untuk mengawal cache penyemak imbas - dengan menetapkan header tamat tempoh.

• Simpan Hostnamelookups Off - Hostnamelookups Off telah menjadi lalai sejak Apache 1.3, tetapi pastikan ia tetap di luar kerana ia boleh mengakibatkan kerugian prestasi.
• apache2buddy adalah skrip mudah yang boleh kita jalankan dan mendapatkan helah untuk mengubah suai sistem: curl -sl
https://www.php.cn/link/5b3a93d103a6345e5d404c61c5b5081
nginx

nginx adalah pelayan web yang didorong oleh peristiwa dan tidak menyekat. Petikan poster pada berita penggodam:

Proses forking sangat mahal berbanding dengan gelung acara. Pelayan HTTP berasaskan acara akhirnya menang.

Kenyataan ini mencetuskan perdebatan yang agak sengit mengenai berita penggodam, tetapi dalam pengalaman kami, hanya beralih dari mpm_prefork Apache ke nginx biasanya bermaksud menghalang laman web daripada terhempas. Hanya beralih ke Nginx biasanya merupakan penyelesaiannya sendiri.

Penjelasan visual yang lebih komprehensif mengenai seni bina nginx boleh didapati di sini.

Tetapan Nginx

nginx mengesyorkan menetapkan bilangan pekerja kepada bilangan teras PC (seperti yang kita lakukan dengan konfigurasi mpm_event Apache), dengan menetapkan pekerja_processes ke auto di /etc/nginx/nginx.conf (lalai adalah 1).

worker_connections Menetapkan bilangan sambungan yang dapat dikendalikan oleh setiap proses pekerja. Lalai adalah 512, tetapi biasanya boleh ditingkatkan.

Sambungan Keepalive adalah aspek pelayan yang mempengaruhi prestasi, yang biasanya tidak dapat dilihat dalam tanda aras.

mengikut laman web nginx:

HTTP Keepalive Connection adalah ciri prestasi yang diperlukan yang mengurangkan latensi dan mempercepat pemuatan laman web.

Mewujudkan sambungan TCP baru boleh mahal -belum lagi situasi yang melibatkan

https penyulitan. Protokol HTTP/2 mengurangkan ini dengan keupayaan multiplexingnya. Menggunakan semula sambungan yang ada dapat mengurangkan masa permintaan.

MPM_PREFORK APACHE dan MPM_WORKER mempunyai sekatan konvensional, yang berbeza dengan gelung acara Keepalive. Ini ditetapkan sedikit sebanyak dalam modul MPM_EVENT Apache 2.4 dan muncul sebagai satu -satunya mod operasi lalai di Nginx. Pekerja Nginx boleh mengendalikan beribu -ribu sambungan masuk pada masa yang sama, dan jika ia digunakan sebagai proksi terbalik atau pengimbang beban, Nginx menggunakan kolam sambungan Keepalive tempatan tanpa overhead sambungan TCP.

Keepalive_Requests adalah tetapan yang mengawal bilangan permintaan yang dapat dilakukan oleh pelanggan melalui satu sambungan Keepalive. Keepalive_timeout menetapkan masa apabila sambungan keepalive terbiar tetap terbuka.

Keepalive adalah tetapan yang berkaitan dengan sambungan Nginx ke pelayan hulu - apabila ia bertindak sebagai proksi atau pengimbang beban. Ini bermakna bilangan sambungan huluan hulu percuma setiap proses pekerja.

Membolehkan sambungan ke hulu hulu memerlukan arahan ini ke dalam konfigurasi utama nginx:

<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

Sambungan hulu nginx diuruskan oleh ngx_http_upstream_module.

Jika aplikasi front-end kami terus mengundi aplikasi back-end kami untuk kemas kini, meningkatkan Keepalive_Requests dan Keepalive_Timeout akan mengehadkan bilangan sambungan yang perlu dibuat. Arahan Keepalive tidak boleh terlalu besar untuk membolehkan sambungan lain ke pelayan huluan kami.

Pelarasan kepada tetapan ini adalah berdasarkan keadaan tertentu dan perlu diuji. Ini mungkin salah satu sebab mengapa Keepalive tidak mempunyai tetapan lalai.

Menggunakan Soket Unix

Secara lalai, Nginx menggunakan proses PHP yang berasingan untuk mengemukakan permintaan fail PHP. Di sini, ia bertindak sebagai proksi (sama seperti ketika kami menyediakan Apache dengan Php7.0-fpm).

Biasanya, tetapan tuan rumah maya kami menggunakan nginx adalah seperti berikut:

<code>locust --host=https://my-website.com
</code>

Sejak FastCGI dan HTTP adalah protokol yang berbeza, dua baris pertama ke hadapan beberapa parameter dan tajuk ke PHP -FPM, manakala baris ketiga menentukan bagaimana permintaan proksi - melalui soket rangkaian tempatan.

Ini adalah praktikal untuk persediaan multi-server, kerana kami juga boleh menentukan pelayan jauh ke mana permintaan akan menjadi proksi.

Walau bagaimanapun, jika kita menjadi tuan rumah keseluruhan persediaan pada satu sistem, kita harus menggunakan soket UNIX untuk menyambung ke proses PHP yang mendengar:

soket UNIX dianggap mempunyai prestasi yang lebih baik daripada TCP, dan tetapan ini dianggap lebih selamat. Anda boleh mendapatkan lebih banyak maklumat mengenai tetapan ini dalam artikel ini oleh Rackspace.

<code>deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu xenial partner</code>

Petua ini mengenai soket Unix juga berfungsi untuk Apache. Maklumat lanjut ada di sini.

gzip_static: Pandangan umum pada prestasi pelayan web adalah untuk memampatkan sumber statik kami. Ini biasanya bermakna kita akan cuba untuk berkompromi dan cuba memampatkan hanya fail yang melebihi ambang tertentu, sebagai sumber yang dinamik memampatkan pada setiap permintaan boleh mahal. Nginx mempunyai arahan gzip_static yang membolehkan kami menyediakan versi gzip fail (lanjutan .gz), bukannya sumber biasa:

<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

Dengan cara ini, nginx akan cuba menyediakan style.css.gz bukannya gaya.css (dalam kes ini kita perlu mengendalikan gzipping sendiri).

Dengan cara ini, kitaran CPU tidak sia -sia pada mampatan dinamik untuk setiap permintaan.

cache dengan nginx

Cerita tentang Nginx tidak lengkap tanpa menyebut bagaimana kandungan cache. Nginx caching sangat cekap sehingga banyak pentadbir sistem berfikir bahawa lapisan cache HTTP yang berasingan (seperti varnis) tidak masuk akal. "Kesederhanaan adalah ciri." Membolehkan caching Nginx sangat mudah.

<code>locust --host=https://my-website.com
</code>

Ini adalah arahan yang kami letakkan di dalam fail hos maya, yang terletak di luar blok pelayan. Parameter proxy_cache_path boleh menjadi jalan yang kita mahu menyimpan cache. Tahap menentukan berapa banyak tahap direktori Nginx harus menyimpan kandungan cache. Atas sebab prestasi, dua peringkat biasanya OK. Ia boleh memakan masa untuk melintasi direktori. Parameter Keys_Zone adalah nama kawasan memori yang dikongsi untuk menyimpan kunci cache, dan 10m adalah ruang untuk kunci ini dalam ingatan (10MB biasanya cukup; ini bukan ruang untuk kandungan cache sebenar). max_size adalah pilihan, yang menetapkan had atas kandungan cache - di sini ialah 10GB. Jika tidak ditentukan, ia akan mengambil semua ruang yang ada. INACTIVE Menentukan berapa lama kandungan boleh tinggal di cache sebelum diminta dan kemudian dipadam oleh Nginx.

Selepas tetapan, kami akan menambah baris berikut yang mengandungi nama kawasan memori ke pelayan atau blok lokasi:

<code>deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu xenial partner</code>

Tahap Tekanan Tekanan Tambahan Nginx boleh dilaksanakan dengan memberitahu Nginx untuk menyediakan item dari cache apabila ralat berlaku di pelayan sumber, pelayan hulu, atau downtime pelayan:

<code>sudo apt-get install libapache2-mod-fastcgi php7.0-fpm
</code>

Untuk maklumat lanjut mengenai arahan pelayan atau blok lokasi untuk tweak lagi cache Nginx, lihat di sini.

Proxy Cache Arahan digunakan untuk sumber statik, tetapi kami biasanya ingin cache output dinamik aplikasi web kami -sama ada CMS atau sesuatu yang lain. Dalam kes ini, kami akan menggunakan Cache Cache bukannya proksi Cache *:

<code>sudo service start php7.0-fpm
</code>

Baris terakhir di atas akan menetapkan tajuk tindak balas untuk memberitahu kami sama ada kandungan itu diluluskan dari cache atau tidak.

Kemudian, di pelayan atau blok lokasi kami, kami boleh menetapkan beberapa pengecualian cache - contohnya, apabila rentetan pertanyaan wujud dalam url permintaan:

<code>sudo a2dismod php7.0 mpm_prefork
sudo a2enmod mpm_event proxy_fcgi
</code>

Juga, dalam kes PHP, dalam blok .php di pelayan, kami akan menambah sesuatu seperti yang berikut:

<code><filesmatch>
    SetHandler "proxy:fcgi://127.0.0.1:9000/"
</filesmatch></code>

di atas, fastcgi_cache* garis dan fastcgi_no_cache mengawal caching dan pengecualian. Rujukan terperinci kepada semua arahan ini boleh didapati di laman web dokumentasi NGINX.

Untuk mengetahui lebih lanjut, kakitangan Nginx telah menyediakan webinar percuma mengenai topik ini dan terdapat banyak e-buku yang tersedia.

Kesimpulan

kami cuba memperkenalkan beberapa teknologi yang membantu meningkatkan prestasi pelayan web dan teori di belakangnya. Tetapi topik ini tidak lengkap: kami masih tidak meliputi tetapan proksi terbalik atau tetapan multi-server yang terdiri daripada Apache dan Nginx. Hasil terbaik pada kedua -dua pelayan bergantung pada ujian dan menganalisis kes -kes sebenar tertentu. Ini adalah topik yang tidak pernah berakhir.

Soalan Lazim Mengenai Teknologi Pengoptimuman Prestasi Apache dan Nginx

Apakah perbezaan utama antara Apache dan Nginx dari segi prestasi dan pengoptimuman?

Apache dan Nginx adalah kedua -dua pelayan web yang kuat, tetapi terdapat perbezaan yang signifikan dalam keupayaan prestasi dan pengoptimuman. Apache adalah pelayan lama yang menggunakan model yang didorong oleh proses untuk membuat thread baru untuk setiap permintaan. Ini boleh membawa kepada banyak penggunaan memori apabila berurusan dengan pelbagai sambungan serentak. Nginx, sebaliknya, menggunakan seni bina yang didorong oleh peristiwa yang membolehkannya mengendalikan ribuan sambungan serentak, dengan penggunaan memori yang sangat sedikit. Ini menjadikan Nginx lebih cekap dan lebih cepat, terutamanya dalam penghantaran kandungan statik dan senario proksi terbalik.

Bagaimana untuk mengoptimumkan nginx untuk prestasi yang lebih baik?

Terdapat pelbagai cara untuk mengoptimumkan nginx untuk prestasi yang lebih baik. Pertama, anda boleh menyesuaikan proses pekerja dan sambungan pekerja. Proses pekerja hendaklah ditetapkan kepada bilangan CPU atau teras, sementara sambungan pekerja harus ditetapkan ke had fail terbuka maksimum. Kedua, anda boleh mengaktifkan mampatan GZIP untuk mengurangkan saiz data Nginx yang dihantar kepada pelanggan. Ketiga, anda boleh menggunakan cache untuk menyimpan data yang sering diakses dalam ingatan, mengurangkan operasi I/O cakera. Akhirnya, anda boleh menggunakan pengimbangan beban untuk menyebarkan trafik rangkaian di pelbagai pelayan, meningkatkan masa tindak balas dan prestasi keseluruhan.

Bagaimana untuk mengoptimumkan Apache untuk prestasi yang lebih baik?

Apache boleh dioptimumkan dalam pelbagai cara. Pertama, anda boleh menyesuaikan Arahan MaxClients untuk mengawal bilangan maksimum sambungan serentak. Kedua, anda boleh mengaktifkan mod_deflate untuk memampatkan data sebelum menghantarnya kepada pelanggan, dengan itu mengurangkan penggunaan jalur lebar. Ketiga, anda boleh menggunakan mod_cache untuk cache untuk menyimpan data yang sering diakses dalam ingatan, mengurangkan operasi I/O cakera. Akhirnya, anda boleh memuatkan keseimbangan menggunakan mod_proxy_balancer untuk menyebarkan trafik rangkaian merentasi pelbagai pelayan, meningkatkan masa tindak balas dan prestasi keseluruhan.

Bolehkah saya menggunakan Apache dan Nginx pada masa yang sama?

Ya, anda boleh menggunakan kedua -dua Apache dan Nginx dalam tetapan proksi terbalik anda. Dalam konfigurasi ini, Nginx bertindak sebagai pelayan front-end yang mengendalikan permintaan klien, dan Apache bertindak sebagai pelayan back-end yang mengendalikan permintaan ini. Persediaan ini menggabungkan kelebihan kedua -dua pelayan, Nginx dengan cekap mengendalikan kandungan statik, sementara Apache menyediakan pemprosesan kandungan dinamik.

Bagaimanakah nginx mengendalikan kandungan statik dan dinamik dengan cara yang berbeza?

nginx cemerlang dalam menyediakan kandungan statik kerana seni bina yang didorong oleh peristiwa, yang membolehkannya mengendalikan ribuan sambungan serentak secara serentak dengan penggunaan memori yang minimum. Untuk kandungan dinamik, NGINX boleh lulus permintaan ke pelayan aplikasi (seperti PHP-FPM) atau proksi mereka ke pelayan Apache. Walau bagaimanapun, Nginx tidak mengendalikan kandungan dinamik tempatan seperti Apache menggunakan modul Mod_PHPnya.

Bagaimanakah Apache mengendalikan kandungan statik dan dinamik dengan cara yang berbeza?

Apache boleh memberikan kandungan statik dan dinamik. Untuk kandungan statik, Apache menggunakan modul terasnya. Untuk kandungan dinamik, Apache menggunakan modul tambahan seperti mod_php untuk memproses skrip PHP. Walau bagaimanapun, model yang didorong oleh proses Apache boleh membawa kepada banyak penggunaan memori apabila berurusan dengan pelbagai sambungan serentak, menjadikannya kurang cekap daripada Nginx dari segi penghantaran kandungan statik.

Apakah kesan pengoptimuman pelayan terhadap prestasi laman web?

Pengoptimuman pelayan dapat meningkatkan prestasi laman web dengan ketara. Ia dapat mengurangkan masa tindak balas pelayan, meningkatkan bilangan sambungan serentak yang dapat dikendalikan oleh pelayan, dan mengurangkan penggunaan jalur lebar. Ini boleh membawa kepada masa beban halaman yang lebih cepat, pengalaman pengguna yang lebih baik dan kedudukan SEO yang lebih baik.

Bagaimana memilih antara Apache dan Nginx?

memilih antara Apache dan Nginx bergantung kepada keperluan khusus anda. Jika anda memerlukan pelayan yang boleh mengendalikan banyak sambungan serentak dengan cekap, atau anda terutamanya melayani kandungan statik, maka Nginx mungkin menjadi pilihan yang lebih baik. Jika anda memerlukan pelayan yang mempunyai sokongan yang kuat untuk pemprosesan kandungan dinamik, atau jika anda bergantung pada fail .htaccess untuk konfigurasi, Apache mungkin lebih sesuai.

Apakah beberapa masalah prestasi biasa dengan Apache dan Nginx?

Isu prestasi biasa dengan Apache termasuk penggunaan memori yang tinggi dan masa tindak balas yang perlahan apabila mengendalikan pelbagai sambungan serentak. Bagi Nginx, masalah biasa termasuk konfigurasi proses dan sambungan pekerja yang tidak betul dan kekurangan keupayaan pemprosesan kandungan dinamik.

Bagaimana untuk memantau prestasi Apache dan Nginx?

Anda boleh menggunakan pelbagai alat untuk memantau prestasi Apache dan Nginx. Untuk Apache, anda boleh menggunakan modul mod_status untuk memberikan maklumat status pelayan. Untuk nginx anda boleh menggunakan modul stub_status. Di samping itu, anda boleh menggunakan alat pemantauan pihak ketiga seperti New Relic, Datadog, atau Nagios untuk mendapatkan metrik dan peringatan prestasi yang lebih terperinci.

Atas ialah kandungan terperinci Apache vs Prestasi Nginx: Teknik Pengoptimuman. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!