- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Перешли на сфинкс, не спасает.
Это как Вы так перешли на сфинкс, что база все-равно под нагрузкой?
Основная нагрузка не от поисковых запросов... Даже главная страница, либо страницы просмотра тем бывает грузятся по 10 секунд...
Ну так покажите тогда запросы с главной... Вообще, надо смотреть структуру главной, наверняка можно многие вещи кешировать.
Если LIKE остался, тогда что переехало на сфинкс?
p.s. ещё есть поиск от яндекса/гугла..
Основная нагрузка не от поисковых запросов... Даже главная страница, либо страницы просмотра тем бывает грузятся по 10 секунд...
Когда сервер безбожно тупит, там уже все тормозит, тк ресурсов в целом нет. И получается вроде как не от них, а начинаеться все с них.
А кешите по времени на сколько?
Для неавторизованных я бы страницы целиком подкешил, даже к базе бы не успевал цепляться. На коннект тоже ресурсы надо.
LIKE не кешируется при любом раскладе. Этот запрос не ускорить, меняйте механизм поиска.
Это как Вы так перешли на сфинкс, что база все-равно под нагрузкой?
Сфинкс отдает ID найденных документов, после чего из базы выгребается контент по этим ID,
Сфинкс отдает ID найденных документов, после чего из базы выгребается контент по этим ID,
Но ведь в запросе у вас перечисляются не ИД документов, а ИД форумов.
WHERE t.forum_id IN (39
не перешли вы на sphinx, не перешли.
Основная нагрузка не от поисковых запросов... Даже главная страница, либо страницы просмотра тем бывает грузятся по 10 секунд...
Эта формулировка вообще вызывает недоумение. Ну дадут вам в очередной раз совет "нужно найти наиболее медленные части форума и заняться их оптимизацией", но ведь это же очевидно. Какого рода ответ вы ожидали? Нет ни никакой секретной ускоряющей технологии, которую бы все скрывали. Разделяйте, замеряйте, оптимизируйте.
Кто-то может заикнуться про кеширование, но с такими форумами вообще принципиальная беда - там кешировать почти нечего. Все очень специфично из-за всяких там личных юзерских данных типа списков игнорирования. Впрочем, для vbulletin подобные продукты все равно есть, но на searchengines.ru почему-то больше не видно упоминания об их использовании. Раньше было.
ipb_posts - отсюда вроде должны быть документы, вы же в топиках ищете а потом в постах уже, можно же сразу посты найти
ipb_posts - отсюда вроде должны быть документы, вы же в топиках ищете а потом в постах уже, можно же сразу посты найти
Скрипт ищет с топиках, либо постах в зависимости от установленного чекбокса "Искать только в названиях тем"... Но суть не в этом, интересуют альтернативные способы хранения данных, кроме MySQL...
На чем работают такие гиганты как Вконтакте, Твиттер, и т.п... ? У них базы по миллиарды записей, и моментальный поиск (например по #хеш-тегу в твиттере...)
У Вконтате вроде своя база на Сях c и разные навороты сверху.
У Вконтате вроде своя база на Сях c и разные навороты сверху.
возможно, но еще пару лет назад выловил ошибку "too many connections" от mysql на страницах вк...