Скъсва се даже.... ама аз вече не смея да се обаждам, че блинки си мисли че е нарочно :wink:
значи паузирах клаудфлеъра
сложете за днс 8.8.8.8 и 8.8.4.4 и ще излезе веднага бързичък иначе утре чак като ви рефрешне на доставчика днса
има на предвид че паузирах клаудфлеъра и не минава през тяхната мрежа и си работи
само че който си ползва днисте на испто още го вижда през клаудфлеъра... и вероятно до утре ще го вижда така или докато ъпдейнте след някоя друга седмица
с днсите на гугъл в момента ще го видите бърз те още като писах рефрешнаха имам плъгин на брузъра показва уебсървъра...... като cloudflare-nginx се смени с litespeed няма нужда да гледам че е рефрешналао
дам това имах на предвид явно доставчика ти е свестен някой чак утре в другиден, другата седмица ще ъпдейтнат итнт въпреки че днс записа има нисък ттл затова им казах да си сложат днсите на гугъл
Smart Keep-Alive Go to top
Description: Specifies whether to turn on Smart Keep-Alive. This option is effective only if Max Keep-Alive Requests > 1. If enabled, you can also enable/disable it at virtual host level. Smart keep-alive will only establish keep-alive connections for requests of JavaScript, CSS Style Sheet and image files. For html pages, connection will not be kept alive. This will help serve more users more efficiently. Normally a web page contains multiple images and scripts that will be cached by the browsers after initial request. It is more efficient to send those non-html static files through a single keep-alive connection and have the text/html file send through another non-keep-alive connection. This method will reduce idle connections and in turn increase capacity to handle more concurrent requests and users.
Syntax: Select from radio box
Tips: [Performance] Enable it for high-load web sites.
До момента съм ползвал (пробвал) по един или друг повод над 15 хостинг доставчика, и твърдя, че повечето (да не кажа почети всички) са много зле. Ето какво ми отовориха преди няколко дена от един от тях:
We are working to improve the time to first request completion. We attribute this to not having a PHP opcode cache installed, as we have seen greater first-request speeds in the past when utilizing a PHP opcode cache. The problem is the current version of LiteSpeed coupled with CloudLinux tend to run in to issues when trying to run a PHP opcode cache. We are working closely with LiteSpeed to try to resolve this issue, and as soon as it is resolved we will get an opcode cache installed and we should see significant first-request speed improvements.
За справка, въпросниата първа заявка се изпулнява за около 0.5 - 1.5 секунди !!!!! (от там позва зареждане на сайта, реално)