- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
доброго времени суток,
есть сайт с большим трафиком.. при получении инфы на сайте к одной и той же таблице идут частые обращения.
таблица содержит описания продуктов, где одно поле, содержащие собственно описание, сериализировано
владелец требует оптимизировать приложение и предлагает вместо этой таблицы использовать временную, где сериализированные данные
будут уже unserialized и разнесены по полям
вопрос: оптимально ли такое решение? какой максимальный "позволительный " размер временной таблицы? какие еще лучшие способы оптимизации?
Если владелец такой умный, то почему сам не напишет?
Что-то вы не с того конца подходите, похоже. Ну будет чуть побыстрее. Расход памяти поменьше.
так вот и жду совета, с какого конца подойти
так вот и жду совета, с какого конца подойти
без сериализации никак ? я бы сделал подтаблицу с связкой Наименование : Значение, и привязал это к товару, это и искать удобней и фильтр удобней строить и быстрее будет, так как парсить стрингу это сложней по любому.!
1. Найти узкое место.
2. Устранить.
3. Перейти к пункту 1.
OReIlly.High.Performance.MySQL.Second.Edition.Jun.2008.eBook-DDU.pdf
OReilly.High.Performance.Web.Sites.Sep.2007.pdf
На русском можно найти кусочки-советы, но нигде они не сложены в одну книжку.
Понимаю, что звучит издевательски, но тут либо вы платите, либо теряете время изучая литературу и практические приемы. Вы сейчас источник нагрузки даже не локализовали. Большинство советов будут бесполезны.
1. Найти узкое место.
2. Устранить.
3. Перейти к пункту 1.
OReIlly.High.Performance.MySQL.Second.Edition.Jun.2008.eBook-DDU.pdf
OReilly.High.Performance.Web.Sites.Sep.2007.pdf
На русском можно найти кусочки-советы, но нигде они не сложены в одну книжку.
Понимаю, что звучит издевательски, но тут либо вы платите, либо теряете время изучая литературу и практические приемы. Вы сейчас источник нагрузки даже не локализовали. Большинство советов будут бесполезны.
"нагрузки даже не локализовали" = тут и так все понятно ! они стрингу парсят!, когда можно просто запросом.
без сериализации никак ? я бы сделал подтаблицу с связкой Наименование : Значение, и привязал это к товару, это и искать удобней и фильтр удобней строить и быстрее будет, так как парсить стрингу это сложней по любому.!
сайт мультиязычный
в принципе сериализацию можно убрать, но нужно разбить одну большую таблицу по языкам
например один товар имеет 20 записей на разных языках
вопрос - что лучше использовать 20 временных таблиц для каждого языка и обновлять их как cron job периодически (как предлагает владелец), или все-таки обычные таблицы (не временные)
А не проще ли прикрутить обычное кеширование, чтоб вообще не дергало мускул?
сайт мультиязычный
в принципе сериализацию можно убрать, но нужно разбить одну большую таблицу по языкам
например один товар имеет 20 записей на разных языках
вопрос - что лучше использовать 20 временных таблиц для каждого языка и обновлять их как cron job периодически (как предлагает владелец), или все-таки обычные таблицы (не временные)
Тип записи - язык сделайте просто и все.
AlienZzzz добавил 11.03.2009 в 16:00
А не проще ли прикрутить обычное кеширование, чтоб вообще не дергало мускул?
Мем кеш норма я думаю . но не кашерно . при изменении товата например.
Тип записи - язык сделайте просто и все.
сейчас именно так и есть
например товар А имеет 20 записей в таблице, каждая соответствует языку
для пользователей, например , Италии, предлагают создать таблицу только с итальянскими описаниями и т.п., чтобы каждый раз не дергать одну таблицу
Мем кеш норма я думаю . но не кашерно . при изменении товата например.
Недавно делали кеширование для интернет магазина, прикрутили простейшее кеширование на php для страниц списка товара, нагрузка на сервер упала очень сильно, собственно vds падал намертво (5к товаров, почти 10к просмотров в сутки было), после прикрутки кеширования нагрузка упала до нуля. А при смене товара - не проблема обнулять кеширование.