тогда просто забейте... или, что правильней, просто вставьте кусок кода, котрый проверяет урл, и если на конце есть/нет слеша делает редирект на нет/есть (как больше нравится)
не стоит ничего мудрить. нет такого понятия как привала по джумли или еще по какмнить граблям. Так уж вышло, что в инете есть одно правило - правило *NIX. Если в пути в конце стоит / - это каталог, если нет - это файл. если бы сайт был нормальным (без кривых CMS) то проблем бы просто небыло. url _http://xxxx/aa - отдавался бы файл aa, а по url _http://xxxx/aa/ отдавался бы файл, установленный в настройках сервера как дефалтовый для папки. И никаких бы разногласий небыло. Разночтения возникают в кривых CMS с использованием километровых правил в модреврайте. Просто приведите правила в соотвествие со стандартом и небудет больше подобных глупых вопросов.
что касается яши... вспомните о панятии дубля (копии) страницы.....
MadvEX: А смысл для простеньких сайтов, у которых нагрузки нет, делать такое ускорение работы СУБД?
чтобы небыло криков, что на серваке лежи 20-30 дохлых сайтов на WP, а сервак уже не тянет....
MadvEX: написано куча полезных алгоритмов для обработки и поиска информации в БД
верно. Но задач, где это нужно - очень мало. Чтобы сформировать страницу для юзера, совсем не обязательно делать 10-50 запросвов к БД как в WP или до 70 как в джумле. Можно просто взять файл шаблона и "скрестить" его с файлом данных, в 90% случаев, статических.
cnst_bus: Нужна ли БД на файлах с удобным интерфейсом?
Планирую написание на обычных текстовых файлах.
БД на файлах, вернее, на основе файловой системы - штука весьма удобная для задачь, где не нужны сложные запросы и выборки. Чтобы она стала эффективной, нужно четко понимать саму задачу и не пытаться залесть туда, где "бинарный" подход SQL просто эффективней. Для CMS (обычные сайты, без сложных структрр данны) и форумов, безусловно, текстовые файлы удобней, проще, надежней, быстрее. В этом есть одно "но". Если все это облочить в шкурку, типа фреймворка, то все плюсы станут минусами... Прелесть прямой работы с файловой системой в скорости и минимизации проверок и ожиданий. Поэтому, хотите получить бычтрый инструмент, просто сделайте 5-10 удобных, заточенных под свою задачу функций и пользуйтесь. Не идити по стопам универсальности. Универсальность (ведь ее программисты придумали для облегчения своей работы), почти всегда, идет в простивовес скорости и качества для конечного пользователя.
а как вы хотите подругому парсить?? вас сразу забанят
я не занимаюсь детсвом. XML куда удобней. К тому же есть куда более эффективные способы, особенно для гугла...
3. Через скрипт у себя же...
это уже не очень хорошо, согласны?
Чистыее HTTP, имхо конечно, мало кому нужны, вернее может и нужны, но платить будут врятле. Легче наплодить свои...
одинаковые страницы
тогда просто забейте... или, что правильней, просто вставьте кусок кода, котрый проверяет урл, и если на конце есть/нет слеша делает редирект на нет/есть (как больше нравится)
Как закрыть к индексации страницу www.site.ru/stranica
но при этом оставить www.site.ru/stranica/
если нет сложных рерайтов, тогда объясните, по этим ссылкам отдаются разные страницы или одинаковые?
вопросы может и глупые, но учусь по ходу дела
без обид. Вопрос глуп не в вашем посте, а просто в сути....
не стоит ничего мудрить. нет такого понятия как привала по джумли или еще по какмнить граблям. Так уж вышло, что в инете есть одно правило - правило *NIX. Если в пути в конце стоит / - это каталог, если нет - это файл. если бы сайт был нормальным (без кривых CMS) то проблем бы просто небыло. url _http://xxxx/aa - отдавался бы файл aa, а по url _http://xxxx/aa/ отдавался бы файл, установленный в настройках сервера как дефалтовый для папки. И никаких бы разногласий небыло. Разночтения возникают в кривых CMS с использованием километровых правил в модреврайте. Просто приведите правила в соотвествие со стандартом и небудет больше подобных глупых вопросов.
что касается яши... вспомните о панятии дубля (копии) страницы.....
Я не предлагаю список битых и забаненых.. Меня интересует вопрос на счет на сколько будет востребованны списке?? нужны ли они кому-то вообще??
вопросы:
1. Какой тип прокси обсуждается (http/https/ftp/smtp)?
2. Забаненых где? (яша/гугл не обсуждается, ибо мало верю в извращенцев, которые по сей день парсят выдачу таким топором)
3. Как проверяется анонимность прокси?
4. Какой регион проксей?
А смысл для простеньких сайтов, у которых нагрузки нет, делать такое ускорение работы СУБД?
чтобы небыло криков, что на серваке лежи 20-30 дохлых сайтов на WP, а сервак уже не тянет....
написано куча полезных алгоритмов для обработки и поиска информации в БД
верно. Но задач, где это нужно - очень мало. Чтобы сформировать страницу для юзера, совсем не обязательно делать 10-50 запросвов к БД как в WP или до 70 как в джумле. Можно просто взять файл шаблона и "скрестить" его с файлом данных, в 90% случаев, статических.
Нужна ли БД на файлах с удобным интерфейсом?
Планирую написание на обычных текстовых файлах.
БД на файлах, вернее, на основе файловой системы - штука весьма удобная для задачь, где не нужны сложные запросы и выборки. Чтобы она стала эффективной, нужно четко понимать саму задачу и не пытаться залесть туда, где "бинарный" подход SQL просто эффективней. Для CMS (обычные сайты, без сложных структрр данны) и форумов, безусловно, текстовые файлы удобней, проще, надежней, быстрее. В этом есть одно "но". Если все это облочить в шкурку, типа фреймворка, то все плюсы станут минусами... Прелесть прямой работы с файловой системой в скорости и минимизации проверок и ожиданий. Поэтому, хотите получить бычтрый инструмент, просто сделайте 5-10 удобных, заточенных под свою задачу функций и пользуйтесь. Не идити по стопам универсальности. Универсальность (ведь ее программисты придумали для облегчения своей работы), почти всегда, идет в простивовес скорости и качества для конечного пользователя.
В пик активности 13-16 часов начинает хорошо притормаживать.
можно хоть какие-то данные?
1. Что за сервер.
2. тип серверного ПО.
3. Колическтов сессий в момент тормозов.
Вот, смотрю на серче картинки и js грузятся с поддоменов. Это для меньшей нагрузки?
это решение других задач, чащще всего, связанных именно с трафиком.
Скорее всего нагрузка идет из-за качания файлов.
это нагрузка не на сервер а на канал связи. Какой у Вас?
T.R.O.N добавил 31.08.2009 в 11:43
Под раздачу файлов поставить антилич с рейт лимитом 5 потоков на 1 ip
такое имеет смысл тольок на асинхронных каналах. Не думаю что сервак стоит на ADSL или подобном
Вынести этот стиль в <head> - ?
да, именно об этом валидатор и пишет.
Для остального - уберите все скрипты со страницы или закоментрируте их, дабы валидатор работал с чистым HTML
loed, вы всуньте в валидатор хотябы то что написали!