마 젠토 페이지 로딩 시간이 너무 오래 걸림


10

magento 웹 사이트가 있습니다. 사용자가 없습니다 (한 번에 최대 2-3).

우리의 서버는 : CPU : 2000MHz RAM : 2048Mb HDD : 50000Mb.

ZendServerCE (apc + memcached + Zend Optimizer + Zend Data Cache)를 설치했습니다. 웹 사이트가 훨씬 최악으로로드 되었기 때문에 memcached를 해제했습니다. 관리 콘솔에서 플랫 유형 구조, 재색 인화 및 캐시 된 데이터를 설정했습니다.

그래서 apc + Zend Optimizer + Zend Data Cache가 있습니다.

  1. 첫 번째 문제는 런타임이 디스패치 작업을 확인하는 방법입니다. start_session () 호출에는 약 500-700ms가 걸립니다. 좋은 결과가 아닌 것 같습니다. 왜 이렇게 오래인지 모르겠어요

  2. 나는 이것을 읽었습니다 : http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_key_buffer_size 내 서버에 대한 최적의 옵션을 알아 냈습니다.

시간당:

Key_read_requests = 8887
Key_reads         = 252
Key_write_request = 187
Key_writes        = 146 

252/8887> 0.01이지만 너무 많지는 않습니다. 내가 얻은 최적의 가치입니다. 다른 결과는> 6에서 시작했습니다.

다음은 my.cnf입니다.

key_buffer              = 48M
myisam_sort_buffer      = 2M
sort_buffer             = 2M
read_buffer_size        = 2M
join_buffer             = 2M
read_rnd_buffer         = 2M
max_allowed_packet      = 128M
thread_stack            = 192K
thread_cache_size       = 16
query_cache_type        = 1
myisam-recover         = BACKUP
max_connections        = 50
table_cache            = 256
#thread_concurrency     = 10
query_cache_limit       = 8M
query_cache_size        = 98M

3. 어떤 이유로 Memcached가 좋지 않았습니다. 나는 그것을 해제했다. 그러나 zend 데이터 캐시 및 zend 최적화 프로그램은 여전히 ​​작동합니다.

4. APC가 올바른 것 같습니다. 컨트롤러 작업을로드하는 데 처음 3-4 초가 걸리고 (확인하기 위해 die ()를 설정했습니다) 처음으로 1-1.3 초가 걸립니다.

도 5. 몇 분 후 mysql을 다시 시작하면 좋은 결과를 얻었습니다. 페이지가 1.5 초에서 2.5 초로로드되었습니다. 그러나 지금 (몇 시간 후) 6-10 초가 걸립니다. 이유를 찾을 수 없습니다.

여기에 잘못된 구성이 있습니까? 내 서버가 magento에 적합하지 않을 수 있습니까?

업데이트 1 : 오늘날 약 600 개의 카테고리와 1000 개의 제품과 다른 웹 스토어의 경우 약 20000 개의 카테고리와 향후 1500-3000 개의 제품이 있습니다.

속성이 많지 않습니다.

업데이트 2 ssh 콘솔이 너무 느리게 작동한다고 들었습니다. 서버를 재부팅하면 빠르게 작동합니다. RAM에 문제가 있음을 의미합니다. 공간이 부족합니다.

아파치없이 초기 상태입니다.

             total       used       free     shared    buffers     cached
Mem:          2048        600       1447

업데이트 3 알았습니다. 이제 0.5-1.5 초 동안로드됩니다.

구성은 다음과 같습니다. mysql

[mysqld]
key_buffer_size         = 256M
tmp_table_size      = 32M
max_heap_table_size     = 32M
myisam_sort_buffer      = 4M
sort_buffer             = 4M
read_buffer_size        = 4M
join_buffer     = 4M
read_rnd_buffer     = 4M
max_allowed_packet  = 64M
thread_stack        = 192K
thread_cache_size       = 16
query_cache_type        = 1
myisam-recover          = BACKUP
max_connections         = 20
table_cache             = 1024
innodb_buffer_pool_size = 128M
query_cache_limit   = 24M
query_cache_size        = 256M

PHP

[apc]
apc.stat=1
apc.enabled=1
apc.optimization=0
apc.cache_by_default=1
apc.shm_segments=10
apc.shm_size=256M
apc.ttl=0
apc.user_ttl=0
apc.num_files_hint=10000
;apc.mmap_file_mask="/tmp/apc"
apc.max_file_size=5M
apc.enable_cli=1
apc.mmap_file_mask="/tmp/apc.XXXXXX"
apc.slam_defense=0
apc.user_entries_hint=10000

모든 것이 완벽하게 작동하지만 한 가지 질문이 남아 있습니다. APC는이 통계를 보여줍니다. 여기에 이미지 설명을 입력하십시오

왜 그렇게 작은 안타? 어떤 아이디어?


Magneto 설치에 관한 몇 줄을 삭제하면 (예 : 카탈로그 크기, 수정, 확장 등) 좋을 것입니다.
user487772

서버를 올바르게 설정할 수 있도록 누군가가 일련의 구성 파일을 게시 할 수있는 방법은 없습니다. 수십 개의 파일이 있습니다. 사용 가능한 하드웨어를 최대한 활용하기 위해 필요한 소프트웨어 및 시스템 수준 변경 사항의 특정 개정.
Ben Lessani-Sonassi

downvote를 설정 한 이유를 설명해주세요
Anthony

@Tim 나는 질문을 업데이트했다
Anthony

2
나는 xhprof로드에 가장 많은 시간이 걸리는 것에 대한 시각화를 시도합니다. 이 서버는 부하가 걸리거나 테스트 용으로 만 사용됩니까?
philwinkle

답변:


6

질문이 매우 마 젠토 중심적이지 않은 것 같으므로, 여기에는 매우 마 젠토 중심의 대답이 아닙니다.

OpCode 캐싱 및 DB 최적화는 웹 애플리케이션을 어느 정도 가속화하는 좋은 방법입니다. 그러나 그 혜택은 상대적으로 적당합니다. 실제 속도 향상을 위해서는 니스 캐시 사용을 고려해야합니다. 무료로 제공되는 magento 모듈 덕분에 오픈 소스이며 구성이 쉽고 magento와 쉽게 통합 할 수 있습니다.

작동 방식에 대한 간단한 개요가 담긴 좋은 기사도 있습니다. http://www.fabrizio-branca.de/make-your-magento-store-fly-using-varnish.html

특히 차트를 고려하십시오.

초당 페이지 수


4
이미 빠른 상점이 있고 자원을 상쇄하려는 경우 니스가 좋습니다. 그러나 상점이 느리다는 사실을 숨기는 데 사용해서는 안됩니다. 페이지는 여전히 처음에 생성되어야하므로 페이지로드 시간은 항상 6-10 초입니다.
Ben Lessani-Sonassi

이전에 사용한 memcached와 같습니다. mysql 속성에서 서버를 잘못 생각하거나 서버가 너무 약하다고 생각합니다.
Anthony

2

비즈니스가 호스팅 성능에 의존하는 경우 왜 경험이없는 서버를 관리하려고합니까?

전문 Magento 호스트에게 연락하여 시스템 관리를 맡기고 가게를 잘 관리하면서 유익한 혜택을 얻을 수 있습니다.

사양을 살펴보면 Magento 저장소를 실행하기에 충분한 RAM이 없습니다. 당신과 비슷한 질문이 많이 있습니다.

https://serverfault.com/a/400748/113375 .
/server/430565/magento-hosting-on-a-budget


고객에게 예산이 제한되어 있기 때문입니다. mounth 당 50 유로 이상의 마 젠토 호스트에 지불해야합니다. 우리는 호스트 150-200 유로 한도에 제한이 있습니다-) 어쨌든 링크 주셔서 감사합니다
Anthony

1
그러면 고객은 100 % 최적화를 통해 연간 $ 20-40,000의 수익을 올릴 수 있습니다 (호스팅은 수익의 0.5-1 %). 여기에 모든 세부 사항과 기술 설정을 제공 할 수있는 많은 사람들이 있지만 너무 적은 노력으로 많은 노력을 기울이고 있습니다. 기술 측면에서는 효과가 있지만 비즈니스 측면에서는 문제가 없습니다. fpc없이 동적 페이지로드가 3 초 미만인 경우를 제외하고 방문자의 56 %를 잃는 것이 이상적입니다. 1-2 초를 목표로하는 것이 이상적입니다. Google과 방문자 전환은 사이트를 달리 처벌합니다. 이 상황에서 95-99 %의 확률로> 3s 페이지로드 및 / 또는 사이트가 다운됩니다.

1

이 물리적 하드웨어입니까 아니면 가상 사설 서버입니까? 데이터베이스를 자체 전용 서버로 이동해야합니다. 또한 속도 문제가 Apache / PHP 또는 MySQL에 있는지 여부를 격리 할 수있는 이점을 제공합니다.

start_session ()이 느리다는 것은 아마도 저전력 하드웨어에 시달리고 있다는 것을 의미합니다. 기술 선택에 따라 세션이 디스크 또는 RAM에 저장되는지 여부는 알 수 없지만 500-700ms는 디스크에 저장되어 있고 I / O 성능 문제가 있음을 의미합니다. 아마도 데이터베이스가 RAM에 맞지 않기 때문에 디스크로 스와핑하지만 모든 추측입니다.

행운을 빕니다!


답변 주셔서 감사합니다! VPS를 사용합니다. magento에는 적합하지 않지만이 범위에서 최적화하는 작업이 있습니다. 데이터베이스가 디스크로 스와핑되는지 확인할 수 있습니까?
Anthony

1
free -m스왑을 사용하고 있는지 알려주고 최신 버전의 top명령은 스왑 사용법으로 주문하려면 O와 P를 눌렀는지 알려줍니다. 그렇지 않으면 다음과 같은 방법으로 mysqld의 프로세스 ID를 사용하는 것으로 되돌아 가야합니다. awk '/^Swap:/ { SWAP+=$2 } END { print SWAP" kB" }' /proc/$(pidof mysqld)/smaps 모두 설명 : dbasquare.com/2012/04/10/…
Ralph Tice

1

성능을 향상시키는 '작동 구성'을 보여줄 방법은 없지만 Magento는 실제로 이와 같은 작업을 시도하고 성능 백서에 고도로 구성된 LAMP 스택의 예를 게시합니다. 이 백서의 방법론은 CE 및 EE에 적용됩니다. 이 스레드의 많은 부분을 반영하고 소스에서 직접 매우 구체적인 마 젠토 권장 사항을 제공한다고 제안한 아이디어로 두 백서를 완전히 읽는 것이 좋습니다. http://www.magentocommerce.com/whitepaper/


1

구성

ZendFramework (zend 최적화 프로그램 및 zend 데이터 캐시) + APC + Memcache + Nginx

나를 위해 완벽하게 작동합니다.

30 명 이상의 동시 사용자가 1 초 미만 (~ 0.4 초 -0.6 초)의 페이지를로드 할 수 있음

nginx를 80 포트 (프록시로)에 설정하고 아파치를 8080에 설정했습니다.

링크에 대한 @MattSchweers에게 감사합니다. 잊어 버렸습니다. MySQL을 구성하는 데 도움이됩니다.


문제 없어요! 나는 실제로 이번 주에 나 자신을 조정하는 일부 MySQL에 대해이 백서를 사용했습니다.

1

내 경험상 litespeed 서버는 $ 32 / 월 1cpu 라이센스의 가치를 2 배 향상시킵니다. PHP가 litespeed에서 분리되어 실행되므로 1cpu 라이센스 만 필요하다고 들었습니다.


웹 서버는 병목 현상이 아닙니다. PHP는 Litespeed로 변경해도 아무런 변화가 없습니다.
Ben Lessani-Sonassi

나는 일반적으로 라이트 스피드가 마 젠토에게 훌륭한 선택이라는 데 동의하지만,이 답변은 아마도 OP에 의해 제기 된 문제를 해결하지 못할 것이며 그의 명시된 예산을 벗어난 것입니다.
Preston

0

여러 개의 웹 스토어와 여러 범주가있는 경우 Magento는 기본적으로 모든 웹 스토어, 범주 및 제품에 대해 일종의 caretsian 제품 항목을 생성하므로 데이터베이스에 상당한 부하를 가하게됩니다. 귀하의 APC 미스가 상당히 높으므로 조사해야합니다. 그러나 APC를 수정하더라도 트래픽이 증가하면 성능 문제가 지속될 수 있다고 생각합니다. 사이트 속도를 높이려면 Var 캐시 또는 전체 페이지 캐시 (Enterprise Edition 인 경우)와 같은 op 캐시를 설치해야합니다.

Magento는 DB에 대한 많은 읽기 쓰기를 수행하므로 마스터 슬레이브 복제 모드에서 MySQl이 슬레이브에서 모든 magento 읽기를 갖도록하고 쓰기는 마스터에 수행되도록 시도 할 수도 있습니다.


0

다음 APC 옵션을 변경하고 조회수가 발생하는지 확인합니다.

apc.shm_segments 1

apc.ttl 7200

apc.user_ttl 7200

라이브 사이트에서 다음을 사용할 수도 있습니다.

apc.stat 0

이렇게하면 파일이 마지막으로 컴파일 된 후 변경되었는지 APC 검사가 중지되어 속도가 크게 향상됩니다. PHP 파일을 편집 할 때 APC 캐시를 플러시하는 것을 잊지 마십시오.


0

다른 생각을하세요. innodb_buffer_pool_size를 늘리고 싶을 수 있습니다. 128M은 약간 낮을 수 있으며 작은 사이트조차도 매우 빠르게 커질 수 있습니다. 변수는 메모리에 얼마나 많은 데이터가 보관되는지를 나타냅니다.

Magento는 빠르게 성장하는 로그 테이블을 포함하여 모든 테이블에 이것을 사용합니다. 보관하고있는이 데이터의 양을 제한해야합니다. 명령 행에서 "php shell / log.php --status"를 실행하면 현재 위치와 손이 닿지 않는지 알 수 있습니다. 로그 테이블을 정리하는 옵션도 있습니다.

2GB의 RAM은 그다지 잘 작동하지 않으므로 메모리를 할당하는 위치에주의해야합니다.

또한 Full Page Cache + Cache Warmer를 사용하면 사이트의 카탈로그 및 cms 페이지를 프라이밍하고 빠르게 유지할 수 있습니다. 당신은 여기에 우리를 볼 수 있습니다 : http://ecommerce.brimllc.com/full-page-cache-magento.html

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.