요새 이상하게 마우스가 느려지는 현상이 발생하고 있다.

맥북프로를 2010년에 구입해서 지금까지 한번 그런적이 없다가.
사용패턴을 바꿔서 집에 외장모니터에 연결하고 데스크탑 대용으로 쓰기 시작하면서 느끼는 증상

CPU가 버벅 거리는 것도 아닌데, 이따금씩 트랙킹이 느려진다거나 멈춘다거나 하는 증상 때문에,
너무 불편해서 ‘아 Bluetooth 는 아직 주옥 같구나…’ 하며,
그냥 무선으로 쓰는것에 감사하자 하던 터에 검색을 해보니
Bluetooth 와 wifi 가 같은 주파수 대역 2.4GHz 을 사용한다는 것을 배우고,
‘Aㅏ 공유기 또 사야하나…’ 라는 좌절 중. 위의 URL을 찾았으니…

Certain external monitors and LCD displays: Certain displays may emit harmonic interference, especially in the 2.4GHz band between channels 11 and 14. This interference may be at its worst if you have a portable computer with the lid closed and an external monitor connected to it. Try changing your access point to use 5 Ghz or a lower 2.4 GHz channel.

특정 외장 모니터 및 LCD 디스플레이: 특정 디스플레이, 특히 채널 11~14의 2.4GHz 대역에서 고조파 간섭이 생길 수 있습니다. 이러한 간섭은 휴대용 컴퓨터의 뚜껑이 닫혀 있고 외장 모니터가 연결되어 있는 경우 가장 심해질 수 있습니다. 5Ghz 또는 하위 2.4GHz 채널을 사용하도록 액세스 포인트를 변경하십시오.

딱 내가 이런 환경. MBP Lid 를 닫아둔 상태에서 외장 LCD모니터를 쓰고 있고, 2.4GHz 대역의 무선 공유기를 사용하고 있으니 말이다.
그래서 사용하는 wifi 를 2.4 하위 채널을 1번으로 무작정 바꾸고나니, Delay 도 거의 사라지고 버벅임도 없다.

“공유기 안사도 됨”

global 지시자가 없어서, location {} 마저 server {} 마다 집어넣어줘야 하는 불편이 이만저만 아니다.
location {} 을 http{} 에서 global 선언이 안되다 보니, fastcgi 역시 매 vhost 의 server {} 에 넣어줘야하는 답답함.
첫 migration 작업이 진행되고, conf 파일을 작성하면서, conf 가 너무 불필요하게 길어지다 보니,
include 로 공통적인 부분은 아예 빼서 처리하기로 한다.

기본 구성은

/etc/nginx/nginx.conf
/etc/nginx/conf.d/virtual.conf
/etc/nginx/fastcgi_params
이나,

/etc/nginx/global_params
/etc/nginx/global_ssl_params
/etc/nginx/fastcgi_ssl_params (copy from fastcgi_params)

를 따로 준비했다.

/etc/nginx/nginx.conf 는 별도로 특이사항은 없으므로 pass!

/etc/nginx/virtual.conf

# connect to php-fpm (unix socket)
upstream backend {
        server unix:/tmp/php-fpm.sock;
}

# non-SSL virtual host (80)
server {
        server_name domain.tld www.domain.tld;
        root /home/user/web_pub;
        include global_params;
        include fastcgi_params;
}

# SSL-enabled virtual host (443)
server {
        server_name domain.tld www.domain.tld;
        root /home/user/web_pub;
        include global_ssl_params;
        include fastcgi_params;
}

/etc/nginx/global_params

listen 80;
index  index.html index.php;
location ~ /\.ht {
        deny all;
}

/etc/nginx/global_ssl_params
global_params 와 동일하나 80 이 443으로 바뀌고 SSL 항목이 추가됨.

listen 443;
index index.html;

ssl on;
ssl_certificate /etc/yourssl.crt;
ssl_certificate_key /etc/yourssl.key;
ssl_session_timeout 5m;
ssl_protocols SSLv2 SSLv3 TLSv1;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
ssl_prefer_server_ciphers on;

location ~ /\.ht {
        deny all;
}

/etc/nginx/fastcgi_params
중간 set,if 는 phpschool에서 송효진님 글 참조.

location ~ \.(php|html)($|/) {
        fastcgi_index   index.php;
        fastcgi_pass    backend;

        fastcgi_param   QUERY_STRING            $query_string;
        fastcgi_param   REQUEST_METHOD          $request_method;
        fastcgi_param   CONTENT_TYPE            $content_type;
        fastcgi_param   CONTENT_LENGTH          $content_length;

        set $fastcgi_script_realname $fastcgi_script_name;

        if ( $fastcgi_script_name ~ ^(.*\.php)(/.*)$ ) {
                set $fastcgi_script_realname $1;
                set $path_info $2;
        }

        if (!-f $document_root$fastcgi_script_realname) {
                return 404;
        }

        fastcgi_param   PATH_INFO               $path_info;
        fastcgi_param   SCRIPT_NAME             $fastcgi_script_realname;
        fastcgi_param   SCRIPT_FILENAME         $document_root$fastcgi_script_realname;
        fastcgi_param   REQUEST_URI             $request_uri;
        fastcgi_param   DOCUMENT_URI            $document_uri;
        fastcgi_param   DOCUMENT_ROOT           $document_root/;
        fastcgi_param   SERVER_PROTOCOL         $server_protocol;

        fastcgi_param   GATEWAY_INTERFACE       CGI/1.1;
        fastcgi_param   SERVER_SOFTWARE         nginx/$nginx_version;

        fastcgi_param   REMOTE_ADDR             $remote_addr;
        fastcgi_param   REMOTE_PORT             $remote_port;
        fastcgi_param   SERVER_ADDR             $server_addr;
        fastcgi_param   SERVER_PORT             $server_port;
        fastcgi_param   SERVER_NAME             $server_name;

        # PHP only, required if PHP was built with --enable-force-cgi-redirect
        fastcgi_param   REDIRECT_STATUS         200;
}

/etc/nginx/fastcgi_ssl_params
fastcgi_params 와 동일하지만, HTTPS on; 이 추가 되어있다. (phpMyAdmin 에서 https 여부 확인 enviroment)

...
        fastcgi_param   SERVER_PORT             $server_port;
        fastcgi_param   SERVER_NAME             $server_name;
        fastcgi_param   HTTPS                   on;
        # PHP only, required if PHP was built with --enable-force-cgi-redirect
        fastcgi_param   REDIRECT_STATUS         200;
}

위와 같이 파일을 분리해서 virtual.conf 작성시,
include 만으로 해당 기능을 사용하고, 정의할 수 있기 때문에 조금 더 간결하게 conf 를 작성하고 관리할 수 있을 것 같다.

이런 링크를 발견.

즉.
http://bystyx.com/test.txt 라는 파일이 있으며,
이 URL을 그대로 실행하면 php 코드가 그대로 노출이 되나,

http://bystyx.com/test.txt/nonexists.php 와 같이,
URL 끝에만 php 를 붙여주면 test.txt 가 php로 실행이 된다.

fastcgi.server 문법에 pcre 가 지원하지 않으므로 $HTTP["url"] 에서 filtering 할 수 있지 않을까 했는데,
$HTTP["url"] 는 physical path 가 아닌, 단순 URI를 이어서, 실제 파일인지는 구분하지 못한다.

결국 php.ini 의 auto_prepend_file 에 SCRIPT_FILENAME 을 체크하는 코드를 삽입해놨는데,
이것도 정석은 아닌듯 하여, 찾아보니…

"check-local" => "enable"

이 구문을 fastcgi.server 에 포함 하면 된다.
좀 아이러니 한건, 구글링해서 나오는 결과에서 대부분 이 항목을 disable 로 둔다는 것이다. (뭐지…)

fastcgi.server 설정 예시

fastcgi.server = ( ".php" => (
"php-tcp" => (
"host" => "127.0.0.1",
"port" => 9000,
"check-local" => "enable",
"broken-scriptfilename" => "enable",
)))

Directory 기반의 .htaccess 를 지원하지 않아 DocumentRoot 기준으로 작성을 해야하므로,
디렉토리명은 각자 설치된 내용에 따라 변경하여 사용한다.

url.rewrite = (
    "^/xe/(layouts|m.layouts)/(.+)/(.+)\.html$" => "xe/index.php",

    "^/xe/(.+)/files/(member_extra_info|attach|cache|faceOff)/(.*)" => "xe/files/$2/$3",
    "^/xe/(.+)/(files|modules|common|widgets|widgetStyle|layouts|m.layouts|addons)/(.*)" => "xe/$2/$3",

    "^(rss|atom)$" => "xe/index.php?module=rss&act=$1",
    "^([a-zA-Z0-9_]+)/(rss|atom|api)$" => "xe/index.php?mid=$1&act=$2",
    "^/xe/([a-zA-Z0-9_]+)/([a-zA-Z0-9_]+)/(rss|atom|api)$" => "xe/index.php?vid=$1&mid=$2&act=$3",

    "^/xe/([0-9]+)/(.+)/trackback$" => "xe/index.php?document_srl=$1&key=$2&act=trackback",
    "^/xe/([a-zA-Z0-9_]+)/([0-9]+)/(.+)/trackback$" => "xe/index.php?vid=$1&document_srl=$2&key=$3&act=trackback",

    "^/xe/admin/?$" => "xe/index.php?module=admin",

    "^/xe/([0-9]+)$" => "xe/index.php?document_srl=$1",

    "^/xe/([a-zA-Z0-9_]+)/?$" => "xe/index.php?mid=$1",
    "^/xe/([a-zA-Z0-9_]+)/([0-9]+)$" => "xe/index.php?mid=$1&document_srl=$2",

    "^/xe/([a-zA-Z0-9_]+)/([a-zA-Z0-9_]+)/?$" => "xe/index.php?vid=$1&mid=$2",
    "^/xe/([a-zA-Z0-9_]+)/([a-zA-Z0-9_]+)/([0-9]+)$" => "xe/index.php?vid=$1&mid=$2&document_srl=$3",

    "^/xe/([a-zA-Z0-9_]+)/entry/(.+)$" => "xe/index.php?mid=$1&entry=$2",
    "^/xe/([a-zA-Z0-9_]+)/([a-zA-Z0-9_]+)/entry/(.+)$" => "xe/index.php?vid=$1&mid=$2&entry=$3"
)

This article will look at installing Nginx on a CentOS Slice using the ‘yum’ package manager.

Yum

Using the inbuilt package manager to install packages is a great idea as it solves dependency issues and you are assured of any security updates if, and when, they occur.

However, one drawback can be that it is rare for a version upgrade to be placed into the repositories. As such, it is possible for a newer version of an application to be released and not be placed into the repository.

EPEL

To install Nginx using yum we will need to include the EPEL (Extra Packages for Enterprise Linux) repository. This repository was developed by the Fedora community to provide extra add-on packages for Fedora-based Redhat Enterprise Linux and it’s other compatible offspring such as CentOS.

One thing to keep in mind when adding extra repositories is that many include newer versions of packages that are readily available through the standard channels. This can cause problems as packages can be automatically upgraded and cease to function as expected.

I want to make it clear that the EPEL repository is purely complimentary and only provides additional packages that are otherwise unavailable through the default repositories.

Versions

Using yum in conjunction with the EPEL repository, CentOS will install Nginx version 0.6.33.

However, at the time of writing, the latest stable version of Nginx is 0.6.34. You can check the latest versions and change logs at the main nginx site.

Which one you choose is, of course, entirely up to you.

If you decide you would rather have a later version of Nginx than the one the EPEL repository provides, then please refer to the sister article (link on the way) which will take you through the process of installing Nginx from source.

Installation and Dependencies

Let’s begin by installing the EPEL repository:

sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5Server/x86_64/epel-release-5-3.noarch.rpm

Installing nginx using Yum is now incredibly simple, thanks to EPEL, as it involves one command:

sudo yum install nginx

As this will be the first package we install using EPEL, we will be asked to import the EPEL gpg-key.

warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 217521f6
Importing GPG key 0x217521F6 "Fedora EPEL <epel@fedoraproject.org>" from /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL
Is this ok [y/N]:

This key is used to sign all packages that are associated with the EPEL repository to verify their validity.

Once the gpg-key has been imported, the installation should proceed as expected.

This will install any dependencies that Nginx requires and actually incorporates the experimental Perl module. You can read more documentation about this feature as well as many others at Nginx’s English Wiki.

Start

One odd thing is that Nginx is not started automatically:

sudo /etc/init.d/nginx start

Done

Navigate

Now simply navigate to your IP address:

http://123.45.67.890

and you will see the following welcome screen:

Init Scripts

As you would imagine when installing an application with the yum package manager, all init scripts have been created.

However, we need to set up Nginx to start automatically if the slice is rebooted:

sudo /sbin/chkconfig nginx on

Controlling nginx is done with these commands:

sudo /etc/init.d/nginx start
...
sudo /etc/init.d/nginx stop
...
sudo /etc/init.d/nginx reload
...
sudo /etc/init.d/nginx restart

You can also check the current status as well as the configuration syntax by using the following commands:

sudo /etc/init.d/nginx status
...
sudo /etc/init.d/nginx configtest

The configtest option is particularly useful for testing your Nginx configuration before actually implementing it with a reload or restart.

That’s it.

Summary

Using the yum package manager along with the EPEL repository makes the installation of Nginx and associated dependencies very simple indeed.

The only thing to consider is the version disparity between the one offered by yum and the one available via source code.

Mark

source : http://articles.slicehost.com/2008/12/17/centos-installing-nginx-via-yum

In short you can get or set SCSI hard disk parameters. If you are using ATA ( IDE ) hard disk use hdparm utility. 

Install sdparm utility

Type the following command at shell prompt:
# apt-get install sdparm
Red Hat / CentOS user can grab sdparm rpm package here.

sdparm examples

To list common mode parameters of a disk, enter:
# sdparm /dev/sda

To list the designators within the device identification VPD page of a disk:
# sdparm --inquiry /dev/sdb

To see all parameters for the caching mode page:
# sdparm --page=ca /dev/sdc

To set the “Writeback Cache Enable” bit in the current values page:
# sdparm --set=WCE /dev/sda

해결방안은 과거 WEFT를 이용하여 웹폰트(EOT)를 만들때 사용된 Subset 에 포함된 내용을 이용하면 용량이 절반이상 줄일 수 있다.
이를 이용하기 위해서는 Cufon Generate 페이지 일부를 수정하여 적용이 가능하다.
첨부된 Subset 의 내용을 입력하기 위해서는 기존 Input 태그에서는 256 글자로 제한되어있으므로, 이를 Textarea 태그로 변경하여 Subset 을 복사, 붙여넣기 하면 된다. 그리고 기본적으로 선택된 Basic 은 Uncheck 해도 무방하다.

* 페이지의 Include the following glyphs (if available) 의 하단에 Also include these single characters 의 <input 을 <textarea 로 변경.

링크 : Subset.txt

Japan – The Strange Country (Japanese ver.) from Kenichi on Vimeo.

mod-proxy-core has 3 different balancers for different needs. Round Robin, Shortest Queue First and CARP.

We can categorize the balancers into two sections:

• load balancing by distribution (RR, SQF)
• load balancing by separation (CARP)

Round Robin

Round Robin (RR) is simple and straight forward.

If you have 3 hosts

• A1
• A2
• A3

the first request goes to A1, the seconds to A2 and the third to A3. The forth request starts at A1 again.

We use a slightly different implementation. Instead of really going from A1 to A2 to A3, we take all active backends and pick one randomly. On average each host gets the same number of requests.

Shortest Queue First

RR has a little problem. If A1 is slower than A2 and A3, the fast backends will get the same number of requests as the A1.

SQF tries to take that into account and take the queue-length as the base for the balancing.

The first request goes to A1 and takes 10s to complete. Meanwhile we get 4 other requests which A2 and A3 execute in 2s.

After two seconds it looks like this:

• A1 needs 8 more seconds [q-len: 1]
• A2 is free [q-len: 0]
• A3 is free [q-len: 0]

Request 3 goes to A2:

• A1 needs 8 more seconds [q-len: 1]
• A2 needs 2 seconds [q-len: 1]
• A3 is free [q-len: 0]

and Request 4 goes to A3:

• A1 needs 8 more seconds [q-len: 1]
• A2 needs 2 seconds [q-len: 1]
• A3 needs 2 seconds [q-len: 1]

If another request comes in now, we put it into the backlog.

Benchmarks

This had to be benchmarked. What a luck that I have enough hardware at home, so we have 4 boxes joining the ring:

• client (.23): a Mac Mini, 1.2GHz, 100Mbit
• proxy (.27): AMD64 3000+, Linux 2.6.x, 1Gbit
• backend-1 (.22): Intel P4 1.2GHz, WinXP 32-bit
• backend-2 (.25): AMD64 X2, 3500+, Win2003 64-bit

The backends are running Apache 2.2.x taken from the MSI, mod_status enabled.

The proxy is lighty 1.5.0-r1435 with mod-proxy-core:

$SERVER["socket"] == ":1445" {
   proxy-core.protocol = "http"
#  proxy-core.balancer = "round-robin"
   proxy-core.balancer = "sqf"
   proxy-core.backends = ( "192.168.178.25:80", "192.168.178.22:8080" )
#  proxy-core.backends = ( "192.168.178.22:8080" )
#  proxy-core.backends = ( "192.168.178.25:80" )
   proxy-core.max-pool-size = 32
}

The backends are serving the 44byte index.html which is in the htdocs/ folder by default.

The client is always running the same command:

$ ab -k -n 100000 -c 16 http://192.168.178.27:1445/

As a first test we only active .25, the dual core box:

Requests per second:    2833.60 [#/sec] (mean)

Only .22 [my 3yr old Centrino notebook] gives:

Requests per second:    1249.45 [#/sec] (mean)

Using RR will balance the request equally over both hosts. We expect at max the double request-rate of the slowest backend.

balancer req/s req .22 req .25 %idle .27
RR       2122  50122   49896   50%
SQF      3213  30970   69048   25%

You see how SQF takes the adjusts to the possibilities of the backend and balances nicely while RR is just doing its thing and results in alot less throughput in the end.

BTW: If keep-alive is disabled, the req/s drop from 3213 to 2678 req/s with SQF and from 2122 to 1835 for RR.

The proxy-server (our lighty) is using its CPU very well and I already found ways to optimize the proxy-code to use less CPU. It won’t affect the performance of this benchmark alot as the backends are at 100% already.