Собственно я это и писал в 1-м посте. Просто слишком уж много мануалов, рекомендующих MySQL.
Чего не знал того не знал. И сколько ее хранится в ОЗУ? А если файлов-сессий столько что mc через putty прорисовывает директорию несколько минут? (была реальная ситуация)? Думаю в кеше будут только последние файлы, причем в кеше жесткого диска.
Из всего выше сказанного я понял что наиболее удачный вариант при работе 1го сервера - файлы, желательно на ram-диске.
Для кластера из нескольких серверов, которые должны пользоваться общими сессиями, это MySQL таблица типа MEMORY.
Я переносил UCOZ на DLE - в базе была таблица соответствий старых и новых адресов, редирект работал с пол года потом я его дропнул.
Это если нельзя по маске как-то автоматизировать
Может конкуренты накручивают ботами для того чтобы поднагадить?
Проанализируй рефереры и IP по логам веб сервера
Поняли в принципе, правильно. Отображение будет списка, критериев выбора, скорее всего, будет много, текстовые описания будут подгружаться только в отдельных случаях. Возможно, для части списка скриптом будет собираться массив ID и отдельным запросом вытаскиваться описания записей с этими ID, либо после действия пользователя запрашиваться описание одного элемента списка
SocFishing, не, пока обойдусь без шардинга и репликации, вот если реально будет высокая нагрузка - тогда уже подумаю. В связи с тем что почти все данные будут храниться в БД и большинство запросов - чтение, узким местом будет либо БД либо скорость диска, там можно будет сделать репликацию между парочкой VPS и коннектиться к рандомному mysql серверу из списка. Или анализировать нагрузку и переключать с одного на другой коэфициентом, теория вероятностей и все такое... Пока все не настолько запущено.
Вот это я хотел услышать. Значит, смысл есть
Вроде должен...
Сделал правило как написали тут - все равно количество запросов равно количеству строк в логе, запрашивает каждый раз
Так много сайтов завернуты через CloudShare и никто не знает как быть как застаить его кешировать у себя файлы?
Практика показала что боты пройдут любую капчу.
Можешь попробовать новую рекапчу внедрить где выберите картинки с вермишелью. ИМХО надо ставить на ботов растяжки. Например, картинка, используемая в шаблоне, выставляющая в сессию флаг что это не бот - тогда пройдут только те боты, которые сделаны на базе браузерных ActiveX
а wp-login.php переименовать не? И правило в nginx прописать чтобы wp-login не доходил до бекенда, а отдавался как статическая страница?
у меня на админку джумлы налетали так что хостер присылал сообщения о превышении CPU и угрозы блокировки аккаунта
У меня один сайт несколько лет как забанен в Яндексе, с безуспешными попытки вывести (контент не уникальный) я в конце концов чтобы снизить нагрузку забанил Яндекс бота, а также MJ12 и еще несколько контор.
Что касается бинга - никогда с него на русскоязычный сайт серьезного трафа не видел
