linux內核調優
打開文件 /etc/sysctl.conf，增加以下設置
#該參數設置系統的TIME_WAIT的數量，如果超過默認值則會被立即清除
net.ipv4.tcp_max_tw_buckets = 20000
#定義了系統中每一個端口最大的監聽隊列的長度，這是個全局的參數
net.core.somaxconn = 65535
#對於還未獲得對方確認的連接請求，可保存在隊列中的最大數目
net.ipv4.tcp_max_syn_backlog = 262144
#在每個網絡接口接收數據包的速率比內核處理這些包的速率快時，允許送到隊列的數據包的最大數目
net.core.netdev_max_backlog = 30000
#能夠更快地回收TIME-WAIT套接字。此選項會導致處於NAT網絡的客戶端超時，建議爲0
net.ipv4.tcp_tw_recycle = 0
#系統所有進程一共可以打開的文件數量
fs.file-max = 6815744
#防火牆跟蹤表的大小。注意：如果防火牆沒開則會提示error: "net.netfilter.nf_conntrack_max" is an unknown key，忽略即可
增加socket緩存區的內存大小
net.ipv4.tcp_mem = 379008 505344 758016
net.ipv4.tcp_wmem = 4096 16384 4194304
net.ipv4.tcp_rmem = 4096 87380 4194304
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_tw_reuse
nginx調優
當我需要進行性能優化時，說明我們服務器無法滿足日益增長的業務。性能優化是一個比較大的課題，需要從以下幾個方面進行探討
- 當前系統結構瓶頸
- 瞭解業務模式
- 性能與安全
1、當前系統結構瓶頸
首先需要了解的是當前系統瓶頸，用的是什麼，跑的是什麼業務。裏面的服務是什麼樣子，每個服務最大支持多少併發。比如針對nginx而言，我們處理靜態資源效率最高的瓶頸是多大？能支持多少qps訪問請求？怎麼得出系統當前的結構瓶頸？
可以通過查看當前cpu負荷，內存使用率，進程使用率來做簡單判斷。還可以通過操作系統的一些工具來判斷當前系統性能瓶頸，如分析對應的日誌，查看請求數量。也可以通過nginx http_stub_status_module模塊來查看對應的連接數，總握手次數，總請求數。也可以對線上進行壓力測試，來了解當前的系統能性能，併發數，做好性能評估。
2、瞭解業務模式
雖然我們是在做性能優化，但還是要熟悉業務，最終目的都是爲業務服務的。我們要了解每一個接口業務類型是什麼樣的業務，比如電子商務搶購模式，這種情況平時流量會很小，但是到了搶購時間，流量一下子就會猛漲。也要了解系統層級結構，每一層在中間層做的是代理還是動靜分離，還是後臺進行直接服務。需要我們對業務接入層和系統層次要有一個梳理
3、性能與安全
性能與安全也是一個需要考慮的因素，往往大家注重性能忽略安全或注重安全又忽略性能。比如說我們在設計防火
牆時，如果規則過於全面肯定會對性能方面有影響。如果對性能過於注重在安全方面肯定會留下很大隱患。所以大
家要評估好兩者的關係，把握好兩者的孰重孰輕，以及整體的相關性。權衡好對應的點。
4、系統與nginx性能優化
大家對相關的系統瓶頸及現狀有了一定的瞭解之後，就可以根據影響性能方面做一個全體的評估和優化。
網絡（網絡流量、是否有丟包，網絡的穩定性都會影響用戶請求）
系統（系統負載、飽和、內存使用率、系統的穩定性、硬件磁盤是否有損壞）
服務（連接優化、內核性能優化、http服務請求優化都可以在nginx中根據業務來進行設置）
程序（接口性能、處理請求速度、每個程序的執行效率）
數據庫、底層服務
文件句柄-用戶局部性修改
如root設置爲65535，其他用戶按個人業務設置
一般的配置文件設置都有自己的模板，再根據業務類型進行調整
大體內容爲：
將進程用戶設爲普通用戶
work線程數=cpu核數，或者設置爲auto
日誌配置爲warn級別等等
-
日誌級別共6種（OFF、FATAL、ERROR、WARN、INFO、DEBUG、TRACE、 ALL）
ALL 最低等級的，用於打開所有日誌記錄。 TRACE designates finer-grained informational events than the DEBUG.Since:1.2.12，很低的日誌級別，一般不會使用。 DEBUG 指出細粒度信息事件對調試應用程序是非常有幫助的，主要用於開發過程中打印一些運行信息。 INFO 消息在粗粒度級別上突出強調應用程序的運行過程。打印一些你感興趣的或者重要的信息，這個可以用於生產環境中輸出程序運行的一些重要信息，但是不能濫用，避免打印過多的日誌。 WARN 表明會出現潛在錯誤的情形，有些信息不是錯誤信息，但是也要給程序員的一些提示。 ERROR 指出雖然發生錯誤事件，但仍然不影響系統的繼續運行。打印錯誤和異常信息，如果不想輸出太多的日誌，可以使用這個級別。 FATAL 指出每個嚴重的錯誤事件將會導致應用程序的退出。這個級別比較高了。重大錯誤，這種級別你可以直接停止程序了。 OFF 最高等級的，用於關閉所有日誌記錄。
tomcat調優
一、內存調優
設置 java_OPTS 參數
-server 啓用jdk 的 server 版；
-Xms java虛擬機初始化時的最小內存；
-Xmx java虛擬機可使用的最大內存；
-XX: PermSize 內存永久保留區域
-XX:MaxPermSize 內存最大永久保留區域
一般設置-Xms，-Xmx相等以避免在每次GC後調整堆的大小，因爲默認空餘堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制；空餘堆內存大於70%時，JVM會減少堆直到-Xms的最小限制
優化jvm–優化垃圾回收策略
優化catalina.sh配置文件。在catalina.sh配置文件中添加以下代碼
tomcat分配1G內存模板
JAVA_OPTS="
-Djava.awt.headless=true
-Dfile.encoding=UTF-8
-server
-Xms1024m
-Xmx1024m
-XX:NewSize=512m
-XX:MaxNewSize=512m
-XX:PermSize=512m
-XX:MaxPermSize=512m
每天0點定時重啓tomcat
二、安全優化
1.telnet端口保護 8005—>8000-8999之間其他的端口
2.ajp連接端口保護 8009—>8000-8999之間其他的端口
通過iptables規則限制ajp端口訪問的權限僅爲線上機器，目的防止線下的測試流量被mod_jk轉發至線上tomcat服務器
3.禁用管理端
-
刪除默認的{tomcat安裝目錄}/conf/tomcat-user.xml文件，重啓tomcat後將會自動生成新的文件
-
刪除{tomcat安裝}/webapps下默認的所有目錄和文件
-
將tomcat應用根目錄配置爲tomcat安裝目錄以外的目錄
目的：對於前端web模塊，tomcat管理端屬於tomcat的高危安全隱患，一旦被攻破，黑客通過上傳web shell的方式將會直接取得服務器的控制權，後果極其嚴重
4.降權啓動 -
tomcat啓動用戶權限必須爲非root權限，儘量降低tomcat啓動用戶的目錄訪問權限
-
如需直接對外使用80端口，可通過普通賬號啓動後，配置iptables規則進行轉發
5.文件列表訪問控制：listingfalse
6.版本信息隱藏
7.訪問日誌格式規範 -
開啓tomcat默認訪問日誌中的referer和user-agent記錄，出現安全問題能夠根據日誌進行問題排查
-
異步非阻塞：
每進來一個request，會有一個worker進程去處理。但不是全程的處理，處理到什麼程度呢？處理
到可能發生阻塞的地方，比如向上遊（後端）服務器轉發request，並等待請求返回。那麼，這個處理
的worker不會這麼一直等着，他會在發送完請求後，註冊一個事件：“如果upstream返回了，告訴我一聲，
我再接着幹”。於是他就休息去了。這就是異步。此時，如果再有request 進來，他就可以很快再按這種
方式處理。這就是非阻塞和IO多路複用。而一旦上游服務器返回了，就會觸發這個事件，worker纔會來
接手，這個request纔會接着往下走。這就是異步回調。