Jump to content
Sign in to follow this  
sitecreator

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

Recommended Posts

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

 

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

 

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

 

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

 

3b6d93bd5c.jpg

 

 

 

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

 

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

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

 

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

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

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

 

 

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

 

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

 

ec46d5f604.jpg

 

 

b226faa0da.jpg

 

 

 

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

 

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

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

Edited by sitecreator

Share this post


Link to post
Share on other sites
19 минут назад, sitecreator сказал:

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

 

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

 

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

 

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

 

3b6d93bd5c.jpg

 

 

 

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

 

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

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

 

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

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

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

 

 

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

 

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

 

ec46d5f604.jpg

 

 

b226faa0da.jpg

 

 

 

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

 

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

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

 

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

 

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

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

 

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

 

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

 

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

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

 

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

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

 

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

 

Share this post


Link to post
Share on other sites

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

  • +1 1

Share this post


Link to post
Share on other sites
11 часов назад, snastik сказал:

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

 

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

 

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

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

 

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

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

 

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

 

bf9601f6a7.jpg

 

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

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

 

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

 

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

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

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

 

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

 

 

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

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

 

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

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

 

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

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

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

 

Share this post


Link to post
Share on other sites
1 час назад, sitecreator сказал:

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

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

 

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



 

Share this post


Link to post
Share on other sites
20 минут назад, chukcha сказал:

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

 

Хотелось бы.

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

 

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

 

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

 

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

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

 

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

Edited by sitecreator

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

@chukcha , 10 000, 1.8Г, 128М

Share this post


Link to post
Share on other sites

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

 

SHOW STATUS LIKE 'Key_blocks_unused'

 

Share this post


Link to post
Share on other sites
В 28.03.2017 в 01:31, chukcha сказал:

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

 

f448891360.jpg

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
You are posting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.