PHP 5.5

Предложения по новым функциям, улучшениям и др.

PHP 5.5

UNREAD_POST eddi13 » 19.03.2015 13:54:51

Доброе время суток.
тут такое дело, расширение mysql объявлено deprecated
http://php.net/manual/en/migration55.deprecated.php

В связи с этим, хотелось бы поинтересоваться,
есть какие-то планы по смене драйвера?
eddi13
 
Сообщения: 15
Зарегистрирован: 02.10.2012 14:42:47

Re: PHP 5.5

UNREAD_POST zapimir » 21.03.2015 03:07:20

В курсе, что deprecated, но пока работают даже в PHP 5.6, и как показали тесты старое расширение быстрее работает.
Хотя после перехода в PHP на собственные драйвера работа с MySQL стала значительно медленнее. Поэтому сейчас работаем над новым методом бэкапа в котором будет собственный драйвер заточенный под бэкап, там разница вообще может доходить до 10-кратной, особенно на таблицах с большим количеством маленьких записей.
В данном случае дампер будет работать даже, если расширение MySQL в PHP не установлено.
zapimir
Site Admin
 
Сообщения: 1627
Зарегистрирован: 01.10.2009 22:39:52

Re: PHP 5.5

UNREAD_POST eddi13 » 22.03.2015 17:34:37

вау... это круто. сразу не примену спросить) "а когда ждать?"))

дак вот. из чего собственно возник топик.
я когда-то давно встроил в систему бекапер версии 2.0.10, омультиязычил его, и он несколько лет исправно работал (хвала разработчикам! поскольку банк "весит" несколько гигабайт), и вот...
я перевел систему на php5.6, и, так как я из тех, кто логирует нотицы, меня через пару дней утомило читать логи типа E_DEPRECATED: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead
оно конечно работает, но блин...
в общем сегодня, под чешское пивко, я заменил в коде все вождения mysql_* их процедуральными аналогами mysqli_*, ну вот и собственно хочу поделиться результатами тестов.

на чем тестируем:
cpu - intel i7
ram - 8GB
hard - SSD
server - Денвер-3 2012-09-16
apache - Apache/2.2.22 (Win32) mod_ssl/2.2.22 OpenSSL/1.0.1c
php - PHP5.6.6
mysql - 5.5.25
tag - система с mysql_*
branch - система с mysqli_*
ядро вашего дампера не изменено, я дописывал только мультиязычность и привязал к конфигам моей системы

что тестируем:
бекап и восстановление системных таблиц геопака
4 таблицы InnoDB, примерно 18,315,000 записей, в банке занимают 1,8GiB

поехали (извиняюсь за логи на немецком, но думаю что разобраться вполне можно)
tag - система с mysql_*
бекап
2015.03.22 12:44:57 Starte Export der Datenbank `radas_general`
Exportiere Tabelle `systemgeo__coordinates`
2015.03.22 12:44:58 Exportiere Tabelle `systemgeo__postcode_distance`
2015.03.22 12:56:08 Exportiere Tabelle `systemgeo__postcode_midpoint`
2015.03.22 12:56:09 Exportiere Tabelle `systemgeo__regionen_vam_code`
Export der Datenbank `radas_general` beendet.
2015.03.22 13:56:09 Job erfolgreich abgeschlossen
Datensätze: 18315255
Dateigrösse: 102 MB
Laufzeit: 673.3985 Sekunden (11 мин. 12 с.)

восстановление
2015.03.22 13:09:24 Starte Import der DB `radas_general`
Datei: radas_general_2015-03-22_12-44-57.sql.gz
Setze Encoding der Verbindung auf: `binary`
Importiere Tabelle `systemgeo__coordinates`
Importiere Tabelle `systemgeo__postcode_distance`
2015.03.22 13:16:07 Importiere Tabelle `systemgeo__postcode_midpoint`
Importiere Tabelle `systemgeo__regionen_vam_code`
Erzeuge Indizes
DB `radas_general` wiederhergestellt.
2015.03.22 14:16:07 Job erfolgreich abgeschlossen
Datensätze: 18315255
Dateigrösse: 536 MB
Laufzeit: 403.7601 Sekunden (6 мин. 43 с.)

branch - система с mysqli_*
бекап
2015.03.22 12:15:27 Starte Export der Datenbank `radas_general_branch`
Exportiere Tabelle `systemgeo__coordinates`
2015.03.22 12:15:28 Exportiere Tabelle `systemgeo__postcode_distance`
2015.03.22 12:26:58 Exportiere Tabelle `systemgeo__postcode_midpoint`
Exportiere Tabelle `systemgeo__regionen_vam_code`
Export der Datenbank `radas_general_branch` beendet.
2015.03.22 13:26:58 Job erfolgreich abgeschlossen
Datensätze: 18315255
Dateigrösse: 102 MB
Laufzeit: 694.4677 Sekunden (11 мин. 31 с.)

восстановление
2015.03.22 13:01:40 Starte Import der DB `radas_general_branch`
Datei: radas_general_branch_2015-03-22_12-15-27.sql.gz
Setze Encoding der Verbindung auf: `binary`
Importiere Tabelle `systemgeo__coordinates`
Importiere Tabelle `systemgeo__postcode_distance`
2015.03.22 13:08:20 Importiere Tabelle `systemgeo__postcode_midpoint`
Importiere Tabelle `systemgeo__regionen_vam_code`
Erzeuge Indizes
DB `radas_general_branch` wiederhergestellt.
2015.03.22 14:08:21 Job erfolgreich abgeschlossen
Datensätze: 18315255
Dateigrösse: 536 MB
Laufzeit: 400.5259 Sekunden (6 мин. 40 с.)

резюмируем
tag - система с mysql_*
бекап - 11 мин. 12 с.
восстановление - 6 мин. 43 с.
и 6.68KB логов E_DEPRECATED: mysql_connect(): The mysql extension.....
branch - система с mysqli_*
бекап - 11 мин. 31 с.
восстановление - 6 мин. 40 с.

и что в итоге
на мой взгляд реальной разницы по времени нет (чуть проиграли на бекапе, чуть выиграли на восстановлении. при соответствующих объемах данных различия по результатам тестов не играют роли в реальной обстановке), зато минус бессмысленного лога.
т.е. переход на mysqli_* по любому даст только выигрышь

сори за длинный пост.

PS.: моим вариантом поделиться к сожалению не могу, вернее могу конечно, но в этом не будет никакого смысла, поскольку он намертво привязан к моей системе и не будет без нее работать. но могу адаптировать 2.0.11 версию, если для вас будет смысл и разработка новой версии о которой вы пишите "еще так на полгодика" затянется.
если есть принципиальный интерес, напишите в личку. там же и представлюсь, что я тут буду писать кто я и что - неудобно как-то)
eddi13
 
Сообщения: 15
Зарегистрирован: 02.10.2012 14:42:47

Re: PHP 5.5

UNREAD_POST eddi13 » 22.03.2015 18:20:12

тест на линуксе с "боевого" сервера на драйвере mysqli
только бекап, поскольку для теста восстеновления на данный момент нет базы, но мне думается, что в процентном отношении не будет никаки сюрпризов.
2015.03.22 15:14:01 Starte Export der Datenbank `radas_general_6`
Exportiere Tabelle `systemgeo__coordinates`
Exportiere Tabelle `systemgeo__postcode_distance`
2015.03.22 15:16:18 Exportiere Tabelle `systemgeo__postcode_midpoint`
Exportiere Tabelle `systemgeo__regionen_vam_code`
Export der Datenbank `radas_general_6` beendet.
2015.03.22 16:16:18 Job erfolgreich abgeschlossen
Datensätze: 18315255
Dateigrösse: 102 MB
Laufzeit: 138.7846 Sekunden (2 мин. 17 с.)
eddi13
 
Сообщения: 15
Зарегистрирован: 02.10.2012 14:42:47

Re: PHP 5.5

UNREAD_POST eddi13 » 22.03.2015 18:24:26

если еще не пробовали, попробуете чешское пиво Pilsner Urquell - на мой скромный взгляд очень вкусно)
eddi13
 
Сообщения: 15
Зарегистрирован: 02.10.2012 14:42:47

Re: PHP 5.5

UNREAD_POST eddi13 » 22.03.2015 18:49:22

о, сори, тест на линуксе с "боевого" сервера на драйвере mysql
2015.03.22 15:45:58 Starte Export der Datenbank `radas_general_6`
Exportiere Tabelle `systemgeo__coordinates`
Exportiere Tabelle `systemgeo__postcode_distance`
2015.03.22 15:47:56 Exportiere Tabelle `systemgeo__postcode_midpoint`
Exportiere Tabelle `systemgeo__regionen_vam_code`
Export der Datenbank `radas_general_6` beendet.
2015.03.22 16:47:56 Job erfolgreich abgeschlossen
Datensätze: 18315255
Dateigrösse: 102 MB
Laufzeit: 119.796 Sekunden (1 мин. 58 с.)
eddi13
 
Сообщения: 15
Зарегистрирован: 02.10.2012 14:42:47

Re: PHP 5.5

UNREAD_POST eddi13 » 22.03.2015 18:54:08

т.е. оно конечно "быстрее" на старом драйвере... при бекапе... при гигабайтных базах...
eddi13
 
Сообщения: 15
Зарегистрирован: 02.10.2012 14:42:47

Re: PHP 5.5

UNREAD_POST zapimir » 26.03.2015 07:51:40

Извиняюсь за задержку с ответом.
Насколько понимаю вы используете бэкап со сжатием, попробуйте ради интереса сделать без сжатия для сравнения.
Что касается E_DEPRECATED, то это не нотисы, а скорее инфа для разработчиков, и на продакшене обычно отрубают (так как не имеет смысла забивать лог этими сообщениями). Даже в php.ini написано
Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT

Кроме того в дампере же свой обработчик, который сообщения E_DEPRECATED игнорирует, возможно в версии 2.0.10, обработки E_DEPRECATED еще не было. Проверьте есть ли строка
Код: Выделить всё
if($errno == 8192) return;


И насчет драйверов вы не совсем поняли. mysql и mysqli это не разные драйвера, это просто интерфейсы к одному и тому же драйверу. Под драйверами имелись в виду libmysql и mysqlnd (который с PHP 5.4 стал драйвером по умолчанию). Вот там разница значительная при бэкапе была, так как обычно еще включена встроенная статистика mysqlnd.

Но в любом случае по сравнению с новым типом бэкапа с собственным драйвером - это всё тормоза.
К примеру бэкап таблички geonames

Код: Выделить всё
sxd 2.0.11     PHP 5.6    472 МБ    74.75 сек.
sxb raw        PHP 5.6    374 МБ     9.38 сек.


Почитать про новый тип бэкапа и попробовать тестовый скриптик можно здесь
zapimir
Site Admin
 
Сообщения: 1627
Зарегистрирован: 01.10.2009 22:39:52

Re: PHP 5.5

UNREAD_POST eddi13 » 27.03.2015 22:46:35

доброе время суток.
ну вот закончилась неделя и это снова я, с новыми развлечениями aka тестами.
чешское пиво, к сожалению, отсутствует, есть только немецкое, посему буду краток)

на этот раз будет только бекап на локальной win машине (кому интересны параметры самой машины смотрим предыдущие тесты), но дабавился Sypex Backuper (если я правильно угадал сокращение sxb).
т.к. sxb находится в сильно тестовой фазе, будем подстраиваться под него, т.е.:
бекапим 1 таблицу systemgeo__postcode_distance, содержащую ~18млн. записей и занимающую в банке (вместе с индексами) примерно 1,8 GiB
по поводу "драйверов", вы zapimir, безусловно правы, я тестировал в предыдущем тестовом топике api к драйверу, а не сам драйвер, а терминалогия - это все от недостатка образования конечноже. если кого из форумчан ввел в заблуждение - простите гада.
как и просили, все бекапы делались без сжатия. мне, при отсутствии чешского пива, было лениво откатывать svn 2.0.10 системы на старую ревизию, посему mysql API тестировалось на неизмененной 2.0.11.

кандидат 1. Sypex Dumper 2.0.11 на устаревшем mysql API (о, здесть все по русски:))
2015.03.27 18:06:34 Начало экспорта БД `radas_general`
Экспорт таблицы `systemgeo__postcode_distance`
2015.03.27 18:16:48 Резервная копия БД `radas_general` создана.
Задание успешно выполнено
Записей: 18291133
Размер файла: 535 МБ
Времени затрачено: 619.3544 сек. (10 мин. 14 с.)

кандидат 2. Sypex Dumper 2.0.10 на более новом mysqli API (а вот здесь опять по немецки:()
2015.03.27 17:18:03 Starte Export der Datenbank `radas_general`
Exportiere Tabelle `systemgeo__postcode_distance`
2015.03.27 17:28:51 Export der Datenbank `radas_general` beendet.
2015.03.27 18:28:51 Job erfolgreich abgeschlossen
Datensätze: 18291133
Dateigrösse: 535 MB
Laufzeit: 651.0442 Sekunden (10 мин. 48 с.)

кандидат 3. Sypex Backuper на SuperNova (да простят мне разработчики вольность) API
RAW Backup 0:25.208 506 МБ

резюмируем
первые два теста, как и предполагалось ничего нового в результаты предыдущего теста не привнесли, поскольку просто исключены издержки на сжатие файла. mysqldump и OUTFILE не тестил даже, поскольку это для тех кто рисует темплаты "нотиве пхп <?=$value;?> кул, а смарти и кампания говно и тармаза и ваабще есть bush и там все придумана, а vi палюбому лучшия ide пасколку без тармазов".
SuperNova API обогнал все и вся в (щас посчитаю на калькуляторе - (619,3544 + 651,0442) / 2 = 635,1993 / 25,208 = 25,19832196128213) в 25 с хвостиком раз... ну даже не знаю как прокомментировать... "вау" наверное надо сказать в этом месте. даже несмотря на закон неубывающей энтропии (ничто никуда не пропадает. выиграли на бекапе - должны проиграть на восстановлении.) - сколько раз мы бекапимся, и сколько раз и при каких обстоятельствах восстанавливаемся? (тут каждый сам ответит и сможет прикинуть одеяло на себя)

и что в итоге
ну и в итоге .... в реальной жизни ничего не изменилось)
все, кто пользует неизмененный бекапер (насртойки error_reporting) могут спать спокойно! все будет еще пару лет работать. для меня лично, это, к сожадению не вариант, поскольку error_reporting вывернуто в системном BugHandler в "-1", из всех сторонних системе скриптов (в том числе и из вашего естессно) прям нагло в исходниках вырезано управление уровнем вывода ошибок, поскольку версии идут часто, тестеры халявят.... ну вот так я решил. но это моя ситуация, которую я сам себе намеренно создал.
про SuperNova API говорить пока рано - он на данный момент, показывает "красивые циферки в браузере" (у меня после его работы папка backup осталось пустой, но думаю так и задумано). в результате его работы, насколько я понял, в файле будут бинарные данные, с которыми сможет работать только sxb (то, что выдает существующая версия 2.х - есть текстовый файл, который при невозможности работы через бекапер можно помучавшись преобразовать в скрипт пригодный для любого бекапера). т.е. при переходе на sxb получается, что я сознательно должен положиться на вашу компанию в плане поддержки. я никоим образом не хочу сказать ничего плохого о ней, до сих пор только хорошие впечатления основанные на годах использования продукта, но я не смогу развернуть бекап без вашей помощи, если вдруг чего глюкнет. не могли бы вы прокомментировать в этом месте кстати...

вот так вот на сегодня с немецким пивом:) и опять получился длинный пост.

PS.: заьыл совсем. мне не пришло ни одного уведомления на емейл про изменения в топике, несмотря на то, что "Сообщать мне о получении ответа" откликнуто.
eddi13
 
Сообщения: 15
Зарегистрирован: 02.10.2012 14:42:47

Re: PHP 5.5

UNREAD_POST zapimir » 28.03.2015 03:01:02

Спасибо за тест, результат порадовал :)
Насчет того, что раз бэкап стал быстрее - то станет медленнее восстановления. То это не так, даже наоборот, восстановление будет также очень быстрым, поскольку этот формат более удобный для машинной обработки, чем обычный SQL. Кроме того при восстановлении будет использоваться новая техника для максимально быстрой заливки баз (сначала таблицы будут создаваться без индексов, потом быстро заливаются данные, если есть права, то даже с использованием LOAD DATA, а не обычными INSERT, и после этого будут добавлены индексы в таблицы).

Основной выигрыш в скорости из-за того, что мы не используем стандартный драйвер, которому приходится делать слишком много лишней работы. И который рассчитан на построчную обработку данных. Ведь, к примеру, в вашем случае нужно больше 18 млн вызовов функции драйвера достающего следующую строку. Причем строка эта преобразовывается в массив, чтобы потом тут же сделать из него строку и записать в файл. В новом типе бэкапа полученные от MySQL-сервера данные - отправляются сразу в файл без малейших преобразований (потому и название RAW).
Также еще процентов 20 времени уходит на преобразование в человекопонятный вид цифр, поэтому для работы с MySQL мы используем относительно новый бинарный протокол (он появился в MySQL 4.1).
Еще из дополнительных фишек нового бэкапа - дедупликация, инкрементальный и многопоточный бэкап. И шифрование на закуску :)

Насчет красивых циферок в браузере, то файл создается просто в этом тестовом скрипте после создания файла и определения его размера - он удаляется (можно просто закомментировать unlink).

И, да основная расплата за скорость и основной недостаток - это то, что это не будет человекопонятный текстовый файл, хотя сам формат файла планируется сделать открытым, также можно будет сделать сохранение из SXB в SQL-файл. Были мысли использовать TAR или ZIP в качестве контейнеров, но там есть определенные недостатки, которые очень не нравятся. А новый формат затачивается еще под облачные хранилища (если вам нужно восстановить одну небольшую табличку, то не нужно скачивать весь бекап, скачается небольшой кусочек этого бекапа в котором находятся нужные данные). В перспективе формат будет позволять восстановить отдельные строки или отдельные поля.

Собственно поэтому и появилась идея разделения на Dumper и Backuper. Т.е. первый продолжит работать с традиционными SQL дампами, а второй будет работать с новым форматом, и будет бэкапить и базу, и файлы.

P.S. что с извещениями проверю.
zapimir
Site Admin
 
Сообщения: 1627
Зарегистрирован: 01.10.2009 22:39:52

Re: PHP 5.5

UNREAD_POST eddi13 » 28.03.2015 13:01:58

Доброе время суток.
общий смысл понятен, нужен какой.то рабочий прототип.
несколько оффтопный вопрос: шифрование, новый протокол, это все здорово - а как с целостностью данных?

например: есть объект юзер у которого есть коллекция адресов, бекапер забирает таблицу за таблицей, вот он забрал таблицу users.... и в этот момент злобный админ добавляет юзера с 10 адресами, данные записались в обе таблицы... дампер переходит к таблице user_address. ну и при восстановлении из бекапа получаем "сиротские" адреса в user_address, целостность данных потеряна. а есть объекты которые "живут" в 10-15 таблицах.

только холодный бекап? или есть какие-то наработки как при горячем бекапе избежать потери целостности?
eddi13
 
Сообщения: 15
Зарегистрирован: 02.10.2012 14:42:47

Re: PHP 5.5

UNREAD_POST zapimir » 31.03.2015 07:05:37

Для целостности данных делается блокировка таблиц на запись для MyISAM таблиц. Потому, как раз важно максимальное уменьшение времени бэкапа.
zapimir
Site Admin
 
Сообщения: 1627
Зарегистрирован: 01.10.2009 22:39:52

Re: PHP 5.5

UNREAD_POST eddi13 » 02.04.2015 10:14:38

zapimir писал(а):как раз важно максимальное уменьшение времени бэкапа

вы же понимаете что время бекапа не решает проблему, оно только чуть уменьшает ее масштабы (в зависимости от нагрузки на проект).
ну т.е. я так понимаю нет другого решения кроме как холодный бекап (тут я не имею ввиду shutdown, а просто обеспечение недоступности банка на запись).
возможно дурацкий вопрос, а есть в mysql комманда которая блокирует/разблокирует все таблицы банка на запись?
ну или какая процедурка из best practices, так сказать. (таблицы все InnoDB)
eddi13
 
Сообщения: 15
Зарегистрирован: 02.10.2012 14:42:47

Re: PHP 5.5

UNREAD_POST zapimir » 03.04.2015 14:27:41

Вообще в больших высоконагруженных базах, в которых нельзя чтобы были простои, обычно используют репликацию, и бэкап уже делают с реплики. Также если все таблицы в InnoDB то блокировку таблиц не практикуют, рекомендуют использовать бэкап в одной транзакции (single transaction).
Также рекомендуется использовать бинарные логи.
zapimir
Site Admin
 
Сообщения: 1627
Зарегистрирован: 01.10.2009 22:39:52

Re: PHP 5.5

UNREAD_POST eddi13 » 04.04.2015 17:24:59

single transaction использует mysqldumper
вы предлагаете отказаться от вашего софта?)
eddi13
 
Сообщения: 15
Зарегистрирован: 02.10.2012 14:42:47


Вернуться в Предложения

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

Яндекс.Метрика