С "читайте также" разобрался, через пару дней сравню среднюю нагрузку с прошлым периодом.
Грубо говоря 5000 страниц по 20 постов на страницу дают то самое значение индекса из запроса. У меня свой лог медленных запросов, включающий время запроса, адрес запрошенной страницы, сам запрос и еще много чего. В нем полно подобных запросов для больших номеров страниц т.е. больших значений индекса.
Практика показывает что это не так. Возможно из-за прохода по большому файлу с записями переменной толщины.
индекс id и категория - все по чему делается WHERE.
А в чем прикол? Все равно идет чтение индексов из таблицы с динамическим размером записи, а потом по этим индексам подтягиваются остальные поля.
Из базуки по воробьям... Обычный поиск по сайту, зачем там сложные поисковые движки.
Это не главное, я изначально говорил о подборе похожих новостей по теме.---------- Добавлено 03.10.2015 в 15:50 ----------Еще один вопрос, позволю себе задать тут же, хотя тема другая.
В каждой категории идет постраничный вывод новостей от новых к старым. Как уменьшить время запросов вида
для очень больших номеров страниц?
Ну сейчас AUTO_INCREMENT=423210, раньше помню когда было 200к записей. Не помню когда именно менял алгоритм, возможно как раз когда было 200к.
Хостинг врядли. Двиг писался больше 6 лет назад, опыта было мало, хостил на хостинге за $1 в месяц. Когда меня оттуда турнули за нагрузку пару лет назад я перебрался сразу на VPS - база загнулась за пол часа после переезда, после чего я все максимально оптимизировал что мог. На серваке еще ресурсы есть, кроме этого сайта там еще несколько, при этом нагрузка CPU не 100%. Не думаю что нужно менять хостинг.
Единственное что я пока не понимаю - раньше было 10к в сутки посетителей, но с начала года Яндекс что-то мутит и с февраля у меня 1-2к, а тормоза жестче стали.
ОК, так и думал что нужно результаты поиска кешировать на скажем пару суток, чтобы новые статьи в "похожие" добавлялись, но поиск шел по индексам и нагрузка была меньше. Для самой статьи нет, только в отдельную таблицу. Просто очень не хочу делать теги как в DLE - мне такая реализация не нравится.
Поиск от Яндекса ерунда, чтобы он был актуален нужно быстрое попадание в индекс чего сейчас нет.
Указанную статью когда-то читал, половина из этого уже применяется.
Вот это поворот, уже распознавание запилили. А я то думаю как чурки пристроились обходить антибот и спамить... Уже думал рекапчу взломали.
Давно пора, есть нормальные варезники а есть такие что затроянивают машины всякими лоадерами и прочей гадостью. Не помешает если их не будет на первых страницах.
Собственно я это и писал в 1-м посте. Просто слишком уж много мануалов, рекомендующих MySQL.
Чего не знал того не знал. И сколько ее хранится в ОЗУ? А если файлов-сессий столько что mc через putty прорисовывает директорию несколько минут? (была реальная ситуация)? Думаю в кеше будут только последние файлы, причем в кеше жесткого диска.
Из всего выше сказанного я понял что наиболее удачный вариант при работе 1го сервера - файлы, желательно на ram-диске.
Для кластера из нескольких серверов, которые должны пользоваться общими сессиями, это MySQL таблица типа MEMORY.
Я переносил UCOZ на DLE - в базе была таблица соответствий старых и новых адресов, редирект работал с пол года потом я его дропнул.
Это если нельзя по маске как-то автоматизировать
Может конкуренты накручивают ботами для того чтобы поднагадить?
Проанализируй рефереры и IP по логам веб сервера
Поняли в принципе, правильно. Отображение будет списка, критериев выбора, скорее всего, будет много, текстовые описания будут подгружаться только в отдельных случаях. Возможно, для части списка скриптом будет собираться массив ID и отдельным запросом вытаскиваться описания записей с этими ID, либо после действия пользователя запрашиваться описание одного элемента списка
SocFishing, не, пока обойдусь без шардинга и репликации, вот если реально будет высокая нагрузка - тогда уже подумаю. В связи с тем что почти все данные будут храниться в БД и большинство запросов - чтение, узким местом будет либо БД либо скорость диска, там можно будет сделать репликацию между парочкой VPS и коннектиться к рандомному mysql серверу из списка. Или анализировать нагрузку и переключать с одного на другой коэфициентом, теория вероятностей и все такое... Пока все не настолько запущено.
Вот это я хотел услышать. Значит, смысл есть
