Скиньте мне тоже линк, поклацкаю, разберусь может в чем нюанс.
Вы подумайте над тем, как часто вы будете обращаться к этим данным. Если вам нужен быстрый доступ, и БД не справляется, тогда NoSQL разумное решение (но не в XML). В остальных случаях, настоятельно рекомендую сделать как советовал оптимизайка и не городить подобные костыли.
Друзья, запустил свой сайт quasar.cc, сделанный на Vue.js + бекенд. Это что-то вроде небольшого примерчика, чтобы пользователи видели что примерно я могу делать. К слову, это SPA и я собираюсь проверить, как он индексируется гуглом.
На данный момент заказы в работу не беру, потому что веду два проекта, но через пару недель появится свободное время.
Для тех, кому не срочно, освежу список того, что я делаю:
Если у вас есть интересная работа, и вы хотите получить качественный результат - обращайтесь, буду рад. Актуальные контакты в первом посте на первой странице.
Дропшиппинг в большинстве случаев это днище.
Ящитаю, что дропшиппинг убивает электронную торговлю. Особенно, если не мониторить МРЦ, найдется куча скудоумных, которые за 2 рубля наценки будут гонять вашего курьера, сидя дома и принимая заказы в ВК. В итоге, страдают обычные магазины, которые закупают продукцию, держат на складе, своевременно отправляют, так как они не могут потягаться с ценой, которую дают дропшипперы, так как они лишены всех этих затрат.
Я был на стороне тех, кто является поставщиком, и предоставлял товары по дропшиппингу, а также был тем, кто работал с поставщиками по этой схеме. И ни то, ни другое сотрудничество, мне не понравилось. Хотя если выжить можно только таким способом, выбирать не приходится.
P.S. В Украине под дропшиппинг благоприятная почва: небольшая страна, быстрые и недорогие доставки из одного края страны в другой, а также небезызвестный prom.ua, благодаря которому каждый идиот может импортировать файл на 100500 тысяч товаров, и продавать дешевле чем вы, имея на руках только мобильный телефон.
Не знаю, было или нет))
Итак, рассказываю подробнее о всей эпопее:
Для начала сделал OPTIMIZE/ANALYZE TABLE, никаких результатов это не дало.
По совету коллег сделал составной индекс и STRAIGHT_JOIN, + добавил FORCE INDEX в нескольких местах. Это помогло ускорить запрос до почти сопоставимых результатов, и все бы ничего, если бы не...
Отвалился другой запрос. Сделал по аналогии, прописал FORCE INDEX по FK CONTSTRAINT, это тоже дало результаты, но стало интересно, в чем же все таки затык, и почему оптимизатор принимает неправильные решения.
В результате, решил попробовать накатить дамп с тестового сервера на боевой, и... это помогло. Не знаю в чем был косяк, но видимо почему-то статистика не давала оптимизатору принимать правильные решения.
Сейчас тоже наблюдаю интересную ситуацию:
Практически идентичный конфиг сервера на проде, и на локальном севрере (виртуалка): 2ГБ, 1 ядро.
Одна и та же версия MariaDB, с одинаковым конфигом.
Одна и та же база, одинаковое количество строк в таблице, все индексы одинаковые.
План выполнения совершенно разные, что в результате выливается в:
0.0001s - локалка
0.47s - прод.
Т.е., разница в 4700 раз.
Понравился пост из Сталингулаг в том-же Телеграм:
https://t.me/stalin_gulag/666
Если бы вы разули свои глаза, то увидели бы, что там 503 статус. Почитайте то, что я писал под пастой с бенчмарком. На бенчмарке моего блога, все ответы были с 200 статусом.
Я показал, что ВП может работать быстро. То, что вы лепите на WP интернет-магазины, это ваши проблемы.
Мне проще не комментировать на самом деле, учитывая что вы сами не вникаете в то, что пишете. И бенчмарки я не вам кидал.
О, вернулся)) Что-то я аж заскучал без вас и ваших охренительных сравнений всего подряд vs джанга.
Вот например результаты нагрузочного тестирования моего мини-блога на WP:
Summary: Total: 61.1485 secs Slowest: 7.6650 secs Fastest: 0.1717 secs Average: 0.3459 secs Requests/sec: 1423.7638 Response time histogram: 0.172 [1] | 0.921 [82998] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 1.670 [3843] |∎∎ 2.420 [180] | 3.169 [15] | 3.918 [6] | 4.668 [11] | 5.417 [0] | 6.166 [0] | 6.916 [2] | 7.665 [5] | Latency distribution: 10% in 0.2095 secs 25% in 0.2132 secs 50% in 0.2182 secs 75% in 0.3418 secs 90% in 0.8283 secs 95% in 0.8984 secs 99% in 1.4656 secs Details (average, fastest, slowest): DNS+dialup: 0.0008 secs, 0.0000 secs, 0.5104 secs DNS-lookup: 0.0001 secs, 0.0000 secs, 0.0225 secs req write: 0.0000 secs, 0.0000 secs, 0.0400 secs resp wait: 0.3400 secs, 0.0495 secs, 7.6645 secs resp read: 0.0002 secs, 0.0000 secs, 0.0405 secs Status code distribution: [200] 87061 responses
1423 запроса в секунду со статусом 200, не считая статики. Разве это медленно?
Вот, к слову, wpcute (простите за дудос)
Summary: Total: 60.3390 secs Slowest: 7.4293 secs Fastest: 0.0385 secs Average: 0.3225 secs Requests/sec: 1545.7990 Total data: 34075572 bytes Size/request: 365 bytes Response time histogram: 0.039 [1] | 0.778 [92512] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 1.517 [429] | 2.256 [61] | 2.995 [268] | 3.734 [0] | 4.473 [0] | 5.212 [0] | 5.951 [0] | 6.690 [0] | 7.429 [1] | Latency distribution: 10% in 0.2473 secs 25% in 0.2709 secs 50% in 0.3041 secs 75% in 0.3430 secs 90% in 0.3866 secs 95% in 0.4169 secs 99% in 0.7247 secs Details (average, fastest, slowest): DNS+dialup: 0.0024 secs, 0.0000 secs, 0.7574 secs DNS-lookup: 0.0004 secs, 0.0000 secs, 0.0861 secs req write: 0.0000 secs, 0.0000 secs, 0.0035 secs resp wait: 0.3167 secs, 0.0380 secs, 6.7810 secs resp read: 0.0001 secs, 0.0000 secs, 0.0045 secs Status code distribution: [503] 91601 responses [200] 1671 responses
Но у них большая часть запросов отдавала 503 статус, так что не считается. На шареде так тонко не настроишь.
