- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Узкое место - работа с БД, сервер держит 20 тыс однотипных запросов к разным строкам БД в секунду, если больше то сервер не справляется, и
обычно используют кеширование вместо наращивания железа. Я представляю себе 2 вида такого кеширования:
1. если строки в БД не менялись, то значения берутся из кеша (обычно оперативки)
2. если считать что первый вариант не прокатит, потому что поля меняются или еще почему-то, и нужно все запросы реально направлять на MySQL
сервер, то в этом случае можно собирать запросы в куски и делать меньше запросов select к БД, т.к. они выполняются быстрее чем много мелких.
Вопрос такой: где уже реализовано кеширование второго типа (может оно уже встроено в memcashed или что то другое надо юзать, подскажите) ?
ты гуглил? если не нашел с ходу, возможно кеш второго типа просто неэффективен чтобы его широко использовали на практике и информация о подобном решении не гуглится.
обычно используют кеширование вместо наращивания железа
только в голубых мечтах поисковых оптимизаторов, в условиях когда все посетители приходят с гугла. для классических приложений бд - наоборот.
Шардинг пробовал?
сервер, то в этом случае можно собирать запросы в куски и делать меньше запросов select к БД, т.к. они выполняются быстрее чем много мелких.
Насколько я понимаю, конкретно, в случае mysql это в корне неправильный подход, это ж Вам не оракл. Тут наоборот, сложные запросы нужно дробить на множество мелких и их скармливать mysql-ю - это оптимальнее.
обычно такое пишут сами, если не используется framework, где это уже есть.
довольно просто реализовать подобное, просто нужно время и анализ.
можно использовать mysql-proxy с кэшем, начало здесь - http://blog.danielhlockard.com/?p=103
исходники здесь и еще есть местами - https://github.com/clofresh/mysql-proxy-cache
для обработки множества простых запросов в секунду на mysql можно использовать Handler Socket, он идет в комплекте со сборкой от перконы