kamilo123 0 Zgłoś post Napisano Czerwiec 12, 2015 Hej, MAM VPS w OVH cloud ten 4rdzenie i postawiony sklep, który korzysta z integratora z magazynem. Jak pobieram produkty no to niestety pobiera mi tylko po 1 produkcie, jak skonfigurować tego VPS-a aby np. obsługiwał 20 wątków jednocześnie bo dodawać 10 tyś produktów po 1 no to mu się schodzi trochę. PLESK + ubuntu. Udostępnij ten post Link to postu Udostępnij na innych stronach
mcbarlo 61 Zgłoś post Napisano Czerwiec 12, 2015 Prędzej bym obstawiał, że to po stronie aplikacji, a nie serwera leży problem. Udostępnij ten post Link to postu Udostępnij na innych stronach
gutek 23 Zgłoś post Napisano Czerwiec 12, 2015 Wg mnie aplikacja pobiera 1 wątkowo dane i dlatego tak powoli idzie. Może skonfiguruj aplikację tak aby np. pobierała wg ustalonych przedziałów dane i wówczas dla każdego przedziału po jednym uruchomieniu aplikacji z paramatrem (przedziałem danych) ? Tylko nie przesadzałbym z ilością uruchomionych apek bo przy 4 rdzeniach raczej nie warto więcej niż 4 uruchomienia równolegle chyba, bo i tak spadnie wydajność. Udostępnij ten post Link to postu Udostępnij na innych stronach
kamilo123 0 Zgłoś post Napisano Czerwiec 13, 2015 Twórca skryptu powiedział mi, że to wina serwera, cytując ,, jeżeli serwer nie potrafi dodawać więcej niż 1 wątek to gówno nie serwer''. Co wydaje mi się dziwne serwer ma 4 rdzenie, obciążenie w trakcie dodawania jest znikome. No i nie wiem czy próbuje zrobić ze mnie idiote bo sprzedaje gówniany skrypt czy to rzeczywiście wina konfiguracji serwera. Udostępnij ten post Link to postu Udostępnij na innych stronach
blfr 225 Zgłoś post Napisano Czerwiec 13, 2015 A co to za skrypt? W czym napisany? Jak go uruchamiasz? Pokaż cat /proc/cpuinfo Udostępnij ten post Link to postu Udostępnij na innych stronach
kamilo123 0 Zgłoś post Napisano Czerwiec 13, 2015 (edytowany) root@:~# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 0 model name : AMD Opteron(tm) Processor 4386 stepping : 2 microcode : 0x6000829 cpu MHz : 3100.000 cache size : 2048 KB fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes xsave avx hypervisor lahf_lm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw xop fma4 arat bogomips : 6200.00 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: processor : 1 vendor_id : AuthenticAMD cpu family : 21 model : 0 model name : AMD Opteron(tm) Processor 4386 stepping : 2 microcode : 0x6000829 cpu MHz : 3100.000 cache size : 2048 KB fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes xsave avx hypervisor lahf_lm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw xop fma4 arat bogomips : 6200.00 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: processor : 2 vendor_id : AuthenticAMD cpu family : 21 model : 0 model name : AMD Opteron(tm) Processor 4386 stepping : 2 microcode : 0x6000829 cpu MHz : 3100.000 cache size : 2048 KB fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes xsave avx hypervisor lahf_lm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw xop fma4 arat bogomips : 6200.00 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: processor : 3 vendor_id : AuthenticAMD cpu family : 21 model : 0 model name : AMD Opteron(tm) Processor 4386 stepping : 2 microcode : 0x6000829 cpu MHz : 3100.000 cache size : 2048 KB fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes xsave avx hypervisor lahf_lm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw xop fma4 arat bogomips : 6200.00 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: Edytowano Czerwiec 13, 2015 przez kamilo123 (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
Misiek08 285 Zgłoś post Napisano Czerwiec 14, 2015 Jeżeli nie chcesz publicznie powiedzieć nic o skrypcie to podaj na PW albo informacje o skrypcie albo dane, pod którymi np. w trybie do odczytu można go obejrzeć. Po kontakcie powiem Ci, czy wina leży po stronie serwera, czy skryptu (jeżeli tak, to przy okazji chętnie powiem co napisać autorowi, żeby nie cwaniaczył na przyszłość) oraz powiem ile by kosztowało u mnie poprawienie problemu. Sama analiza darmowa. Udostępnij ten post Link to postu Udostępnij na innych stronach
Pan Kot 1535 Zgłoś post Napisano Czerwiec 14, 2015 (edytowany) Twórca skryptu powiedział mi, że to wina serwera, cytując ,, jeżeli serwer nie potrafi dodawać więcej niż 1 wątek to gówno nie serwer''. Co wydaje mi się dziwne serwer ma 4 rdzenie, obciążenie w trakcie dodawania jest znikome. No i nie wiem czy próbuje zrobić ze mnie idiote bo sprzedaje gówniany skrypt czy to rzeczywiście wina konfiguracji serwera. Wystarczy odpalić htopa i samemu zobaczyć efekty. Generalnie PHP jest zorientowany na dużą ilość krótkich tasków, a nie na małą ilość długich tasków. To oznacza mniej więcej tyle, że PHP sam w sobie świetnie się skaluje i jest w stanie radzić sobie z ogromną ilością requestów, ale tylko i wyłącznie wtedy, kiedy te requesty same w sobie nie będą zbyt kosztowne. W 99.9% przypadków wolne działanie PHP to wina tylko i wyłącznie skryptu, ale bez analizy nikt Ci tego jasno nie stwierdzi. Po stronie serwera leży tylko i wyłącznie implementacja, a nawet najgorsza z nich (prefork) jest w stanie dla każdego requesta zespawnić osobny proces, który jest w stanie działać z 100% wydajnością pojedynczego rdzenia (czy wątku w przypadku HT) serwera. W przypadku lepszych implementacji (FPM), master jest na tyle sprytny, że bez problemu dynamicznie spawnuje nowych workerów, a każdy request ma podobnie jak w przypadku wcześniej dostęp do 100% mocy rdzenia/wątku. O dziwo, PHP od niedawna wspiera pthreadowe wątki, więc nawet zasobożerne skrypty można przepisać aby były mniej inwazyjne dla pojedynczego rdzenia i wspierały wiele z nich, ale jest to rzadkość i w 99.9% przypadków totalny bezsens, bo głównym obciążeniem dla PHP i jego workerów zawsze powinna być liczba requestów, a nie ich zasobożerność. Z doświadczenia wiem, że spowolnienie PHP z winy serwera jest możliwe tylko i wyłącznie przy wykonywaniu setek, albo i tysięcy requestów PHP, a nie pojedynczego requesta, który wolno parsuje dane. Pewno wina leży w gównianym skrypcie, który jest całkowicie niezoptymalizowany do pracy z większą ilością danych, widziałem już nie raz pseudo ekspertów, którzy pobierali dane tysiącem requestów MySQL zamiast jednym. Dzisiaj nikt już nie zwraca uwagi na jakość, elegancję i wydajność kodu, tylko na to "czy działa". Cholernie mnie to denerwuje. Edytowano Czerwiec 14, 2015 przez Archi (zobacz historię edycji) 1 Udostępnij ten post Link to postu Udostępnij na innych stronach
Dentarg 46 Zgłoś post Napisano Czerwiec 14, 2015 Archi skąd ja to znam, "jak działa za wolno, to trzeba kupić lepszy serwer" . Udostępnij ten post Link to postu Udostępnij na innych stronach
kamilo123 0 Zgłoś post Napisano Czerwiec 14, 2015 Pliki skryptu są zakodowane nic tam nie da się zobaczyć. (ionCube Loader). Udostępnij ten post Link to postu Udostępnij na innych stronach
kamilo123 0 Zgłoś post Napisano Czerwiec 14, 2015 To zobacz chociaz jak w momencie maksymalnego obciazenia zachowuje sie proces php. Rowniez moge z doswiadczenia potwierdzic to, co napisal Archi. Jak to konkretnie mogę sprawdzić ?? Udostępnij ten post Link to postu Udostępnij na innych stronach
OneDistrict 12 Zgłoś post Napisano Czerwiec 15, 2015 Dzisiaj nikt już nie zwraca uwagi na jakość, elegancję i wydajność kodu, tylko na to "czy działa". Cholernie mnie to denerwuje. Fajnie to ujales. Szczegolnie robia tak ludzie, ktorzy wykonuja zlecenia. Outsourcing juz jest lepszy, bo gotowy skrypt jest wystawiany dla sporej spolecznosci, ktory sie rozwija lepiej niz np. autorski CMS napisany przez - w dodatku - amatora. Udostępnij ten post Link to postu Udostępnij na innych stronach
Misiek08 285 Zgłoś post Napisano Czerwiec 15, 2015 Pliki skryptu są zakodowane nic tam nie da się zobaczyć. (ionCube Loader). Nie zawsze, czasami da się "coś" zobaczyć. Zapraszam na PW z kodem. Udostępnij ten post Link to postu Udostępnij na innych stronach
