- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Вчера вот 1 террабайт был занят
Вы не правильно читаете данные, нельзя занять 1 терабайт оперативной памяти при всего 64 Гб её наличия
вы не видели сайт чтобы утверждать это. Там миллионы страниц.
Вы опять не правильно прочитали, на тех цифрах видно что у меня 90% попаданий в кеш, в данном случае вам кеш работает в минус вашему сайту, так как он работает примерно так у вас:
1. Идем в мемкеш, мимо (miss)
2. Выполняем полезную нагрузку
3. Пишем в мемкеш данные
В вашем случае 1 и 3 пункт просто грузят лишний раз сервер. Хотя если у вас 3 пункта нет от туда и столько промахов, но тогда вы грузите просто первым пунктом. В общем код кривой
Вы не правильно читаете данные, нельзя занять 1 терабайт оперативной памяти при всего 64 Гб её наличия
это опечатка, конечно же 1 Гб я имел ввиду.
Вы опять не правильно прочитали, на тех цифрах видно что у меня 90% попаданий в кеш, в данном случае вам кеш работает в минус вашему сайту, так как он работает примерно так у вас:
в данном случае вам кеш работает в минус вашему сайту
наличие хоть одного закешированного запроса это уже плюс, не понимаю о чем вы.
наличие хоть одного закешированного запроса это уже плюс, не понимаю о чем вы.
Наличие кеша к которому не обращаются это уже минус.
а если запросы в базу данных разные и их очень много?
То их нет смысла кешировать. База и так работает хорошо, при наличии индексов и достаточного свободного количества памяти она так же будет оперировать данными в оперативке, перекладывать из оперативки одни и те же данные в разные ячейки не совсем эффективно. Но хозяин барин, я лишь вам указываю на проблему на которую следует обратить внимание.
PS. Если у вас просто статьи, сложите их в статический кеш nginx, он работает очень эффективно и намного лучше
То их нет смысла кешировать.
ну, как это нет смысла. Тут надо понимать какую нагрузку создает запрос к базе данных и сравнивать с записью в кеш, что не сопоставимо. И пусть эффективность кеша будет да хоть 5% - это уже польза
я понимаю что это косо криво на уровне запросов, но если смотреть на это практически, то пусть лучше так чем совсем без кешая понимаю что это косо криво на уровне запросов, но если смотреть на это практически, то пусть лучше так чем совсем без кеша
А сделать чтоб было нормально как вариант я так понимаю не рассматривается? =)) Я же не говорю что надо отказаться, я говорю что у вас проблема в том что кеш промахивается сильно много это надо исправлять в любом случае
их нет смысла кешировать.
Я за кеширование:
- требующих вычислений, но не требующих частых обновлений блоков HTML
- результатов тяжелых запросов к БД или обращений к API
- результатов медленных разборов, валидации и коррекции каких-нибудь XML или JSON
В случае редко меняющегося текстового контента на одном языке вообще сложно представить что может пойти не так. Может быть дело в особенностях/баге конкретного экземпляра приложения. Либо 1 GiB слишком мало.
Перед использованием кеши желательно прогревать простым скриптом, чтобы не создавать записи по одной во время работы. Загрузив первую тысячу записей и посмотрев статистику можно оценить сколько RAM потребуется для полного кеша, а затем прогреть до 90% доступной памяти выборкой самых нужных статей. Например, сотней тысяч самых новых.
А сделать чтоб было нормально как вариант я так понимаю не рассматривается? =)) Я же не говорю что надо отказаться, я говорю что у вас проблема в том что кеш промахивается сильно много это надо исправлять в любом случае
что сделать нормально? закешировать миллион запросов на террабайт?
И пусть эффективность кеша будет да хоть 5% - это уже польза.
Какая у вас версия DLE? Разработчикам обращались?