- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добился того, что некэшируемых запросов к БД практически не осталось (то что есть на графике остатки от зеркала сайта на старом движке) но появляется другая проблема..
Кэш удаляется как только в таблице происходит обновление строки или удаление. Например:
- Таблица сообщений соц сети - постоянное добавление/обновление/удаление записей - с ростом посещаемости эффективность кэширования стремится к нулю
- Таблица информации о пользователях - с каждой регистрацией и редактированием данных - кэш очищается.
В итоге - польза от кэша тает на глазах
Как лучше это дело оптимизировать?
кешировать не всю таблицу, а конкретные запросы и выборки поштучно кешировать в мемкешед.
конкретные запросы
только запросы и кэшируются, но при изменении в таблице запросы из кэша удаляются
В итоге - польза от кэша тает на глазах
хм а какая польза от кеша если данные изменились а ваш сайт показывает старые данные из кеша которые не соответсвуют действительности???
если на это наплевать то сделайте две базы - в одной храняться актуальные данные, во второй раз в сутки синхронизированные с первой базой, скрипт будет брать из кеша второй базы и класс - чего хотели того добились
хм а какая польза от кеша если данные изменились
я ж ничё против не имею, просто хотелось бы понять, как оптимизировать работу сервера и движок соц сети, в которой данные постоянно меняются и имеёт первостепенное значение.
так может хранить данные не в mysql, а в MongoDB и т.п., которые сразу все в памяти ?
я ж ничё против не имею, просто хотелось бы понять, как оптимизировать работу сервера и движок соц сети, в которой данные постоянно меняются и имеёт первостепенное значение.
ну соц сеть как и есть динамически меняющийся объект, кешировать который не имеет смысл
ну это как если бы вы на бирже пользовались устаревшими данными
а насчет сервера - если текущая конфигурация не справляется - значит надо модернизировать
---------- Добавлено 10.03.2013 в 00:42 ----------
так может хранить данные не в mysql, а в MongoDB и т.п., которые сразу все в памяти ?
ну так и в мускуле можно сделать таблицы хранящиеся в ОЗУ
ну соц сеть как и есть динамически меняющийся объект, кешировать который не имеет смысл
тупо наращивать железо при росте нагрузки?