Перейти к содержанию
sitecreator

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

Рекомендуемые сообщения

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

 

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

 

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

 

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

 

3b6d93bd5c.jpg

 

 

 

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

 

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

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

 

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

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

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

 

 

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

 

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

 

ec46d5f604.jpg

 

 

b226faa0da.jpg

 

 

 

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

 

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

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

Изменено пользователем sitecreator

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
19 минут назад, sitecreator сказал:

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

 

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

 

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

 

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

 

3b6d93bd5c.jpg

 

 

 

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

 

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

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

 

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

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

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

 

 

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

 

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

 

ec46d5f604.jpg

 

 

b226faa0da.jpg

 

 

 

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

 

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

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

 

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

 

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

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

 

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

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

 

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

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
11 часов назад, snastik сказал:

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

 

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

 

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

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

 

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

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

 

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

 

bf9601f6a7.jpg

 

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

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

 

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

 

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

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

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

 

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

 

 

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

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

 

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

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

 

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 час назад, sitecreator сказал:

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

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

 

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



 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
20 минут назад, chukcha сказал:

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

 

Хотелось бы.

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

 

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

 

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

 

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

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

 

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

Изменено пользователем sitecreator

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

SHOW STATUS LIKE 'Key_blocks_unused'

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
В 28.03.2017 в 01:31, chukcha сказал:

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

 

f448891360.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу

×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.