昨天，我安装了一个优化过的 Nginx 来为一个网站提供服务，它真的很快。今天，我做了一些测试，对配置做了一些额外的更改（只是添加了一个重定向），现在服务器突然需要 7 到 10 秒才能提供页面。一旦收到请求，页面加载速度非常快，但在进入网站和浏览时会出现 10 秒的卡顿。这是我第一次使用 fastcgi 配置 nginx，我真的不知道发生了什么，因为我处于调试模式，我唯一看到的是错误日志中的信息消息，根本没有错误或警报。您在代码中看到的所有重写都是昨天的，所以我想这不是问题所在。您认为我的代码格式错误吗？
我将在这里发布配置并希望有人能给我一些提示...谢谢。
user www-data;
worker_processes 2;
error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
worker_rlimit_nofile 30000;
events {
worker_connections 4096;
}
http {
perl_modules perl;
perl_require JavaScript/Minifier.pm;
perl_require CSS/Minifier.pm;
perl_require JSMinify.pm;
perl_require CSSMinify.pm;
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log logs/access.log main;
gzip_static on;
gzip_http_version 1.1;
gzip_proxied expired no-cache no-store private auth;
gzip_disable "MSIE [1-6]\.";
gzip_vary on;
sendfile on;
tcp_nopush off;
tcp_nodelay on;
#keepalive_timeout 0;
keepalive_timeout 10;
gzip on;
log_request_speed_filter on;
log_request_speed_filter_timeout 3;
server {
listen 80;
server_name mysite.com;
#charset koi8-r;
access_log logs/mysite.access.log;
error_log logs/mysite.error.log debug;
location /nginx_status {
stub_status on;
access_log off;
}
location ~ \.js$ {
perl JSMinify::handler;
}
location ~ \.css$ {
perl CSSMinify::handler;
}
location / {
root /usr/local/nginx/html;
index index.php;
rewrite ^/api/?(.*)$ /webservice/dispatcher.php?url=$1 last;
rewrite ^/([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$1$2$3.jpg last;
rewrite ^/([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$1$2$3$4.jpg last;
rewrite ^/([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$1$2$3$4$5.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$1$2$3$4$5$6.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9$10.jpg last;
rewrite ^/c/([0-9]+)(\-[\.*_a-zA-Z0-9-]*)(-[0-9]+)?/.+\.jpg$ /img/c/$1$2$3.jpg last;
rewrite ^/c/([a-zA-Z-]+)(-[0-9]+)?/.+\.jpg$ /img/c/$1$2.jpg last;
try_files $uri $uri/ /index.php?$args;
index index.html index.htm index.php;
strip on;
}
if ($http_user_agent ~* aesop_com_spiderman|alexibot|backweb|bandit|batchftp|bigfoot|black.hole|blackwidow|blowfish|botalot|buddy|builtbottough|bullseye|cheesebot|cherryicker|chinaclaw|collector| copier|copyrightcheck|cosmos|crescent|curl|custo|da|diibot|disco|dittospyder|dragonfly|drip|easydl|ebingbong|ecatch|eirgrabber) {
rewrite ^/ http://mysite.com/robots.txt;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /usr/local/nginx/html$fastcgi_script_name;
include fastcgi_params;
fastcgi_read_timeout 10;
fastcgi_send_timeout 10;
}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
# server {
# listen 80;
# server_name www.mysite.com;
# rewrite ^ http://www.mysite.com$uri permanent;
# }
# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
# listen 8000;
# listen somename:8080;
# server_name somename alias another.alias;
# location / {
# root html;
# index index.html index.htm;
# }
#}
# HTTPS server
#
#server {
# listen 443;
# server_name localhost;
# ssl on;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_timeout 5m;
# ssl_protocols SSLv2 SSLv3 TLSv1;
# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}
}
答案1
您不应该对微型实例进行任何类型的性能测试，除非您计划在生产中运行微型实例（我不推荐这样做）。
微型实例的 CPU 受限，I/O 性能低下。这两点足以让人避免在生产中使用它们，或者担心解决性能问题。
我的建议是在生产级实例类型上运行一些性能测试（对于流量较小的情况，小型实例是个不错的开始）。这是排除微型实例作为间歇性性能问题的根本原因的最快和最明智的方法。
http://aws.amazon.com/ec2/实例类型/
微型实例 (t1.micro) 提供少量一致的 CPU 资源，并允许您在有额外周期可用时短时间内增加 CPU 容量。它们非常适合吞吐量较低的应用程序和需要定期增加计算周期的网站
微实例
- 613 MiB 内存
- 最多 2 个 EC2 计算单元（用于短周期突发）
- 仅限 EBS 存储
- 32 位或 64 位平台
- I/O 性能：低
- 是否提供 EBS 优化：否
- API 名称：t1.micro