Opencart mysql
КАК СДЕЛАТЬ BACKUP И RESTORE БАЗЫ ДАННЫХ MYSQL ДЛЯ OPENCART ИЛИ ДРУГИХ CMS
Многие начинающие веб мастера часто задаются вопросом, как сделать резервную копию базы данных сайта. Всё очень просто! для этого необходимо зайти в панель управления вашего хостинга, зайти в раздел баз данных и выбрать вход в базу данных через phpMyAdmin. Как это делается, я не буду описывать, по тому как на каждом хостинге это делается по разному.
***
***
***
После входа в phpMyAdmin Вы увидите перечень Ваших баз данных. Выбираем нужную базу данных кликая по ней мышкой. После чего выбираем вкладку «Экспорт» и кнопку «Ок», как показано на картинках. Сохраняем файл на локальный диск в нужную вам папку. Сохранится файл, имя которого будет названием базы данных и с расширением sql.
Как же теперь восстановить базу данных их файла, для чего-то же бы делали бекап базы, Все очень просто! Точно так же выбираем базу данных в списке с левой стороны, только на этот раз выбираем вкладку «Импорт». На открывшейса вкладке надо выбрать файл загружаемого образа базы данных Вашего сайта, выбрать его кодировку и нажать кнопку «Ok».
Как определить какую надо выбрать кодировку. Если вы делаете восстановление базы данных для OpenCart, то можно мело выбирать кодировку UTF-8. А если вы делаете востановление базы данных сайта работающего на каком-то другом движке, то кодировку базы данных можно посмотреть в самом образе базы. Откройте образ базы данных в текстовом редакторе, таком как Notepad++ или блокнот. в строчке, примерно с порядковым номером 12-ть будет вот такая запись /*!40101 SET NAMES utf8 */; тут явно указано что, что образ базы данных находится в кодировке UTF8/
myplugin.ru
КАК СДЕЛАТЬ BACKUP И RESTORE БАЗЫ ДАННЫХ MYSQL ДЛЯ OPENCART ИЛИ ДРУГИХ CMS
Многие начинающие веб мастера часто задаются вопросом, как сделать резервную копию базы данных сайта. Всё очень просто! для этого необходимо зайти в панель управления вашего хостинга, зайти в раздел баз данных и выбрать вход в базу данных через phpMyAdmin. Как это делается, я не буду описывать, по тому как на каждом хостинге это делается по разному.
***
***
***
После входа в phpMyAdmin Вы увидите перечень Ваших баз данных. Выбираем нужную базу данных кликая по ней мышкой. После чего выбираем вкладку «Экспорт» и кнопку «Ок», как показано на картинках. Сохраняем файл на локальный диск в нужную вам папку. Сохранится файл, имя которого будет названием базы данных и с расширением sql.
Как же теперь восстановить базу данных их файла, для чего-то же бы делали бекап базы, Все очень просто! Точно так же выбираем базу данных в списке с левой стороны, только на этот раз выбираем вкладку «Импорт». На открывшейса вкладке надо выбрать файл загружаемого образа базы данных Вашего сайта, выбрать его кодировку и нажать кнопку «Ok».
Как определить какую надо выбрать кодировку. Если вы делаете восстановление базы данных для OpenCart, то можно мело выбирать кодировку UTF-8. А если вы делаете востановление базы данных сайта работающего на каком-то другом движке, то кодировку базы данных можно посмотреть в самом образе базы. Откройте образ базы данных в текстовом редакторе, таком как Notepad++ или блокнот. в строчке, примерно с порядковым номером 12-ть будет вот такая запись /*!40101 SET NAMES utf8 */; тут явно указано что, что образ базы данных находится в кодировке UTF8/
myplugin.ru
Тормозит Opencart. Часть 12 (Mysql Innodb конфиг сервера и подбный шаманимз)
Как обычно сделаю небольшое отступление в прошлое.
Вопрос оптимизации магазинов у нас стал первый раз лет 5 назад, когда была амбициозная идея сделать большой супермаркет, но как то проект не выгорел, а наработки появились.
Тут бы хотелось еще раз подчеркнуть один момент. Сейчас все смотрят в Gmetrix или в PagespeedInsights и тычут пальцем — вот.. Хочу болшую оценку. Товарищи. Оценки этих сервисов зависят на 80% от настройки отдачи статики. Включил сжатие-кеширование. Уменьшил качество картинок и готово. От этого ваш магазин сука менее тупым не станет. И если страница грузится у вас 5 секунд. Но Gmetrix показывает 70. Покупать больше у вас не станут. Покупателям похуй на оценки этого сраного метрикса. Они не хотят тупить по полчаса в ожидании когда же ценный товар явится перед их взором. Так что в первую очередь надо снижать скорость загрузки контента, а потом надрачивать на циферки Gmetrixа.
Когда мы начали задаваться вопросом скорости работы магазина — нам под руку сначала попался модуль PageCache, который давал потрясающие казалось бы тогда результаты. Но на вторую загрузку страницы. Первичная все равно была тупая — но это тогда был прорыв. (аналог гавнобуста)
После этого я наткнулся на индексы в базе данных и это было следующим прорывом. (индексы кстати по ссылке выложены не все) и для совсем уж быстрой работы магазина их недостаточно, скажем так — там вводная, чтобы было понятно куда копать.
Потом был модуль Turbocache, который отлично снижал остаточную нагрузку, еще больше разгружая базу и двигался я в правильном направлении.
В какой то момент казалось бы я знаю и понимаю все. Но попался магазин на 700 000 товаров. И индексов, кешей и вырезания задротных элементов кода по живому оказалось мало. В бой пошел бубен и тюнинг сервера MySql. К сожалению это индивидуальный процесс, доступен он только владельцам выделенных серверов или VPS-VDS, и описывать его детально я не буду, так как с одной стороны информации в интернете об этом завались.Почему нужно настраивать сервер. По умолчанию хостер вам выдает голую систему, в которой все настройки по дефолту. У вас может быть хоть 150 гигабайт оперативной памяти. Но когда вы засетапили какой нить Centos, сервер MySql в нем сконфигурирован таким образом, что эти 150 гиг он не увидит, а будет использовать очень ограниченный минимум. И ваш десятый разработчик по класике будет ныть — сервер гавно, база данных гавно, опенкарт гавно — и я наверное сольюсь ищите другого. Правильный ответ в такой ситуации — разработчик ты сам гавно верни бабки.ПОЧЕМУ Я НЕ НЕ РЕКОМЕНДУЮ НАСТРАИВАТЬ СЕРВЕР САМОСТОЯТЕЛЬНО.Ну тут где то как в ситуации со стоматологом. Всем понятно что дырку надо высверлить и замазать, но почему то никто не делает этого сам а идет к специалисту. Вот со стоматологами всем понятно, а в сервер желающих залезть хоть отбавляй. Здесь лучше доверится на 100% опытному администратору Linux или хотя бы специалисту по настройке баз данных.
После наших успехов, начали как грибы появляться всякие приблуды. Бусты, хуюсты, лайтнинги, даже по моему тупорылый Вася Биба высирал какую то ебалу оптимизирующую. Каждый ебливый студент, посчитал себя обязанным стать крутым спецом в ОПТИМИЗАЦИИ магазина. Про итоги работы одного такого студента можете почитать здесь. Но не можешь срать — не мучай жопу. Спасибо тебе Борис Иваныч. Борис Иваныч — это собирательный образ моих преподаваталей по базам данных микропроцессорной технике и программированию.
Если все же кто то захочет полезть настраивать сервант mysql — попробую объяснить основную задачу. Mydsql — это пиздец быстрая штука. Кастрированная от лишнего хлама, лишенная детских болезней и дубовая. Для того чтобы ваша база данных работала быстро необходимо 2 вещи : 1 — ее правильная архитектура — читаем про индексы, 2 — наличие достаточного количества оперативной памяти, чтобы сервер баз данных не обращался к диску. Один раз таблицы прочитал, поместил в кеш в память и оттуда дальше с ними работает. Памяти должно хватать на все. На построение-перестроение индексов, на хранение временных результатов, вобщем практически на все операции. Как только сервер обратился к диску — все пиздец. Все втухло. И тут начинается цепная реакция. Если у вас производилась операция записи в таблицу oc_product к примеру. Таблица заперлась на чтение. Пока записывается обновление количества просмотров товара, все остальные процессы не могут прочитать из этой таблицы ничего и магазин залипает и превращается в инвалида.
И еще немного про конфиг. Если вы правильно все настроили. mysql отлично кеширует и хранит результаты запросов. А встречал упырей, которые делали драйвер подключения к базе с кешированием. Который сначала давал вроде неплохие результаты, а потом вешал все под 0. И почему. Многие думают. что вот бля у меня 100 человек нихера нет нагрузки — а вот хуй товарищи, боты не спят, и хуярят как полоумные. Особо отличается бинг бот. Который ебанутый на всю голову и может зайти на 100 страниц одновременно. Правильно настроенный Crawl-delay — наше все. А вот теперь представим. Что у нас на неоптимизированном магазине на страницу приходится 200 запросов. Зашли боты и посмотрели 1000 страниц магазина. Что в итоге получим ? В хлам засранную папку с кешом. Благодаря модулю кеширования запросов. И все.. ХАНА…. Почитайте про ограничения на максимальное количество файлов в папке в линуксе и про то как снижается производительность. Большим дебилизмом, чем кешировать по одному все запросы может быть только преобразования таблиц в InnoDb — и вот про это ваще ща подробно расскажу.
Выкатили мне давеча магазин. Симптомы классические. Блюет, понос, температура. Страницы грузятся по 10 секунд и то первые 2 минуты после полной перезагрузки сервера. 8 Гиг забиваются в хлам. Ну я по накатанной. Базу прошустрил, кучу хламушных виртуалхостов поотрубал. Конфиг серванта прописал. Все работает 2 минуты и вата.
Ковырялся ковырялся и взору моему предстает ебать-молотить чудо. Какой то сука умник перевел все таблицы из MyIsam в InnoDb. Я как то встречал приблуду, которая делает этот понос. Один ебанашка у нас на форуме за нее даже был забанен, так как с пеной у рта орал, что это полезно и нихера не слушал папу — что это гавно на постном масле. Аргументы у него следующие. Мол InnoDb поддерживает транзакции на уровне сервера, там лучшая сохранность данных. Она более быстрая. Все это отлично. При одном условии. База и код движка должны быть спроектирована под этот тип таблиц (как в той же Magento). А тут не вникнув в процесс какие то умники нахуевертили с мыслями — а ща вот так клац сделаем будет, я читал — это же ахуенно. А не тут то было. Во первых сразу — прощай поиск по описаниям товаров, так как InnoDb не поддерживает полнотекстовые индексы (не пишите в каментах что с версии MySql 5.6.4 поддерживает — я это и без знаю) Но не у всех есть возможность жонглировать версиями MySql. Во вторых. Везде написано с операциями на чтение данных MyIsam работает быстрее. В третьих. Если вы ждете защищенных транзакций — а это как раз самое главное достоинство InnoDb. То хер на блюде. В Opencartе в коде нет ни намека на использование этих методов. А тут как говорится нет ножек, нету шоколадки. Так что перспектива использовать тип таблиц InnoDb для Opencart видится мне весьма и весьма сомнительной. С таким же успехом, можно гандон на голову одеть и надеятся, что он спасет от триппера.
И вот вижу я что у нас везде InnoDb, смотрю в лог а там, — там тадам. Плодящиеся незавершаемые процессы убивают нахрен сервер. Меняем это дело на MyIsam, меняем драйвер подключения базы данных с обычного старого Mysql на Mysqli и вуаля, тадам, фанфары. Пляшем и танцуем. Все работает, нагрузка на сервере упала с 99% загрузки процессора до 4-6%. Все довольны. Магазин летает, глубина просмотров увеличилась, покупатели не уходят к конкурентам. И не надо разорятся на очередной «мощнее» сервер как в Пентагоне. Это все красиво звучит и быстро читается, но реально убитые три ночи в поисках затыка.
И еще… Любители парсеров заполонили все. На каждом первом сервере в конфиге PHP вижу time_limit = 99999, memory_limit = 512. Товарищи вы как то поаккуратней. Выжираете все ресурсы парой процессов — и все.. Дальше все не едет. Ограничивайте ресурсы для php минимально необходимыми. А если надо запарсить — делайте это ночью Ручками тайм лимит увеличили, так же ручками после этого убрали назад.
То же самое касается max_upload_file_size и max_post_size. Залили базу. Верните обратно. А то придут злые хацкеры, нагрузят вам в папку Download разных ништяков и будете судорожно искать куда делось все свободное место.
Хуйнаныр
(14)Очко
(0) ocshop.info
