Magento i APC

[Miłosz 2311]

Mam problem ze zmuszeniem Magento do używania APC. Wersja Magento to 1.7.1, APC próbowałem w różnych wersjach.

 

Konfig z Magento:

<cache>
<backend>apc</backend>
<prefix>MYSTORE_PODST_</prefix>
</cache>

Konfig APC, kombinowane z różnych stron:

apc.enabled=1
apc.shm_segments=1

apc.shm_size=1G
apc.num_files_hint=10000

apc.optimization=0

apc.user_entries_hint=10000

apc.ttl=7200
apc.user_ttl=7200
apc.gc_ttl=3600

apc.stat=1

apc.include_once_override=0

apc.enable_cli=1
apc.file_update_protection=2
apc.max_file_size=10M

apc.cache_by_default=1
apc.use_request_time=1
apc.slam_defense=0
;apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.mmap_file_mask=/dev/zero
apc.stat_ctime=0
apc.canonicalize=1
apc.write_lock=1
apc.report_autofilter=0
apc.rfc1867=0
apc.rfc1867_prefix =upload_
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_freq=0
apc.rfc1867_ttl=3600
apc.lazy_classes=0
apc.lazy_functions=0

Jakieś pomysły? Komuś działa Magento z APC poprawnie?

 

[malu 460]

Tak trochę offtopic, ale APC is dead. ; )

Xcache, Zend opcache.

[Miłosz 2311]

Będziemy robić upgrade php na 5.4 i pewnie xcache wrzucimy

[progreso.pl 94]

Będziemy robić upgrade php na 5.4 i pewnie xcache wrzucimy

 

Magento z xcache nie działa stabilnie (stosunkowo sporo segmentation faultów). Z APC śmiga b. dobrze - z czym konkretnie masz problem? Mój konfig:

 

apc.shm_size = 256M

apc.max_file_size=5M

apc.file_update_protection=2

apc.enabled=1

apc.enable_cli=0

apc.cache_by_default=1

apc.include_once_override=0

apc.localcache=0

apc.localcache.size=512

apc.num_files_hint=10000

apc.report_autofilter=0

apc.rfc1867=0

apc.slam_defense=1

apc.stat=1

apc.stat_ctime=0

apc.ttl=7200

apc.user_entries_hint=10000

apc.user_ttl=7200

apc.write_lock=1

Magento b. duże (największe w Polsce chyba

[Miłosz 2311]

Z tym że nie keszuje nic a nic.

 

A na xcache wali 500

[malu 460]

A zapytam inaczej, jak uruchamiasz PHP?

[Miłosz 2311]

Aktualnie suphp, ale ma być fpm.

[www.ionic.pl 535]

na samsym suphp przecie tracisz tyle, że głowa boli, podaj to php inaczej i zrób opcache,

ps poczytaj też jak coś docsy apc, bo masz trochę "dziwny" ten konfig

[malu 460]

Żaden opcache nie będzie Ci Miłosz działał po CGI. : )

Zmień po prostu sposób wykonywania, skoro masz suphp to pewnie siedzi tam DA, więc jak najbardziej możesz użyć custombuilda2 i wrzucić tam php po fcgid. (Lepiej działa z apache niż proxy na mod_fastcgi do php-fpm)
Bo raczej nikt nie używa suphp budując swoje środowisko.

[Miłosz 2311]

Nie ma tam DA

Postawnowione jest już przejście na FPM.

[Gość patrys]

W ogóle używanie SUPHP to smutna sprawa nawet na środowisku z DirectAdmin, a co dopiero próbować na nim uruchomić Opcache skoro on sam forkuje procesy per request.

 

Tak nic nie mówiąc pod skrypty ala Magento jeżeli chcemy używać Apache, to dobrze się sprawdza i nie jest problemowy mod_php + ruid2.

Przy FPM uruchomionym np. przez mod_fastcgi mogą pojawić się problemy z funkcjonowaniem Magento ( kiedyś mieliśmy problem, ale nie pamiętam jaka to byłą wersja Magento ).

[Miłosz 2311]

Jakiś czas temu próbowałem na szybko odpalić to Magento na fpmie i właśnie był jakiś problem. Sklep walił 500tkami. W weekend chciałem przenieść sklep na testową maszyne i zobaczyć o co z tym fpmem tam chodzi.

Jak powiadasz, że mod php i ruid2 daje rade, to też przetestuje na nim.

 

A u siebie na DA mam fcgid.

[Miłosz 2311]

No dobra.. śmiga sobie mod_php + mod_ruid2. Dorzuciłem xcache. Narazie na szybko z repo, wersja 2.0.0.

 Warning: xcache_set(): XCache var cache was not initialized properly.

Zagawozdka, od czasu do czasu wywala pomimo, że xcache.var_size jest na 512M.

 

[Gość patrys]

Narazie na szybko z repo, wersja 2.0.0.

 

Na szybko to policja w parku mandaty wypisuje

 

Pokaż konfiguracje, bo po ostatnim, to tam może być wszystko.

Choć na początek to dobra zasada by nie korzystać w takich przypadków z "repo", a zainstalować w wersji ostatniej stabilnej.