PHP는 높은 동시성 문제를 해결합니다
- 伊谢尔伦원래의
- 2017-01-24 13:09:5917104검색
우리가 일반적으로 웹 시스템의 처리 속도를 측정하는 지표는 QPS(Query Per Second, 초당 처리되는 요청 수)입니다. 이 지표는 초당 수만 번에 달하는 높은 동시성 시나리오를 해결하는 데 매우 중요합니다. 예를 들어 비즈니스 요청을 처리하는 평균 응답 시간이 100ms라고 가정합니다. 동시에 시스템에 Apache 웹 서버가 20개 있고 MaxClients가 500(Apache 연결 최대 수를 나타냄)으로 구성되어 있다고 가정합니다.
그러면 우리 웹 시스템의 이론적 최고 QPS는 (이상적인 계산 방법):
20*500/0.1 = 100000 (100,000 QPS)
咦? 우리 시스템은 1초에 100,000건의 요청을 처리할 수 있는 매우 강력한 것 같습니다. 5w/s의 플래시 세일은 "종이 호랑이"인 것 같습니다. 물론 실제 상황은 그다지 이상적이지 않습니다. 실제 높은 동시성 시나리오에서는 컴퓨터의 부하가 높으며 이때 평균 응답 시간이 크게 늘어납니다.
일반 p4 서버는 하루 최대 약 100,000개의 IP를 지원할 수 있으며, 방문 횟수가 10W를 초과하는 경우 소프트웨어가 아무리 강력하지 않으면 문제를 해결하기 위해 전용 서버가 필요합니다. 최적화되어도 도움이 되지 않습니다. 서버
속도에 영향을 미치는 주요 요소는 네트워크 - 하드 디스크 읽기 및 쓰기 속도 - 메모리 크기 - CPU 처리 속도입니다.
웹 서버의 경우 Apache가 더 많은 연결 프로세스를 열수록 CPU가 처리해야 하는 컨텍스트 전환이 많아지며, 이는 CPU 소비를 증가시키고 평균 응답 시간의 증가로 직결됩니다. 따라서 위에서 언급한 MaxClient 수는 CPU, 메모리 등 하드웨어 요소를 고려하여 고려해야 합니다. Apache 자체 abench를 통해 테스트하고 적합한 값을 얻을 수 있습니다. 그런 다음 메모리 작업 수준에서 스토리지로 Redis를 선택합니다. 동시성이 높은 상태에서는 스토리지 응답 시간이 중요합니다. 네트워크 대역폭도 한 요인이지만 이러한 요청 패킷은 일반적으로 상대적으로 작으며 요청에 병목 현상이 발생하는 경우가 거의 없습니다. 로드 밸런싱으로 인해 시스템 병목 현상이 발생하는 경우는 거의 없으므로 여기서는 이에 대해 논의하지 않습니다.
그러면 문제는 우리 시스템이 5w/s의 높은 동시성 상태에서 평균 응답 시간이 100ms에서 250ms로 변경된다고 가정할 때입니다(실제 상황은 그 이상).
20 *500/0.25 = 40000(40,000QPS)
따라서 우리 시스템에는 초당 50,000개의 요청에 대해 40,000QPS가 남게 되며 10,000의 차이가 있습니다.
예를 들어 고속도로 교차로에서는 1초에 5대의 차량이 오고 5대의 차량이 지나가며 고속도로 교차로는 정상적으로 작동합니다. 갑자기 이 교차로를 1초에 4대의 차량만 통과할 수 있게 되어 교통 흐름이 여전히 그대로이므로 교통 정체가 발생하게 됩니다. (5레인이 갑자기 4레인으로 변한 느낌)
마찬가지로 어느 순간 20*500개의 연결 프로세스가 풀가동을 하고 있는데 여전히 10,000개의 신규 요청이 있어 연결이 되지 않습니다. 프로세스를 사용할 수 없으며 시스템이 비정상적인 상태에 빠질 것으로 예상됩니다.
실제로 동시성이 높지 않은 일반적인 비즈니스 시나리오에서는 특정 비즈니스 요청 인터페이스에 문제가 있으며 응답 시간이 매우 느립니다. . 전체 웹 요청 응답 시간이 매우 길어서 웹 서버에서 사용 가능한 연결 수가 점차 채워지고 다른 일반적인 비즈니스 요청에는 연결 프로세스를 사용할 수 없습니다.
더 무서운 문제는 사용자의 행동 특성입니다. 시스템을 사용할 수 없을수록 사용자가 클릭하는 빈도가 높아집니다. 이러한 악순환은 결국 "눈사태"로 이어집니다. 정상적으로 작동하는 다른 머신에서는 정상적인 머신도 정지되고, 이로 인해 웹 시스템 전체가 다운되는 악순환이 발생하게 됩니다.
3. 재시작 및 과부하 보호
시스템에 "눈사태"가 발생한 경우 성급하게 서비스를 다시 시작해도 문제가 해결되지 않습니다. 가장 흔한 현상은 시작한 후 바로 끊기는 것입니다. 이때는 수신 계층에서 트래픽을 거부한 후 다시 시작하는 것이 가장 좋습니다. redis/memcache 등의 서비스도 다운된 경우, 재시작 시 '워밍업'에 주의해야 하며, 시간이 오래 걸릴 수 있습니다.
플래시 세일 및 긴급 세일 시나리오에서는 트래픽이 시스템의 준비와 상상을 넘어서는 경우가 많습니다. 이때 과부하 보호가 필요합니다. 전체 시스템 로드 조건이 감지된 경우 요청을 거부하는 것도 보호 조치입니다. 프런트 엔드에서 필터링을 설정하는 것이 가장 간단한 방법이지만 이 접근 방식은 사용자로부터 "비난"을 받는 동작입니다. 더 적절한 것은 CGI 항목 계층에서 과부하 보호를 설정하여 고객의 직접 요청을 신속하게 반환하는 것입니다.
높은 동시성에서 데이터 보안
여러 스레드가 동일한 파일에 쓸 때( 여러 스레드가 동일한 코드 조각을 동시에 실행합니다. 각 실행의 결과가 단일 스레드 실행의 결과와 동일하고 결과도 스레드로부터 안전합니다. MySQL 데이터베이스인 경우 자체 잠금 메커니즘을 사용하여 문제를 해결할 수 있습니다. 그러나 대규모 동시성 시나리오에서는 MySQL이 권장되지 않습니다. 플래시세일과 급세일 시나리오에는 또 다른 문제가 있는데, 바로 '과잉 전송'입니다. 이 부분을 주의 깊게 제어하지 않으면 과도한 전송이 발생하게 됩니다. 또한 일부 전자상거래 회사에서는 구매자가 상품을 성공적으로 구매한 후에도 판매자가 주문이 유효한 것으로 인식하지 못하고 상품 배송을 거부하는 경우가 많다고 들었습니다. 여기서 문제는 반드시 가맹점이 배신적이라는 것이 아니라, 시스템의 기술적 수준에서 과잉 발행의 위험이 발생한다는 점일 수 있습니다.
1. 초과배송 사유
특정 긴급 세일 시나리오에서 총 100개의 제품만 있다고 가정해 보겠습니다. 마지막 순간에 99개의 제품을 소비했고 마지막 제품만 남았습니다. 이때 시스템은 여러 개의 동시 요청을 보냈고, 이러한 요청으로 읽은 상품 잔액은 모두 99개였으며 모두 이 잔액 판단을 통과하여 결국 초과 발행으로 이어졌습니다. (앞서 기사에서 언급한 장면과 동일)
위 사진에서 동시유저 B님도 '구매에 성공'하여 한 분이 더 상품을 획득하실 수 있게 되었습니다. 이 시나리오는 동시성이 높은 상황에서 발생하기가 매우 쉽습니다.
최적화 계획 1: 인벤토리 필드 번호 필드를 unsigned로 설정합니다. 인벤토리가 0이면 필드가 음수일 수 없으므로 false가 반환됩니다
<?php
//优化方案1：将库存字段number字段设为unsigned，当库存为0时，因为字段不能为负数，将会返回false
include('./mysql.php');
$username = 'wang'.rand(0,1000);
//生成唯一订单
function build_order_no(){
return date('ymd').substr(implode(NULL, array_map('ord', str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
}
//记录日志
function insertLog($event,$type=0,$username){
global $conn;
$sql="insert into ih_log(event,type,usernma)
values('$event','$type','$username')";
return mysqli_query($conn,$sql);
}
function insertOrder($order_sn,$user_id,$goods_id,$sku_id,$price,$username,$number)
{
global $conn;
$sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price,username,number)
values('$order_sn','$user_id','$goods_id','$sku_id','$price','$username','$number')";
return mysqli_query($conn,$sql);
}
//模拟下单操作
//库存是否大于0
$sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id' ";
$rs=mysqli_query($conn,$sql);
$row = $rs->fetch_assoc();
if($row['number']>0){//高并发下会导致超卖
if($row['number']<$number){
return insertLog('库存不够',3,$username);
}
$order_sn=build_order_no();
//库存减少
$sql="update ih_store set number=number-{$number} where sku_id='$sku_id' and number>0";
$store_rs=mysqli_query($conn,$sql);
if($store_rs){
//生成订单
insertOrder($order_sn,$user_id,$goods_id,$sku_id,$price,$username,$number);
insertLog('库存减少成功',1,$username);
}else{
insertLog('库存减少失败',2,$username);
}
}else{
insertLog('库存不够',3,$username);
}
?>2.
스레드 안전성을 해결하기 위한 많은 아이디어가 있는데, "비관적 잠금" 방향에서 논의를 시작할 수 있습니다.
비관적 잠금, 즉 데이터 수정 시 잠금 상태를 채택하여 외부 요청에서 수정 사항을 제외합니다. 잠긴 상태가 발생하면 기다려야 합니다.
위의 솔루션으로 스레드 안전성 문제가 해결되었지만 우리의 시나리오는 "높은 동시성"이라는 점을 잊지 마세요. 즉, 그러한 수정 요청이 많이 있을 것이며 각 요청은 "잠금"을 기다려야 합니다. 일부 스레드는 이 "잠금"을 잡을 기회가 전혀 없을 수 있으며 그러한 요청은 거기에서 종료됩니다. 동시에 이러한 요청이 많아지면 시스템의 평균 응답 시간이 즉시 증가하게 되며 결과적으로 사용 가능한 연결 수가 소진되고 시스템이 예외에 빠지게 됩니다.
최적화 계획 2: MySQL 트랜잭션을 사용하여 작업 행 잠금
<?php
//优化方案2：使用MySQL的事务，锁住操作的行
include('./mysql.php');
//生成唯一订单号
function build_order_no(){
return date('ymd').substr(implode(NULL, array_map('ord', str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
}
//记录日志
function insertLog($event,$type=0){
global $conn;
$sql="insert into ih_log(event,type)
values('$event','$type')";
mysqli_query($conn,$sql);
}
//模拟下单操作
//库存是否大于0
mysqli_query($conn,"BEGIN"); //开始事务
$sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id' FOR UPDATE";//此时这条记录被锁住,其它事务必须等待此次事务提交后才能执行
$rs=mysqli_query($conn,$sql);
$row=$rs->fetch_assoc();
if($row['number']>0){
//生成订单
$order_sn=build_order_no();
$sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price)
values('$order_sn','$user_id','$goods_id','$sku_id','$price')";
$order_rs=mysqli_query($conn,$sql);
//库存减少
$sql="update ih_store set number=number-{$number} where sku_id='$sku_id'";
$store_rs=mysqli_query($conn,$sql);
if($store_rs){
echo '库存减少成功';
insertLog('库存减少成功');
mysqli_query($conn,"COMMIT");//事务提交即解锁
}else{
echo '库存减少失败';
insertLog('库存减少失败');
}
}else{
echo '库存不够';
insertLog('库存不够');
mysqli_query($conn,"ROLLBACK");
}
?>3.FIFO 대기열 아이디어
그렇다면 위의 시나리오를 약간 수정해 보겠습니다. 요청을 대기열에 넣고 FIFO(First In First Out, First In First Out)를 사용하면 일부 요청이 잠금을 획득하지 못하게 됩니다. 이렇게 보니 멀티스레딩을 강제로 싱글스레딩으로 바꾸는 듯한 느낌이 드시나요?
이제 잠금 문제가 해결되었으며 모든 요청은 "선입 선출" 대기열에서 처리됩니다. 그러면 새로운 문제가 발생합니다. 동시성이 높은 시나리오에서는 요청이 많기 때문에 큐 메모리가 순간적으로 "폭발"될 수 있으며 시스템이 다시 비정상적인 상태에 빠지게 됩니다. 또는 대규모 메모리 대기열을 설계하는 것도 해결책입니다. 그러나 시스템이 대기열에 있는 요청을 처리하는 속도는 대기열로 유입되는 미친 개수와 비교할 수 없습니다. 즉, 대기열에 있는 요청 수가 점점 더 많이 누적되고 결국 웹 시스템의 평균 응답 시간은 여전히 크게 떨어지며 시스템은 여전히 예외 상태에 빠지게 됩니다.
4. 파일 잠금 아이디어
일일 IP가 높지 않거나 동시성 수가 그리 많지 않은 애플리케이션의 경우 일반적으로 고려할 필요가 없습니다! 일반적인 파일 조작 방법에는 전혀 문제가 없습니다. 하지만 동시성이 높으면 파일을 읽고 쓸 때 다음 파일에 대해 여러 프로세스가 작동할 가능성이 높습니다. 이때 파일에 대한 액세스를 독점하지 않으면 데이터 손실이 발생하기 쉽습니다
최적화 계획 4: 비차단 파일 독점 잠금 사용
<?php
//优化方案4：使用非阻塞的文件排他锁
include ('./mysql.php');
//生成唯一订单号
function build_order_no(){
return date('ymd').substr(implode(NULL, array_map('ord', str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
}
//记录日志
function insertLog($event,$type=0){
global $conn;
$sql="insert into ih_log(event,type)
values('$event','$type')";
mysqli_query($conn,$sql);
}
$fp = fopen("lock.txt", "w+");
if(!flock($fp,LOCK_EX | LOCK_NB)){
echo "系统繁忙，请稍后再试";
return;
}
//下单
$sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id'";
$rs = mysqli_query($conn,$sql);
$row = $rs->fetch_assoc();
if($row['number']>0){//库存是否大于0
//模拟下单操作
$order_sn=build_order_no();
$sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price)
values('$order_sn','$user_id','$goods_id','$sku_id','$price')";
$order_rs = mysqli_query($conn,$sql);
//库存减少
$sql="update ih_store set number=number-{$number} where sku_id='$sku_id'";
$store_rs = mysqli_query($conn,$sql);
if($store_rs){
echo '库存减少成功';
insertLog('库存减少成功');
flock($fp,LOCK_UN);//释放锁
}else{
echo '库存减少失败';
insertLog('库存减少失败');
}
}else{
echo '库存不够';
insertLog('库存不够');
}
fclose($fp);
?>5. 낙관적 잠금 아이디어
이번에는 "낙관적 잠금"에 대한 아이디어를 논의할 수 있습니다. 낙관적 잠금은 "비관적 잠금"에 비해 더 완화된 잠금 메커니즘을 채택하며 대부분 버전 업데이트를 사용합니다. 구현에서는 이 데이터에 대한 모든 요청을 수정할 수 있지만 데이터의 버전 번호가 일치하는 경우에만 성공적으로 업데이트할 수 있으며 다른 요청은 실패로 반환됩니다. 이 경우 대기열 문제를 고려할 필요는 없지만 CPU의 계산 오버헤드가 증가합니다. 그러나 전반적으로 이것이 더 나은 솔루션입니다.
Redis의 watch와 같이 "낙관적 잠금" 기능을 지원하는 소프트웨어와 서비스가 많이 있습니다. 이 구현을 통해 우리는 데이터 보안을 보장합니다.
최적화 계획 5: Redis에서 시청
<?php
$redis = new redis();
$result = $redis->connect('127.0.0.1', 6379);
echo $mywatchkey = $redis->get("mywatchkey");
/*
//插入抢购数据
if($mywatchkey>0)
{
$redis->watch("mywatchkey");
//启动一个新的事务。
$redis->multi();
$redis->set("mywatchkey",$mywatchkey-1);
$result = $redis->exec();
if($result) {
$redis->hSet("watchkeylist","user_".mt_rand(1,99999),time());
$watchkeylist = $redis->hGetAll("watchkeylist");
echo "抢购成功！<br/>";
$re = $mywatchkey - 1;
echo "剩余数量：".$re."<br/>";
echo "用户列表：<pre class="brush:php;toolbar:false">";
print_r($watchkeylist);
}else{
echo "手气不好，再抢购！";exit;
}
}else{
// $redis->hSet("watchkeylist","user_".mt_rand(1,99999),"12");
// $watchkeylist = $redis->hGetAll("watchkeylist");
echo "fail！<br/>";
echo ".no result<br/>";
echo "用户列表：<pre class="brush:php;toolbar:false">";
// var_dump($watchkeylist);
}*/
$rob_total = 100; //抢购数量
if($mywatchkey<=$rob_total){
$redis->watch("mywatchkey");
$redis->multi(); //在当前连接上启动一个新的事务。
//插入抢购数据
$redis->set("mywatchkey",$mywatchkey+1);
$rob_result = $redis->exec();
if($rob_result){
$redis->hSet("watchkeylist","user_".mt_rand(1, 9999),$mywatchkey);
$mywatchlist = $redis->hGetAll("watchkeylist");
echo "抢购成功！<br/>";
echo "剩余数量：".($rob_total-$mywatchkey-1)."<br/>";
echo "用户列表：<pre class="brush:php;toolbar:false">";
var_dump($mywatchlist);
}else{
$redis->hSet("watchkeylist","user_".mt_rand(1, 9999),'meiqiangdao');
echo "手气不好，再抢购！";exit;
}
}
?>PHP는 웹사이트 빅데이터, 대규모 트래픽 및 높은 동시성 문제를 해결합니다
첫 번째로 이야기하고 싶은 것은 데이터베이스의 구조가 좋아야 합니다. 쿼리에 *를 사용하지 마세요. 자주 쿼리하는 경우에는 인덱스를 추가하고 그렇지 않은 경우에는 정렬을 사용하세요. 조건이 허락한다면 일반적으로 MySQL 서버는 Linux 운영 체제에 설치하는 것이 가장 좋습니다. Apache 및 nginx의 경우 동시성이 높은 상황에서는 nginx를 사용하는 것이 좋습니다. Ginx는 Apache 서버의 좋은 대안입니다. nginx는 더 적은 메모리를 소비합니다. 공식 테스트에서는 50,000개의 동시 연결을 지원할 수 있으며 실제 프로덕션 환경에서는 동시 연결 수가 20,000~30,000에 달할 수 있습니다. PHP에서 불필요한 모듈을 최대한 닫고 memcached를 사용합니다. Memcached는 데이터베이스를 사용하지 않고 메모리에서 직접 데이터를 전송하는 고성능 분산 메모리 개체 캐싱 시스템입니다. 이를 통해 GZIP 압축을 통해 속도를 최적화할 수 있습니다. 웹 사이트를 압축하고 웹 사이트 콘텐츠를 압축하여 웹 사이트 트래픽을 크게 절약합니다. 둘째, 외부 핫링크를 금지합니다. 외부 웹사이트의 사진이나 파일을 핫링크하는 것은 많은 부하 부담을 가져오는 경우가 많기 때문에 자신의 사진이나 파일을 외부 핫링크하는 것은
엄격하게 제한해야 합니다. 다행히 현재로서는 간단히 참조할 수 있습니다. 핫링크를 제어하기 위해 Apache 자체는구성을 통해 핫링크를 비활성화할 수 있습니다. IIS에는 동일한 기능을 수행할 수 있는 일부 타사 ISAPI도 있습니다.
물론 핫링크를 달성하기 위해 코드를 통해서도 추천을 위조할 수 있지만, 현재 고의로 추천과 핫링크를 위조하는 사람은 많지 않습니다.이를 무시하거나 비기술적인 수단을 사용하여 해결할 수 있습니다. 사진과 같은 워터마크를 추가하세요.
셋째, 대용량 파일의 다운로드를 제어합니다.
대용량 파일을 다운로드하면 트래픽이 많이 소모되고, SCSI가 아닌 하드 드라이브의 경우 대량의 파일을 다운로드하면
이 필요한 경우에는 대용량 파일을 다른 서버에 보관하는 것이 좋습니다.
넷째, 다른 호스트를 사용하여 주요 트래픽을 전환하세요.
파일을 다른 호스트에 배치하고 사용자가 다운로드할 수 있는 다른 이미지를 제공하세요. 예를 들어 RSS 파일이
파일을 다른 호스트에 배치하고 사용자가 다운로드할 수 있는 다른 이미지를 제공합니다. . 예를 들어 RSS 파일이 많은 트래픽을 차지한다고 생각되면 FeedBurner 또는 FeedSky와 같은 서비스를 사용하여 RSS 출력을 다른 호스트에 배치하면 다른 사람의 액세스에 대한 대부분의 트래픽 압력이 집중됩니다. FeedBurner의 호스트와 RSS는 너무 많은 리소스를 차지하지 않습니다.
여섯째, 트래픽 분석 및 통계 소프트웨어를 활용하세요.
높은 동시성 및 고부하 제약: 하드웨어, 배포, 운영 체제, 웹 서버, PHP, MySQL, 테스트
배포: 서버 분리, 데이터베이스 클러스터 및 라이브러리 테이블 해싱, 미러링, 로드 밸런싱
전용 파일 서버/비디오 서버 분할로 경량 버스/대형 버스를 효과적으로 분리합니다.
각 웹 서버는 DEC를 통해 모든 데이터베이스에 연결하고 마스터와 슬레이브로 동시에 분할할 수 있습니다.
데이터베이스 서버 그룹:
데이터베이스 읽기 및 쓰기 압력을 상대적으로 균등하게 유지합니다.
데이터베이스 실제 파일 매핑을 통해 여러 데이터베이스의 데이터 동기화를 달성합니다.
공유 디스크/디스크 어레이
데이터 물리적 파일의 통합 읽기 및 쓰기에 사용됩니다.
대용량 첨부 파일의 보관 창고에 사용됩니다.
균형과 이중화를 통해 전체 시스템의 IO 효율성과 데이터를 보장합니다. 자체 물리 디스크 보안;
프론트 엔드 로드 밸런싱을 통한 웹 압력의 합리적인 분배
가볍고 무거운 데이터 흐름의 합리적인 분배; 파일/비디오 서버와 일반 웹 서버 분리 ;
데이터베이스 서버 그룹을 통해 데이터베이스 IO 압력을 합리적으로 분산;
각 웹 서버는 일반적으로 하나의 데이터베이스 서버에만 연결되며 자동으로 전환될 수 있습니다. 중복 데이터베이스 서버에 대한 DEC의 하트비트 감지를 통해 매우 짧은 시간
디스크 어레이의 도입으로 시스템 IO 효율성이 크게 향상될 뿐만 아니라 데이터 보안도 크게 향상됩니다.
웹 서버:
웹 서버의 리소스 사용량 중 상당 부분은 웹 요청을 처리하는 데서 발생합니다. 이는 Apache에서 발생하는 부담입니다. 연결에 있어서 Nginx는 Apache 서버에 대한 좋은 대안입니다. Nginx("engine x")는 러시아에서 작성된 고성능 HTTP 및 역방향 프록시 서버입니다. 중국에서는 Sina, Sohu Pass, NetEase News, NetEase Blog, Kingsoft Xiaoyao.com, Kingsoft iPowerWord, Xiaonei.com, YUPOO Photo Album, Douban, Xunlei Kankan 등과 같은 많은 웹사이트와 채널이 Nginx 서버를 사용합니다.
Nginx의 장점:
높은 동시 연결 수: 공식 테스트에서는 50,000개의 동시 연결을 지원할 수 있으며 실제 프로덕션 환경에서는 동시 연결 수가 20,000~30,000에 이릅니다.
낮은 메모리 소비: 동시 연결 30,000개 미만, 시작된 10개의 Nginx 프로세스는 150M(15M*10=150M)의 메모리만 소비합니다.
내장 상태 확인 기능: Nginx Proxy 백엔드의 웹 서버가 다운되더라도 프런트엔드 액세스에는 영향을 미치지 않습니다.
전략: 기존 Apache와 비교하여 리소스 사용량이 적고 로드 용량이 높은 웹 서버인 Lighttpd와 Nginx를 선택합니다.
Mysql:
MySQL 자체는 강력한 로드 용량을 가지고 있습니다. MySQL 최적화는 궁극적으로 시스템 최적화에 대한 올바른 이해가 필요하기 때문에 매우 복잡한 작업입니다. 데이터베이스 작업에는 많은 수의 단기 쿼리, 읽기 및 쓰기가 포함되며, 프로그램 개발 중에 주의해야 할 인덱싱 및 쿼리 효율성 향상과 같은 소프트웨어 개발 기술 외에도 MySQL 실행 효율성에 가장 큰 영향을 미칩니다. 하드웨어 시설의 관점에서는 검색, 디스크 IO 수준, CPU 주기, 메모리 대역폭에서 비롯됩니다.
서버의 하드웨어 및 소프트웨어 조건에 따라 MySQl 최적화를 수행합니다. MySQL 최적화의 핵심은 시스템 리소스 할당에 있습니다. 이는 MySQL에 제한 없이 더 많은 리소스를 할당한다는 의미는 아닙니다. MySQL 구성 파일에는 가장 주목할만한 매개변수 중 일부가 소개되어 있습니다:
인덱스 버퍼 길이 변경(key_buffer)
테이블 길이 변경(read_buffer_size)
설정 열기 최대 테이블 수(table_cache)
느리고 긴 쿼리에 대한 시간 제한(long_query_time) 설정
조건이 허락한다면 일반적으로 Linux 운영 체제에 MySQL 서버를 설치하는 것이 가장 좋습니다. FreeBSD에는 설치되어 있지 않습니다.
전략: MySQL 최적화를 위해서는 비즈니스 시스템의 데이터베이스 읽기 및 쓰기 특성과 서버 하드웨어 구성을 기반으로 다양한 최적화 계획을 수립해야 하며, 필요에 따라 MySQL의 마스터-슬레이브 구조를 배포할 수 있습니다.
PHP:
1. 가능한 한 적은 수의 모듈을 로드하세요.
2. Windows 플랫폼에 있는 경우 일반적으로 사용하는 것 대신 IIS나 Nginx를 사용해 보세요. Apache 사용
3. 가속기 설치(둘 다 PHP 코드 사전 컴파일된 결과와 데이터베이스 결과를 캐시하여 PHP 코드의 실행 속도를 향상시킵니다.)
eAccelerator, eAccelerator는 최적화된 동적 무료 오픈 소스 PHP 가속기입니다. 콘텐츠 캐싱은 PHP 스크립트의 캐싱 성능을 향상시켜 PHP 스크립트를 컴파일할 때 서버에 발생하는 오버헤드가 거의 완전히 제거됩니다.
Apc: APC(Alternative PHP Cache)는 PHP용 무료 공개 최적화 코드 캐시입니다. 이는 PHP 중간 코드를 캐싱하고 최적화하기 위한 강력한 개방형 무료 프레임워크를 제공하는 데 사용됩니다.
memcache: memcache는 Danga Interactive에서 개발한 고성능 분산 메모리 개체 캐싱 시스템으로, 동적 애플리케이션에서 데이터베이스 부하를 줄이고 액세스 속도를 향상시키는 데 사용됩니다. 주요 메커니즘은 메모리에 통합된 거대한 해시 테이블을 유지하는 것입니다. Memcache를 사용하면 이미지, 비디오, 파일, 데이터베이스 검색 결과 등을 포함한 다양한 형식의 데이터를 저장할 수 있습니다.
Xcache: 중국에서 개발 people Cache,
전략: PHP용 가속기를 설치합니다.
프록시 서버(캐시 서버):
Squid 캐시(Squid라고도 함)는 널리 사용되는 무료 소프트웨어(GNU General Public License) 프록시 서버이자 웹 캐싱 서버입니다. Squid는 웹 서버의 프런트엔드 캐시 서버 역할을 하여 관련 요청을 캐싱하여 웹 서버의 속도를 높이는 것부터 World Wide Web, 도메인 이름 시스템 및 그룹을 위한 기타 웹 검색을 캐싱하는 것까지 광범위한 용도로 사용됩니다. 네트워크 리소스를 공유하고, 트래픽을 필터링하여 네트워크를 지원하고, 프록시 네트워크를 통해 LAN에 연결합니다. Squid는 주로 Unix 계열 시스템에서 실행되도록 설계되었습니다.
전략: Squid 역방향 프록시 서버를 설치하면 서버 효율성이 크게 향상될 수 있습니다.
스트레스 테스트: 스트레스 테스트는 모든 중요한 소프트웨어 테스트 노력의 일부인 기본적인 품질 보증 동작입니다. 스트레스 테스트의 기본 개념은 간단합니다. 일반적인 조건에서 수동 또는 자동 테스트를 실행하는 대신 컴퓨터 수가 적거나 시스템 리소스가 부족한 조건에서 테스트를 실행하는 것입니다. 일반적으로 스트레스 테스트를 받는 리소스에는 내부 메모리, CPU 가용성, 디스크 공간 및 네트워크 대역폭이 포함됩니다. 동시성은 일반적으로 스트레스 테스트에 사용됩니다.
스트레스 테스트 도구: webbench, ApacheBench 등
취약성 테스트: 우리 시스템의 취약점에는 주로 SQL 주입 취약점, xss 크로스 사이트 스크립팅 공격 등이 포함됩니다. 보안에는 운영 체제 취약점, mysql, apache 등의 취약점과 같은 시스템 소프트웨어도 포함되며 일반적으로 업그레이드를 통해 해결할 수 있습니다.
취약성 테스트 도구: Acunetix Web Vulnerability Scanner
관련 콘텐츠를 찾을 수 없습니다.