платиновое правило номер один:
открывай логи и смотри что происходит
на debian (возможно и в centos также) добавляю в /etc/pam.d/sshd и /etc/pam.d/vsftpd (где нужен) строку:
account required pam_access.so
дальше в файле /etc/security/access.conf можно управлять доступом примерно так:
- : user : ALL EXCEPT xxx.xxx.xxx.xxx
т.е. запретить user'у доступ отовсюду, кроме указанных ip (через пробел можно несколько)
плюс тоже, доступ к ssh по ключу.
и проверить чтоб в /etc/ssh/sshd_config не стояло permitrootlogin yes
ну и порт не стандартный
за 10мин пишется php скрипт, который нужные файлы/базы упакует и отправит куда надо.
его в крон добавляем и все.
где проблема?
во-первых сервера бывают разные. может у них какраз под mysql серверок с терабайт+ памяти 🙄
во-вторых не забываем про суть оверселлинга.
наверняка там 99 клиентов суммарно не занимают базами эти 25гб, и также возможно есть один уникал с 25гб базой - ну и хрен бы с ним 🙄
в чем проблема?
как же интернет с гигабитным каналом продают за 1000р, учитывая что гарантированный гигабит стоит под $1000.
как сервер с 10 ядрами делят на 30 одноядерных vps
все просто, если придет второй уникал с 25гб базой, его просто разместят на втором сервере с еще 99 другими юзерами, не использующих и 1% дозволенных ресурсов.
это жесть конечно 🙄
а когда элементов меню будет 500 какая простыня там получится?
вот набросал по-быстрому исходя из поставленной задачи (и ничего более) добавлять class="active" в списке меню:
menu.php:
в массив $menu вписываем относительный путь к файлу и то как он в меню подписан будет.
и все. дальше в каждый файл просто вставляем:
index.php:
about.php:
contacts.php:
и по переменной $_SERVER['SCRIPT_NAME'] поймет скрипт где делать пометку class="active"
отличный пример кстати 🙄
они не работают, они выживают как могут...
тормозит естественно не сам php, а криворуко сделанные скрипты... километры скриптов.
если у вас там просто инклуды, то ничего страшного конечно.
да и все ведь относительно. кто-то к примеру не видит разницы когда mysql на локальном хосте и на удаленном работает.
а кто-то чувствует разницу как к локальной подключаться - по порту или сокету...
кому-то пофиг работает ли хост на hdd или любой ssd, а кому-то на нервы будут действовать "тормоза" pci-e ssd p3500, если он уже знает как может p3700...
запускайте php в html файлах. это же просто расширения. можете хоть .xxx обозвать, роли не играет.
как именно - надо знать что там у вас сейчас. может в админ-панели можно сделать, может вручную конфиг поправить, а может единственный (самый медленный) вариант - через .htaccess.
быстро - это когда nginx берет (из кэша желательно) готовый html и пулей отправляет клиенту.
без лишнего соплежуйства в виде передачи запроса к php или сперва к apache, а тот сперва поищет все .htaccess'ы по всем каталогам на пути к запрашиваемому файлу, исполнит все что там понаписали, потом только обрисует задачу php, и когда тот закончит, вернет обратно результат nginx, а тот уже клиенту, который уже уснул от ожидания 😒
потому и говорю - правильней инклуды свои запрятать в какую-нибудь запароленую папку /admin/ и запускать их когда что-то обновилось на сайте. чтоб они сгенерированный результат сохранили в основном сайте обычным .html'ем, который nginx будет сам отдавать без посредников.
но конечно понимаю что никто этим заморачиваться не будет :(
правильное решение: нужно сделать чтоб php выполнялся в прежних .html файлах.
еще более правильное решение: сделать скрытыми свои php'шки и запускать их при необходимости, чтоб те по шаблону генерировали нынешние .html
(если конечно задача не заключается именно в том чтоб сделать все медленней и выполнять какие-то скрипты при каждом запросе 😒 )
возникает вопрос - нафига вообще там тогда эти ul, li ?
если все что они делают удаляете стилями :)
кэшировать что-либо - это не решение проблемы, это костыль.
решение - ускорить выполнение запроса, уменьшить их количество и т.п.
но все это не вяжется с отдалением mysql (читай замедлением).
что если, грубо говоря, размер базы будет больше памяти, отведенной под memcache?
правильно - будут периодические подтормаживания. это еще хуже чем постоянные тормоза.
3. а должно все выглядеть...
как?
попробуйте убрать все те тучки вокруг текста - <ul>, <li>, </li> и </ul>
