Tomcat – Leistungsoptimierung

1. JVM-Optimierung

1.

2. Optimierung der Garbage-Collection-Strategie.

2. Connector-Optimierung von server.xml (Connector ist ein Container im Zusammenhang mit der HTTP-Anforderungsverarbeitung. Die Initialisierungssequenz der drei Container ist: Server->Service->Connector)

(1) Geben Sie die Verwendung des NIO-Modells an, um HTTP-Anfragen zu akzeptieren

(2) Optimierung des HTTP-Connectors, geben Sie die Anzahl der Verarbeitungsthreads an

(3) Thread-Pool

(4) Andere Routinen-Einstellungen

3. Sitzungsablaufzeit festlegen

4. Apr-Plugin zur Verbesserung der Tomcat-Leistung

5. Clustering

6 . Problemlokalisierung

1. JVM-Optimierung

Linux ändert TOMCAT_HOME/bin/catalina.sh, fügt

JAVA_OPTS="-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m -Duser.timezone=Asia/Shanghai"

Windows ändert TOMCAT_HOME/bin /catalina.bat, vorne Fügen Sie

set JAVA_OPTS=-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m

vorne hinzu

1. Speicheroptimierung
Die Speichermoduseinstellung erfolgt einfach in catalina.sh, da die nachfolgenden Startparameter JAVA_OPTS als JVM-Startparameter behandeln.

Die spezifischen Einstellungen sind wie folgt:
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4"

Die Parameter sind wie folgt folgt:
-Xmx3550m: Stellen Sie den maximal verfügbaren Speicher der JVM auf 3550 MB ein. Die maximale Heap-Größe sollte 80 % des verfügbaren physischen Speichers nicht überschreiten
-Xms3550m: Stellen Sie die JVM so ein, dass der Speicher 3550 m beträgt. Dieser Wert kann auf den gleichen Wert wie -Xmx gesetzt werden, um zu vermeiden, dass die JVM den Speicher nach Abschluss jeder Garbage Collection neu zuordnet.
-Xmn2g: Stellen Sie die Größe der jungen Generation auf 2G ein. Die gesamte Heap-Größe = Größe der jungen Generation + Größe der alten Generation + Größe der persistenten Generation. Die persistente Generation hat im Allgemeinen eine feste Größe von 64 m, sodass durch die Vergrößerung der jungen Generation die Größe der alten Generation verringert wird. Dieser Wert hat großen Einfluss auf die Systemleistung. Sun empfiehlt offiziell eine Konfiguration von 3/8 des gesamten Heaps.
-Xss128k: Legen Sie die Stapelgröße jedes Threads fest. Nach JDK5.0 beträgt die Stapelgröße jedes Threads 1 MB. In der Vergangenheit betrug die Stapelgröße jedes Threads 256 KB. Passen Sie die erforderliche Speichergröße für mehr Anwendungsthreads an. Bei gleichem physischen Speicher kann eine Reduzierung dieses Werts mehr Threads generieren. Das Betriebssystem hat jedoch immer noch eine Begrenzung der Anzahl der Threads in einem Prozess und kann nicht unendlich generiert werden. Der Erfahrungswert liegt bei etwa 3000 bis 5000.
-XX:NewRatio=4: Legen Sie das Verhältnis der jungen Generation (einschließlich Eden und zwei Survivor-Gebiete) zur alten Generation (ohne die persistente Generation) fest. Auf 4 eingestellt, beträgt das Verhältnis der jungen Generation zur alten Generation 1:4 und die junge Generation macht 1/5 des gesamten Stapels aus
-XX:SurvivorRatio=4: Legen Sie das Größenverhältnis des Eden fest Bereich und der Survivor-Bereich in der jungen Generation. Auf 4 eingestellt, beträgt das Verhältnis von zwei Survivor-Bereichen zu einem Eden-Bereich 2:4, und ein Survivor-Bereich macht 1/6 der gesamten jungen Generation aus
-XX:MaxPermSize=16m: Stellen Sie die Größe der persistenten Generation auf ein 16m.
-XX:MaxTenuringThreshold=0: Legen Sie das maximale Alter des Mülls fest. Wenn es auf 0 gesetzt ist, gelangen die Objekte der jungen Generation direkt in die alte Generation, ohne den Survivor-Bereich zu durchlaufen. Bei Anwendungen mit vielen alten Generationen kann die Effizienz verbessert werden. Wenn dieser Wert auf einen größeren Wert festgelegt wird, wird das Objekt der jungen Generation im Survivor-Bereich mehrmals kopiert, was die Überlebenszeit des Objekts in der jungen Generation verlängern und die Möglichkeit einer Wiederverwertung in der jungen Generation erhöhen kann.

2. Optimierung der Garbage-Collection-Strategie
Die Einstellung der Garbage-Collection befindet sich ebenfalls in catalina.sh. Passen Sie die Variable JAVA_OPTS an.
Die spezifischen Einstellungen lauten wie folgt:
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100"
Die spezifische Garbage-Collection-Strategie und die entsprechenden Parameter Die Strategie lautet wie folgt:

Serieller Kollektor (die wichtigste Recyclingmethode vor JDK1.5)
-XX:+UseSerialGC: Richten Sie den seriellen Kollektor ein
Parallelkollektor (Durchsatzpriorität)
Java - Diese Konfiguration gilt nur für die junge Generation. Das heißt, unter der obigen Konfiguration verwendet die junge Generation die gleichzeitige Sammlung, während die alte Generation weiterhin die serielle Sammlung verwendet.
-XX:ParallelGCThreads=20: Konfigurieren Sie die Anzahl der Threads des Parallelkollektors, dh wie viele Threads gleichzeitig die Garbage Collection durchführen können. Dieser Wert wird am besten gleich der Anzahl der Prozessoren konfiguriert.
-XX:+UseParallelOldGC: Konfigurieren Sie die Garbage Collection-Methode der alten Generation für die parallele Sammlung. JDK6.0 unterstützt die parallele Sammlung der alten Generation
-XX:MaxGCPauseMillis=100: Legen Sie die maximale Zeit für die Müllsammlung jeder jungen Generation fest. Wenn diese Zeit nicht eingehalten werden kann, passt die JVM die Größe der jungen Generation automatisch an Wert .
-XX:+UseAdaptiveSizePolicy: Nach dem Festlegen dieser Option wählt der Parallelkollektor automatisch die Bereichsgröße der jungen Generation und das entsprechende Survivor-Bereichsverhältnis aus, um die vom Zielsystem angegebene Mindestantwortzeit oder Erfassungshäufigkeit zu erreichen Für diesen Wert parallel verwenden. Der Kollektor ist immer geöffnet.

Gleichzeitiger Collector (Antwortzeitpriorität)
Beispiel: java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC
-XX:+UseConcMarkSweepGC: Legen Sie die alte Generation für die gleichzeitige Sammlung fest. Nachdem dies im Test konfiguriert wurde, schlug die Konfiguration von -XX:NewRatio=4 aus unbekannten Gründen fehl. Daher ist es derzeit am besten, die Einstellung -Xmn für die Größe der jungen Generation zu verwenden.
-XX:+UseParNewGC: Stellen Sie die junge Generation auf parallele Sammlung ein. Kann gleichzeitig mit der CMS-Sammlung verwendet werden. Für JDK5.0 und höher legt die JVM ihn entsprechend der Systemkonfiguration selbst fest, sodass dieser Wert nicht festgelegt werden muss.
-XX:CMSFullGCsBeforeCompaction: Da der gleichzeitige Collector den Speicherplatz nicht komprimiert und organisiert, wird nach einer gewissen Zeit eine „Fragmentierung“ generiert, was die Betriebseffizienz verringert. Dieser Wert legt fest, wie oft der GC ausgeführt wird, um den Speicherplatz zu komprimieren und zu organisieren.
-XX:+UseCMSCompactAtFullCollection: Komprimierung der alten Generation einschalten. Es kann die Leistung beeinträchtigen, aber es kann die Fragmentierung beseitigen


3 Zusammenfassung
Sie müssen einige Kompromisse bei den Speichereinstellungen eingehen 1) Je größer der Speicher, desto Unter normalen Umständen ist die Verarbeitungseffizienz umso besser, aber gleichzeitig dauert die Speicherbereinigung umso länger, und die Verarbeitungseffizienz wird in diesem Zeitraum zwangsläufig beeinträchtigt.
2)在大多数的网络文章中都推荐 Xmx和Xms设置为一致，说是避免频繁的回收，这个在测试的时候没有看到明显的效果，内存的占用情况基本都是锯齿状的效果，所以这个还要根据实际情况来定。

 

二、Server.xml的Connection优化

提高Tomcat的并发能力一些方法

1、Apache + Tomcat 结合起来用Apache 负责静态页面，Tomcat负责动态页面，同时减少connectionTimeout的时间，以应对并发量大线程回收来不及的情况。
2、压力过大的问题，可以做负载均衡，一个TOMCAT无论如何也不可能担当如此多的线程负载，而且JVM过大，其内存管理成本将显著加大。2G的内存，做3-4个TOMCAT实例（512RAM*4），更为科学合理。
3、数据库连接池，不少人，都推荐使用C3P0，能提高访问数据库的并发性能好几倍。（有博文称使用tomcat自带的jdbc-pool更好，还没试过）
4、采用Tomcat集群可以最大程度的发挥服务器的性能，可以在配置较高的服务器上部署多个Tomcat，也可以在多台服务器上分别部署 Tomcat，Apache和Tomcat整合的方式还是JK方式。经过验证，系统对大用户量使用的响应方面，Apache+3Tomccat集群> Apache+2Tomcat集群> Apache集成Tomcat >单个Tomcat。并且采用Apache+多Tomcat集群的部署方式时，如果一个Tomcat出现宕机，系统可以继续使用，所以在硬件系统性能足够优越的情况下，需要尽量发挥软件的性能，可以采用增加Tomcat集群的方式。
5. 打开KeepAlive支持
KeepAlive on, KeepAliveTimeout 15 MaxKeepAliveRequests 1000
根据实际经验，通过Apache和Tomcat集群的方式提高系统性能的效果十分明显，这种方式可以最大化的利用硬件资源，通过多个Tomcat的处理来分担单Tomcat时的压力。
web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。

1.指定使用NIO模型来接受HTTP请求 
protocol="org.apache.coyote.http11.Http11NioProtocol" 指定使用NIO模型来接受HTTP请求。默认是BlockingIO，配置为protocol="HTTP/1.1" 
acceptorThreadCount="2" 使用NIO模型时接收线程的数目 

2、指定处理线程数目 

<Connector port="80" protocol="HTTP/1.1" maxThreads="600" minSpareThreads="100" maxSpareThreads="500" acceptCount="700"
connectionTimeout="20000" redirectPort="8443" />

maxThreads="600"       ///最大线程数
minSpareThreads="100"///初始化时创建的线程数
maxSpareThreads="500"///一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。
acceptCount="700"//指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理

这里是http connector的优化，如果使用apache和tomcat做集群的负载均衡，并且使用ajp协议做apache和tomcat的协议转发，那么还需要优化ajp connector。

<Connector port="8009" protocol="AJP/1.3" maxThreads="600" minSpareThreads="100" maxSpareThreads="500" acceptCount="700"
connectionTimeout="20000" redirectPort="8443" />

 3、线程池

由于tomcat有多个connector，所以tomcat线程的配置，又支持多个connector共享一个线程池。

首先。打开/conf/server.xml，增加

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="500" minSpareThreads="20" maxIdleTime="60000" />

最大线程500（一般服务器足以），最小空闲线程数20，线程最大空闲时间60秒。

然后，修改节点，增加executor属性，executor设置为线程池的名字：

<Connector executor="tomcatThreadPool" port="80" protocol="HTTP/1.1"  connectionTimeout="60000" keepAliveTimeout="15000" maxKeepAliveRequests="1"  redirectPort="443" />

可以多个connector公用1个线程池，所以ajp connector也同样可以设置使用tomcatThreadPool线程池。

 4.其它常用设置 
maxHttpHeaderSize="8192" http请求头信息的最大程度，超过此长度的部分不予处理。一般8K。 
URIEncoding="UTF-8" 指定Tomcat容器的URL编码格式。不要遗漏URIEncoding=”GBK”，能使页面url传递中文参数时保证正确。
disableUploadTimeout="true" 上传时是否使用超时机制 
enableLookups="false"--是否反查域名，默认值为true。为了提高处理能力，应设置为false 
compression="on"   打开压缩功能 。压缩会增加Tomcat负担，最好采用Nginx + Tomcat 或者 Apache + Tomcat 方式，压缩交由Nginx/Apache 去做。
compressionMinSize="10240" 启用压缩的输出内容大小，默认为2KB 
noCompressionUserAgents="gozilla, traviata"   对于以下的浏览器，不启用压缩 
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" 哪些资源类型需要压缩 
5.小结 
关于Tomcat的Nio和ThreadPool，本身的引入就提高了处理的复杂性，所以对于效率的提高有多少，需要实际验证一下。 

三、设置session过期时间

conf\web.xml中通过参数指定：

    <session-config>   
        <session-timeout>180</session-timeout>     
    </session-config> 
单位为分钟。

 

四、Apr插件提高Tomcat性能

  Tomcat可以使用APR来提供超强的可伸缩性和性能，更好地集成本地服务器技术.

  APR(Apache Portable Runtime)是一个高可移植库，它是Apache HTTP Server 2.x的核心。APR有很多用途，包括访问高级IO功能(例如sendfile,epoll和OpenSSL)，OS级别功能(随机数生成，系统状态等等)，本地进程管理(共享内存，NT管道和UNIX sockets)。这些功能可以使Tomcat作为一个通常的前台WEB服务器，能更好地和其它本地web技术集成，总体上让Java更有效率作为一个高性能web服务器平台而不是简单作为后台容器。

  在产品环境中，特别是直接使用Tomcat做WEB服务器的时候，应该使用Tomcat Native来提高其性能  

  要测APR给tomcat带来的好处最好的方法是在慢速网络上（模拟Internet），将Tomcat线程数开到300以上的水平，然后模拟一大堆并发请求。
  如果不配APR，基本上300个线程狠快就会用满，以后的请求就只好等待。但是配上APR之后，并发的线程数量明显下降，从原来的300可能会马上下降到只有几十，新的请求会毫无阻塞的进来。
  在局域网环境测，就算是400个并发，也是一瞬间就处理/传输完毕，但是在真实的Internet环境下，页面处理时间只占0.1%都不到，绝大部分时间都用来页面传输。如果不用APR，一个线程同一时间只能处理一个用户，势必会造成阻塞。所以生产环境下用apr是非常必要的。

(1)安装APR tomcat-nativeapr-1.3.8.tar.gz   安装在/usr/local/apr
    #tar zxvf apr-1.3.8.tar.gz
    #cd apr-1.3.8#./configure;make;make install
    
    apr-util-1.3.9.tar.gz  安装在/usr/local/apr/lib
    #tar zxvf apr-util-1.3.9.tar.gz
    #cd apr-util-1.3.9  
    #./configure --with-apr=/usr/local/apr ----with-java-home=JDK;make;make install
    
    #cd apache-tomcat-6.0.20/bin  
    #tar zxvf tomcat-native.tar.gz  
    #cd tomcat-native/jni/native  
    #./configure --with-apr=/usr/local/apr;make;make install
    
  (2)设置 Tomcat 整合 APR
    修改 tomcat 的启动 shell （startup.sh），在该文件中加入启动参数：
      CATALINA_OPTS="$CATALINA_OPTS -Djava.library.path=/usr/local/apr/lib" 。
 
  (3)判断安装成功:
    如果看到下面的启动日志，表示成功。      2007-4-26 15:34:32 org.apache.coyote.http11.Http11AprProtocol init

5. Cluster-Lösung

Die Verarbeitungsleistung eines einzelnen Tomcat ist begrenzt. Wenn die Parallelität groß ist, müssen mehrere Sätze für den Lastausgleich bereitgestellt werden.

Die wichtigsten Punkte des Clusters sind wie folgt:
1. Einführung in die Ladeseite
Soft Load kann mit Nginx oder Apache durchgeführt werden, hauptsächlich unter Verwendung einer Verteilungsfunktion
Referenz:
(Nginx-Last)
(Apache-Last)

2. Gemeinsame Sitzungsverarbeitung
Die aktuellen Verarbeitungsmethoden sind wie folgt:
1) Verwenden Sie die Tomcat-eigene Sitzungsreplikationsfunktion
Referenz (Sitzungsreplikationskonfiguration)
Der Vorteil der Lösung besteht darin, dass sie einfach zu konfigurieren ist. Der Nachteil besteht darin, dass die Sitzungsreplikationszeit zunimmt wird länger dauern, was sich auf die Effizienz der Antwort auswirkt.
2) Verwenden Sie einen Drittanbieter zum Speichern gemeinsamer Sitzungen.
Derzeit wird memcached zum Verwalten gemeinsamer Sitzungen und memcached-session-manager zum Verwalten von Tomcat-Sitzungen verwendet
Referenz (mit MSM Tomcat-Clustersitzung verwalten)
3). Verwenden Sie die Sticky-Session-Strategie
Für Situationen, in denen die Sitzungsanforderungen nicht zu hoch sind (keine Abrechnung erforderlich, eine erneute Anforderung ist zulässig, wenn sie fehlschlägt usw.). ), kann die Sitzung desselben Benutzers Nginx oder Apache zur Verarbeitung an denselben Tomcat übergeben werden. Dies ist die sogenannte Session-Sticky-Strategie, die derzeit in vielen Anwendungen verwendet wird.
nginx enthält standardmäßig nicht das Sitzungs-Sticky-Modul und muss neu kompiliert werden (ich weiß nicht, wie man unter Windows neu kompiliert)
Der Vorteil ist, dass die Verarbeitungseffizienz viel höher ist, aber der Nachteil ist dass es nicht für Anlässe mit hohen Sitzungsanforderungen geeignet ist

3. Eine Instanz für jeden Standort. Starten Sie mehrere Tomcat.

Verwenden Sie nicht den virtuellen Host von Tomcat, eine Instanz pro Site. Das heißt, starten Sie mehrere Tomcats.

Dies ist auch ein häufiger Fehler bei PHP-Betrieb und -Wartung. Der Ansatz von PHP besteht darin, mehrere virtuelle Hosts unter einem Web zu platzieren, anstatt für jeden Host einen Webserver zu starten. Tomcat ist multithreaded und teilt sich den Speicher. Wenn eine Anwendung auf einem virtuellen Host abstürzt, sind alle Anwendungen betroffen. Obwohl die Verwendung mehrerer Instanzen relativ teuer ist, sorgt sie für Anwendungsisolation und -sicherheit.

4. Zusammenfassung
Die oben genannten Schlüsselpunkte für die Implementierung eines Clusters 1 und 2 können in Kombination verwendet werden~

6 Standort

Das Problem, dass die Verarbeitung durch Tomcat lange dauert, wird hauptsächlich durch die Parallelität zu diesem Zeitpunkt, die Anzahl der Sitzungen, den Speicher und die Speicherwiederverwendung usw. verursacht. Nachdem ein Problem aufgetreten ist, muss es analysiert werden.

1. Informationen zur Anzahl der Tomcat-Sitzungen
Dies kann direkt über die Tomcat-Webverwaltungsoberfläche
oder mit Hilfe des Drittanbieter-Tools Lambda Probe angezeigt werden. it Im Vergleich zur Verwaltung, die mit Tomcat geliefert wird, hat es etwas mehr Funktionen, aber nicht viel

2. Überwachen Sie die Speichernutzung von Tomcat
Verwenden Sie die mit dem gelieferte Jconsole JDK kann klarer sein. Sehen Sie sich die Speichernutzung, den Thread-Status, die Gesamtzahl der aktuell geladenen Klassen usw. an.
Das mit JDK gelieferte jvisualvm kann Plug-Ins (wie GC usw.) herunterladen, um umfangreichere Informationen anzuzeigen. Wenn Sie lokales Tomcat analysieren, können Sie auch Speicherstichproben durchführen und die Nutzung jeder Klasse überprüfen

3. Drucken Sie den Ladestatus von Klassen und den Recyclingstatus von Objekten
Dies Sie können diese Informationen drucken (auf dem Bildschirm (standardmäßig auch in catalina.log) oder in einer Datei), indem Sie die Startparameter der JVM konfigurieren. Die spezifischen Parameter lauten wie folgt:
-XX:+PrintGC: Ausgabeformat: [. GC 118250K-> 113543K(130112K), 0,0094143 Sek.] [Vollständiger GC 121376K->10414K(130112K), 0,0650971 Sek.]
-XX:+PrintGCDetails: Ausgabeformat: [GC [DefNew: 8614K->7 81K (9088 K), 0,0123035 Sek.] 118250 K-> 113543 K (130112 K), 0,0124633 Sek.] [GC [DefNew: 8614 K-> 8614 K (9088 K), 0,0000665 Sek.] 414K (12102 4K), 0,0433488 Sekunden] 121376K-> 10414K(130112K), 0,0436268 Sekunden]
-XX:+PrintGCTimeStamps -XX:+PrintGC: PrintGCTimeStamps können mit den beiden oben genannten gemischt werden, Ausgabeformat: 11,851: [GC 98328K->93620K( 130112K), 0,0082960 Sek. s]
-XX:+PrintGCApplicationConcurrentTime: Druckt die ununterbrochene Ausführungszeit des Programms vor jeder Garbage Collection. Kann mit oben gemischt werden. Ausgabeformat: Anwendungszeit: 0,5291524 Sekunden
-XX:+PrintGCApplicationStoppedTime: Druckt die Zeit, die das Programm während der Speicherbereinigung angehalten hat. Kann mit oben gemischt werden. Ausgabeformat: Gesamtzeit, für die Anwendungsthreads angehalten wurden: 0,0468229 Sekunden
-XX:PrintHeapAtGC: Detaillierte Stapelinformationen vor und nach GC drucken
-Xloggc:filename: In Verbindung mit dem oben Genannten verwenden, um relevante Protokollinformationen aufzuzeichnen Datei zur Analyse

-verbose:class überwacht den Status geladener Klassen
-verbose:gc zeigt Informationen zum Ausgabegerät an, wenn in der virtuellen Maschine Speicherrecycling stattfindet
-verbose:jni gibt die native Methode aus Aufrufe Verwandte Situationen werden im Allgemeinen zur Diagnose von JNI-Aufruffehlermeldungen verwendet

4. JMS-Fernüberwachung hinzufügen
Für Tomcat, das auf anderen Computern im LAN bereitgestellt wird, können Sie den JMX-Überwachungsport öffnen , LAN Andere Maschinen können über diesen Port einige häufig verwendete Parameter anzeigen (einige komplexere Funktionen werden jedoch nicht unterstützt). Sie können auch in den JVM-Startparametern konfiguriert werden:
-Dcom.sun.management .jmxremote.ssl =false -Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=192.168.71.38 Stellen Sie die JVM-JMS-Überwachungs-IP-Adresse auf 127.0.0.1 ein, hauptsächlich um eine falsche Überwachung zu verhindern Diese Intranetadresse
-Dcom.sun.management.jmxremote.port=1090 legt den Port für die JVM-JMS-Überwachung fest.
-Dcom.sun.management.jmxremote.ssl=false legt die JVM-JMS-Überwachung fest und ist nicht praktikabel Verwenden Sie SSL
-Dcom.sun.management.jmxremote.authenticate=false. Das Einrichten der JVM-JMS-Überwachung erfordert keine Authentifizierung

5. Zu den professionellen Analysetools gehören
IBM ISA, B. JProfiler usw., suchen Sie einfach online nach bestimmten Überwachungs- und Analysemethoden.

Das obige ist der detaillierte Inhalt vonTomcat – Leistungsoptimierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!