>Когда показывается страница с продуктом читается информация из файла.
А смысл? Не нагружать базу?
>Кластер — как синхронизировать статитику между кластерами — это уже проблема сисадмина.
Я считаю, что программист и сисадмин должны работать вместе, а не придумывать друг другу проблемы. Ведь еще не понятно, что будет неэффективнее — забить данные в базу, или переходить на NAS/SAN для хранения файлов и распарсивать XMLки.
Кстати, в Вашем случае, как я понял, XMLка обновляется достаточно редко, поэтому можно без кластерной ФС хранить по экземпляру на каждой ноде (или база огромного размера?), и не заботиться о моментальной синхронизации, а раз в N времени синхронизировать их скриптом. В этом случае использование файлов — оправдано.
Пункт в основном был о «изящном» решении, которое я недавно повстречал на одном проекте. Весь контент был в XML-файлах. В базе хранились какие-то ошметки метаинформации — структура папок, путь до xml файлов, поля их элементы. Данные обновлялись часто.
Вообще, в советах нет крайностей — нигде нет слов «Всегда» или «Никогда». Значит, при инвертировании, в советах не получится этих же слов. Использование всего этого бывает оправдано (правда, кроме пары пунктов), но перед использованием надо очень хорошо подумать.
>Так что механизм SSI для высоконагруженных систем в топку?
Идея SSI — не в том, чтобы инклюдить статику в динамику, а в том, чтобы разбивать сайт на независимые блоки, генерящиеся параллельно/разными машинами. А то, для чего Вы хотите использовать SSI — это уже кеш тех самых независимых блоков.
>Кстати за частую совет очень и очень даже хороший.
Да, бывает. Но, на мой взгляд, сайт надо разделять на три части:
1) код. пишется, дорабатывается, потом — перемещается на продакшн.
2) статика. появляется один раз, удаляется 1 раз. Время между первым и вторым — достаточно большое.
3) данные. меняются, запрашиваются постоянно.
Например, если сейчас у нас эти три понятия разделены, то статику можно бекапить по мере создания, а данные — раз в N часов. Получаются тривиальные скрипты — один вызов tar cf или mysqldump. А если мы выносим данные в файлы, то теперь в бекапе статики нам придется делать exclude, в бекап данных — добавлять tar.
Но основная проблема, как я описал — в разнесении всей информации на кластер, поддержании нормальной скорости доступа к ней, блокировок и так далее.
md5() — конкретное название конкретной функции, трансформирующей одну строчку в другую по каким-то непонятным правилам. Именно поэтому и стоят скобочки. Правила легко могут быть и алгоритмом хеширования.
Вообще, в базовом случае используется 3хх редирект на /protect, оттуда — 3хх редирект на сайт. Некоторые боты не понимают и этого.
В случае, если это не помогает, подключается js.
Да, проблема с noscript действительно существует. Для них можно сделать отдельную станичку, например, с капчей (другой вопрос — будут ли они ее вводить, а не закрывать сайт), с просьбоой отправить письмо, с еще кучей возможных вариантов — система не зафиксирована, а постоянно дорабатывается под нужды.
Но иногда — очень криво. Написатели сайтов любят выносить часть логики и кода своего проекта в mod_rewrite с извращенной обратной логикой и кучей Cond'ов.
Ведь если клиент хостера заказал настройку сервера у хостера, а не сделал ее сам, то он не сможет воспользоваться советами из статьи — он просто не знает, как проверить, что php работает как cgi, а у mysql — мало памяти. А по графику munin'a, наверно, пользователь заметил улучшения по сравнению с тем, что было до «настройки».
А лично мне не понравилось из поставленного:
1) mod_php. Пережиток прошлого, уродская штука. Не запускает программы юзера под юзером. Встраивается в веб-сервер. Не thread-safe. Зачем такое нужно? Вместо него рулит php-fcgi или php-fpm.
2) можно было либо отказаться от apache, перейдя на nginx+php-fcgi, либо сделать apache-mpm-worker, что дало бы прирост, но, опять же, запретило mod_php.
В принципе, делать это можно и алертом, можно — простым редиректом на javacsript — главное, что боты не умеют выполнять javascript.
У меня есть решение, которое умеет такое делать. Пропускает google и yandex, обычным клиентам 1-2 секунды показывает белый лист с надписью «подождите», пока не загрузит сайт.
Боты, попавшиеся на том, что не ходят по сайту, а только запрашивают страницу с javascript, банятся средствами ОС FireWall.
Я понимаю это, и это — отвратительная особенность case. break не связан со смыслом того, что должно выполняться, он связан со смыслом того, что не должно выполняться. Это можно переписать в более абсурдном виде:
foo();
do_not_execute_bar();
bar();
А смысл? Не нагружать базу?
>Кластер — как синхронизировать статитику между кластерами — это уже проблема сисадмина.
Я считаю, что программист и сисадмин должны работать вместе, а не придумывать друг другу проблемы. Ведь еще не понятно, что будет неэффективнее — забить данные в базу, или переходить на NAS/SAN для хранения файлов и распарсивать XMLки.
Кстати, в Вашем случае, как я понял, XMLка обновляется достаточно редко, поэтому можно без кластерной ФС хранить по экземпляру на каждой ноде (или база огромного размера?), и не заботиться о моментальной синхронизации, а раз в N времени синхронизировать их скриптом. В этом случае использование файлов — оправдано.
Пункт в основном был о «изящном» решении, которое я недавно повстречал на одном проекте. Весь контент был в XML-файлах. В базе хранились какие-то ошметки метаинформации — структура папок, путь до xml файлов, поля их элементы. Данные обновлялись часто.
Вообще, в советах нет крайностей — нигде нет слов «Всегда» или «Никогда». Значит, при инвертировании, в советах не получится этих же слов. Использование всего этого бывает оправдано (правда, кроме пары пунктов), но перед использованием надо очень хорошо подумать.
>Так что механизм SSI для высоконагруженных систем в топку?
Идея SSI — не в том, чтобы инклюдить статику в динамику, а в том, чтобы разбивать сайт на независимые блоки, генерящиеся параллельно/разными машинами. А то, для чего Вы хотите использовать SSI — это уже кеш тех самых независимых блоков.
исправил :)
>Кстати за частую совет очень и очень даже хороший.
Да, бывает. Но, на мой взгляд, сайт надо разделять на три части:
1) код. пишется, дорабатывается, потом — перемещается на продакшн.
2) статика. появляется один раз, удаляется 1 раз. Время между первым и вторым — достаточно большое.
3) данные. меняются, запрашиваются постоянно.
Например, если сейчас у нас эти три понятия разделены, то статику можно бекапить по мере создания, а данные — раз в N часов. Получаются тривиальные скрипты — один вызов tar cf или mysqldump. А если мы выносим данные в файлы, то теперь в бекапе статики нам придется делать exclude, в бекап данных — добавлять tar.
Но основная проблема, как я описал — в разнесении всей информации на кластер, поддержании нормальной скорости доступа к ней, блокировок и так далее.
ru2.php.net/md5:
Но вывод правильный — сделано ради денег. Для этого был раньше сделан аукцион, который тоже не АНО :)
В случае, если это не помогает, подключается js.
Да, проблема с noscript действительно существует. Для них можно сделать отдельную станичку, например, с капчей (другой вопрос — будут ли они ее вводить, а не закрывать сайт), с просьбоой отправить письмо, с еще кучей возможных вариантов — система не зафиксирована, а постоянно дорабатывается под нужды.
Ведь если клиент хостера заказал настройку сервера у хостера, а не сделал ее сам, то он не сможет воспользоваться советами из статьи — он просто не знает, как проверить, что php работает как cgi, а у mysql — мало памяти. А по графику munin'a, наверно, пользователь заметил улучшения по сравнению с тем, что было до «настройки».
А лично мне не понравилось из поставленного:
1) mod_php. Пережиток прошлого, уродская штука. Не запускает программы юзера под юзером. Встраивается в веб-сервер. Не thread-safe. Зачем такое нужно? Вместо него рулит php-fcgi или php-fpm.
2) можно было либо отказаться от apache, перейдя на nginx+php-fcgi, либо сделать apache-mpm-worker, что дало бы прирост, но, опять же, запретило mod_php.
У меня есть решение, которое умеет такое делать. Пропускает google и yandex, обычным клиентам 1-2 секунды показывает белый лист с надписью «подождите», пока не загрузит сайт.
Боты, попавшиеся на том, что не ходят по сайту, а только запрашивают страницу с javascript, банятся средствами ОС FireWall.
А что мешает прийти на сервер следубщему админу, настроить его по-своему, показать график, почему это лучше и сделать такой же пост на хабре?
foo();
do_not_execute_bar();
bar();
if(WM_PAINT == msg) { foo(); } else if(WM_QUIT == msg) { bar(); } .... else { default(); }Наверно, если бы делал, то делал так:
switch(msg) { case WM_PAINT: foo(); break; case WM_QUIT: case 0: bar(); break; }Но выглядит все равно как-то уродско.
if(a) { foo(); }?
Это не правильно, надо так:
if(a) { foo(); }