как не надо бы ускорять сайт и ломать базу данных

[sitecreator]

Обратился ко мне  мой старый заказчик.

 

Случилась у него проблема с сервером когда я помочь не мог, ибо болел тогда. Но благо, что специалистов на форуме достаточно, то они и перенесли сайт на новый сервер, ускорили и, вроде бы, от проблем избавили человека.

 

А теперь вот приходится решать массу проблем, возникших после ускорения.

 

Чисто для примера как делалась местами "оптимизация" за счет дополнительных индексов.  Ведь много это не мало?

 

 

 

 

Может быть я что-то не понимаю в новых тенденциях оптимизации?  Может это и есть секрет ускорения?

 

Но это все мелочи, которые на работу магазина не влияют.

тут несколько моментов  более интересные оказались, не позволяющие магазину нормально работать.

 

Не получается товар добавить.  Вылетает белый лист. И никаких ошибок PHP нет.

Поломал я голову.

И оказались две таблицы 'product' и 'product_description'  с разным количеством срок и с разными счетчиками автоинкримента (следующий автоматический индекс product_id).

 

 

Есть бекапы. До переезда бекап БД в порядке.  После переезда (первый же бекап на новом сервере)  БД уже не в порядке (как потом выяснилось).  Откатиться на правильный бекап невозможно, т. к. много изменений было сделано.

 

А появились вот такие метаморфозы:

 

 

 

 

 

 

Были и другие неожиданности.

 

Господа оптимизаторы, вероятно, что не стоит ограничиваться только проверкой скорости генерации главной страницы,  может быть и про другие моменты забывать не нужно?

Как говорил Жванецкий, тщательнЕе надо, ребята.

Змінено 27 березня 2017 користувачем sitecreator

[snastik]

19 минут назад, sitecreator сказал:

Обратился ко мне  мой старый заказчик.

 

Случилась у него проблема с сервером когда я помочь не мог, ибо болел тогда. Но благо, что специалистов на форуме достаточно, то они и перенесли сайт на новый сервер, ускорили и, вроде бы, от проблем избавили человека.

 

А теперь вот приходится решать массу проблем, возникших после ускорения.

 

Чисто для примера как делалась местами "оптимизация" за счет дополнительных индексов.  Ведь много это не мало?

 

 

 

 

Может быть я что-то не понимаю в новых тенденциях оптимизации?  Может это и есть секрет ускорения?

 

Но это все мелочи, которые на работу магазина не влияют.

тут несколько моментов  более интересные оказались, не позволяющие магазину нормально работать.

 

Не получается товар добавить.  Вылетает белый лист. И никаких ошибок PHP нет.

Поломал я голову.

И оказались две таблицы 'product' и 'product_description'  с разным количеством срок и с разными счетчиками автоинкримента (следующий автоматический индекс product_id).

 

 

Есть бекапы. До переезда бекап БД в порядке.  После переезда (первый же бекап на новом сервере)  БД уже не в порядке (как потом выяснилось).  Откатиться на правильный бекап невозможно, т. к. много изменений было сделано.

 

А появились вот такие метаморфозы:

 

 

 

 

 

 

Были и другие неожиданности.

 

Господа оптимизаторы, вероятно, что не стоит ограничиваться только проверкой скорости генерации главной страницы,  может быть и про другие моменты забывать не нужно?

Как говорил Жванецкий, тщательнЕе надо, ребята.

 

Вы как всегда пишите феерично!

 

Во первых - дубли индексов, кроме как на размер базы ни на что не влияют и никоим образом не создают каких-бы то ни было проблем.

Во вторых в таблице product_description нет автоинкрементального поля.

 

Так что судя по всему у вас как и у ваших оптимизаторов, тоже тенденции рулевые.

 

[chukcha]

Наличие одинаковых индексов, действительно ... летают, но низко-низко ( про прапорщика и крокодилов)

 

1. Когда создается/ изменяется индекс к полю?
Только на момент редактирования таблицы
Где таблицы редактируются - в админке

 

2 на момент выполнения оптимизатор выбирает оптимальный индекс - 1 из 2 - это и есть низко-низко (но очень низко)

 

Автоинкремент на _desctiption

 

Это действительно не понятно,

Возможно это могло бы понадобиться для прмого доступа к записи в _description по уникальному ключу, но он и без этого есть _id+language_id

 

Откуда взялись дубли индексов, - просто и понятно
Как ускорить?

Опа - и есть скрипт по добавлению индексов, а че там мучаться, и я добавлю, а посмотреть что они уесть или нет до этого мозгов не хватило

 

И.. тут еще нужно понять а зачем индекс на upc, sort_order (тихо-тихо, не надо эмоций)

 

[RGB]

Больше индексов, хороших и разных! 

[sitecreator]

11 часов назад, snastik сказал:

Во первых - дубли индексов, кроме как на размер базы ни на что не влияют и никоим образом не создают каких-бы то ни было проблем.

 

я где-то писал про проблемы?

 

12 часов назад, sitecreator сказал:

на работу магазина не влияют.

 

лишние индексы были добавлены чуть ли не в каждую таблицу.  объем БД "до" сам по себе и так был немаленький, а тут легко увеличился сразу на несколько десятков Мегабайт.

Вы считаете, что это нормально и так можно и нужно делать?

 

таблицы то тяжелые в Мегабайтах:

 

 

Один из факторов оптимизации за счет сервера БД - это размещение индексов в оперативной памяти. Параметр  key_buffer_size. Или я ошибаюсь?

Разве в этом случае размер индексов не имеет значения?  И лишние десятки мегабайт индексов не помеха?

 

Я не берусь утверждать наверняка,  но рассуждая логически, делаю вывод, что это все же лишнее.

 

5 часов назад, chukcha сказал:

Как ускорить?

Опа - и есть скрипт по добавлению индексов, а че там мучаться, и я добавлю, а посмотреть что они уесть или нет до этого мозгов не хватило

 

Вероятно, что скриптом и было добавлено.   50 Мегабайт дополнительных индексов ни на чем не скажутся? Кеш индексов не разрастется?

 

 

5 часов назад, chukcha сказал:

Автоинкремент на _desctiption

 

Это действительно не понятно,

Возможно это могло бы понадобиться для прмого доступа к записи в _description по уникальному ключу, но он и без этого есть _id+language_id

 

вот тут был сам несколько в недоумении . Но работало безупречно "до" на протяжении лет. А потому убирать не стал.

Сам по себе этот автоинкремент не создает каких-бы то ни было проблем. Пока его не изменить за пределами движка.

Могу предположить, что автоинкремент был добавлен каким -то модулем.

 

[chukcha]

1 час назад, sitecreator сказал:

Один из факторов оптимизации за счет сервера БД - это размещение индексов в оперативной памяти. Параметр  key_buffer_size.

А если они туда не размещаются?

 

Ві реально думаете, что индексы копируются в этот буфер?
А может это все же именно буфер?
Конечно это было бы шикарно, чтоб все индексы туда легли, но!!! А может тогда лучше вообще всю базу монтировать в memory filesystem? 

 

[sitecreator]

20 минут назад, chukcha сказал:

Конечно это было бы шикарно, чтоб все индексы туда легли

 

Хотелось бы.

Как это сделать я не представляю, тут моих познаний недостаточно.

 

Можно ли использовать именованные кеши для индексов конкретных таблиц? Для самых основных и часто используемых. Разве это плохой вариант.  И разве в таком случае этот индекс не будет постоянно в памяти?

 

Я пытаюсь понять почему мне говорят, что раздутый индекс - это ничего плохого.

 

Так а что же в нем хорошего?

"До" был размер индексов 18М, а "после" уже 53М. Производительности дублирующие индексы не добавили.

 

Чего добились этим? Я вижу, что ничего кроме увеличения размеров самой БД.

Змінено 27 березня 2017 користувачем sitecreator

[chukcha]

Сколько у вас там товаров?

Сколько памяти?
Какой размер буфера сейчас?
 

[sitecreator]

@chukcha , 10 000, 1.8Г, 128М

[chukcha]

чисто спортивный интерес

 

SHOW STATUS LIKE 'Key_blocks_unused'

 

[sitecreator]

В 28.03.2017 в 01:31, chukcha сказал:

чисто спортивный интерес