Sziasztok!
Van pár perl alapú cgi-s webszerverünk.
A nagy méretű pdf-k (20MB+) böngészőbe való betöltése, letöltése "túl" lassú a felhasználók szerint.
pld.: wget-tel, de böngészőben is több perc:
.pdf 100%[===================================================>] 135,65M 4,11MB/s idő 6m 31s
A documentumok iscsi disk en vannak.
A perl alapú webes program telepítésénel 2.4 apache-hoz ezt ajánlották:
a2dismod mpm_event
a2enmod mpm_prefork
+ apache.conf ba írtam
StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 4000 StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0
plusz ez alapján:
https://httpd.apache.org/docs/2.4/misc/perf-tuning.html --> Sendfile
EnableSendfile off
Őszintén szólva érezhető a gyorsulás 10 MB eszméletlen gyors (böngésző cache-t mindig ürítem + privát ablak a teszteléseknél).
De a 20+ MB pdf-k nél igen csak akadozik, a 100MB+ file-k nál meg már tényleg sok a 4-5 perc nem?
Valakinek már volt hasonló problémája, tudnátok segíteni?
[Megoldás]
igaz régen volt 2018 aug.
Wireshark -al vizsgálva a forgalmat, rengeteg TCP Dup ACK fogadott a külső hálózaton való letöltésnél
Erre találtam egy "leírást"
https://serverfault.com/questions/799421/tcp-dup-ack-linux-kernel-3-2
Ha jól értelmeztem akkor egy "tűzfal" beállítás okozza a problémát.
De volt egy lehetőség ennek megkerülésére , szerveren beállítottam a következőt:
net.ipv4.tcp_sack = 0
és láss csodát kiváló lett a külső hálózatról a letöltés még 40-50 MB fileok is pár mp alatt lenn vannak nem akad a kapcsolat.
- 1585 megtekintés
Hozzászólások
Rosszul jelent meg sajnos: <>
--IfModule prefork.c--
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 4000
--/IfModule--
--IfModule worker.c--
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
--/IfModule--
- A hozzászóláshoz be kell jelentkezni
Megneznem a szerver memoriajat, amin az apache fut. Fura hogy tiz megas file-t meg gyorsan felolvas valahonnan (iscsi target), de az annal nagyobbakat csak nyogvenyelosen.
Na most vagy az apache oldalan megy el az I/O vagy az iscsi target oldalan.
Masik lehetseges ok, mondjuk hogy iscsi/network hibak miatt forog valami rendszerhivasban. Mehet ra az strace -c az apache-ra, aztan ha meg tudod allapitani, hogy mi a perl process, akkor arra is.
- A hozzászóláshoz be kell jelentkezni
Memóriát néztem, van még szabad bőven.
Talán a másik fontos dolgot elfelejtettem feltüntetni.
Vannak hasonló webszerverek de ott 2.2 apache van és szépen dolgozik( folyamatosan tölti, nem akadozik). Sajnos azokat nem én telepítettem, dokumentáció nélkül nem igazán találom a különbséget. Természetesen átnéztem az apache könyvtárakat, de ott is csak a ifmodul .. van pluszban.
- A hozzászóláshoz be kell jelentkezni
Na ezert kell egy jo kis IaaC tool (ansible, puppet, chef, saltstack, stb.), hogy tuti minden ugyanugy nezzen ki. Na de ez most nem relevans.
En megprobalnam egy sim apache 2.4-el tesztelni mindenfele modul nelkul a letoltest, ha ugy jo, akkor aztan egyesevel bekapcsolnam a modulokat, hogy hol cseszodik el az egesz.
- A hozzászóláshoz be kell jelentkezni
Megpróbálom, köszönöm.
- A hozzászóláshoz be kell jelentkezni
Ideglenesen megoldva.
Wireshark -al vizsgálva a forgalmat, rengeteg TCP Dup ACK fogadott a külső hálózaton való letöltésnél-
Vpn keresztül, ez a hiba jelenség nem jelentkezett.
De találtam egy leírást:
https://serverfault.com/questions/799421/tcp-dup-ack-linux-kernel-3-2
Ha jól értelmeztem akkor egy tűzfal beállítás okozza a problémát.
De azért szerveren beállítottam a következőt:
net.ipv4.tcp_sack = 0
és láss csodát kiváló lett a külső hálózatról a letöltés még 40-50 MB fileok is pár mp alatt lenn vannak nem akad a kapcsolat.
- A hozzászóláshoz be kell jelentkezni
Meg egy gyors kérdés a fenn említett ideglenes megoldás, hordoz e magában valami fajta veszélyforrást?
- A hozzászóláshoz be kell jelentkezni