Игорь Воротнёв, у меня по всей видимости была какая то версия mySQL 8 не стабильная, сейчас специально чтобы доказать свою правоту - установил версию из homebrew стабильную (8.0.13), даже чуток быстрее грузится. Скачет от 60 до 80 млс, так что по всей видимости так просто попалась версия в моих тестах, видимо разницы реально нет.
Игорь Воротнёв, какой конфиг mySQL вы используете для WP? из дефолтных оптимизирую только пул сайз для inno и размер буфера и еще пару мелочей. В 2 раза там обратно, но в целом разброс нормальный, 70-100 млс (ответ сервера) на 10.3 MariaDB (php 7.2 + OPCache) vs 120-170 млс на mySQL 8.0 (с тем же конфигом php). Это на голой базе, на базе с 50к страниц разброс примерно такой же получается, особого прироста нет. Точнее не могу сказать версии, всегда использую mariaDB, а то было случайно установил mySQL 8 и офигел от скорости работы сайта, на локалке всегда быстрее было, а тут медленнее чем с сервера грузится...
Игорь Воротнёв, я о реализации, это э отдельный форк от mySQL разработки, тестил лично mySQL (официальный форм, версия 8) VS MariaDB (форк, версия rock или myrock) - на локалхосте даже в 2 раза быстрее и это на голой инсталляции WP
Роман, да тут ничего и не придумать больше) Заказчику делать форму с нуля и заморочки с платными SSL на компанию - было дорого, а более дешевого варианта просто нет) Все обдумал)
Роман, нет, с РФИ переговоры велись очень долго, не понятно в чем прикол не закрывать сессии, нигде в банков такой херни нет... У них есть API, оно позволяет блочить саму ссылку для оплаты, например когда инициирована оплата - клиенту на почту приходит письмо с ссылкой и вот ограничить время которое будет активна эта ссылка - можно! Но если человек прошел по ссылке - выбрал способ оплаты, его кидает на страничку биллинга и вот там сессия не ограничена, если человек не закроет вкладку - он может оплатить ее хоть через час, хоть через 2е суток. И тут выходов было 2, либо полностью мутить свою форму и передавать данные карт через API, либо использовать iframe в pop up окне и просто на сайте уже блочить само окно, лимит работы ссылки в письме установили в 15 секунд чтобы человек физически не успевал перейти по ней) Ну сейчас пропадающие заявки свели к минимуму) Уже только появляются в случае проблем сервисов банка, когда они калбек не направляют после успешной оплаты.
SagePtr, никто не спорит, но цель была иная. так как держать бронь дольше нет возможности, билетов в сутки много продается и мы удаляем заявки из базы которые не оплачены с помощью крона и основная проблема была в том что люди оплачивают потом по истечению времени, а заявок уже нет. В итоге на концерты приходит множество людей показывая оплату, а мест нет)
Потому я не говорил о каком то сильном вмешательстве, это хороший пример того что это была бы большой уязвимостью (хотя она была раньше, пока не прикрыли), но если бы можно было хоть отслеживать ссылку например.
А чтобы воровать данные карты можно было бы не заморачиватся так, а просто левую форму сверстать и все)))
А какая разница в каком виде вы храните и отправляете ключ то по сути? От злых глаз на фронте вы ничего не спрячите, все что вы отдали браузеру - можно считать открытым по умолчанию. С помощью просто снифера любой школьник получит и POST и GET без проблем.
Роман, ну вот из жизни пример, есть модуль отплаты от РФИ через iframe, проблема РФИ в том что у них платежи не блокируются вообще и человек может хоть через месяц оплатить покупку, а так как у нас продажа билетов - мы максимум держим бронь 20 минут. Задача была отследить содержимой iframe модуля оплаты, чтобы понять хоть на каком он этапе и если человеку не приходит смс или например он дошел до пункта ввода пароля из смс, а время истекает - дать пользователю еще пару минут... А если на этапе выбора оплаты - то блочить окно платежа и снимать бронь.
Intenditore, просто это странная затея, никому не нужная... 2.3 vs 2.8 прирост будет 5-10%, это ничтожно и бессмысленно. Если убрать технические нюансы по заводу, то сама операция перепайки с большим риском и если у вас только не отвалился чип который и так требует ребол - то в ином случае это бессмысленно. Когда то изучал тему по GPU после отвала 6570m натыкался на статье где люди такую же проблему имели с 6550m и делали ребол на 6570m - то без танцев с бубном обошлось.
An Sem, ну он делит, это понятно. Но убрав лишние столбцы вы избавляете файл от ненужных данных и ворочать такой файл намного легче. А для добавления вместо 100к строк проверяется только 45...
An Sem, ну о том что БД такая у WP всем известно и это нужно было учитывать до выбора CMS)
Но на самом деле не понятно, вы выяснили какой именно процесс ложит сервер? Все как то слишком размыто, но скорее всего не хватает CPU так как мускул нагрузит на 100% (это все догадки) и тут вот возникает вопрос, нагрузится то только одно ядро, у вас еще 2 свободно, почему тогда сайт лагает?
Тут надо отследить процесс, во что упирается система. Возможно вы обновляли мощность сервера не но обновляли конфиг и не все ресурсы задействованы. Возможно нужно ограничить сам импорт, пускай он будет медленнее но нагружать например не более чем на 50%.
переписать ядро WP - бессмысленно, занимался этим на opencart (переводя все запросы к DB на питон) и по итогу получаем не обновляемый кусок говна).
Потому для вас лучшим выходом будет либо сменить настройки плагина для импорта либо сменить плагин для импорта, либо написать отдельно скрипт. Переписывать логику WP это уже последнее о чем нужно думать).
Из своего опыта, возможно вам это так же чем то поможет.
У заказчика есть магазин с 100к товаров и в CSV делает выгрузку, сначала мы залили товары (импортировали) там куча столбцов с инфой, но в этом же файл потом используется для обновления цен раз в неделю, там же могут быть и новые товары... Потому перед выгрузкой простым скриптом из одного CSV делаю 2, первый вырезает новые товары и сохраняю в отдельный CSV, вторым удаляю все столбцы кроме артикула, цен и наличия - и импорт вместо 20 часов занимает 2.
An Sem, ну 500 мег это мелочь для WP, у меня есть сайт с 1гб и грузится страница до 2 секунд без всяких плагинов кеширования.
Вот тут и кроется основная проблема, хостер настраивает сервер по шаблону, у них есть один образ и из него они поднимают северы. Вы же должны понимать что каждая CMS требует индивидуальных настроек php/mysql для быстрой работы. В первую очередь надо учитывать что WP работает с innoDB и например MariaDB будет в разы быстрее mySQL любых версий, далее нужно настроить mysql для работы с innoDB используя максимум ресурсов. Так же стоит использовать как минимум php7.2 + Opcache что заметно ускорит работу системы.
То что сервер не выдерживает нагрузок и сайт тормозит во время импорта - это опять же плохие настройки сервера
dollar, нельзя говорить о какой то безопасности когда вы используете чужое ПО, хотите безопасность - сделайте свой браузер, свой протокол интернета, свою OS... Поверьте, есть тысяча способов спарсить пароль помимо этого, за который вы переживаете.
