Pirks

Если не срочно и еще актуально, можно обсудить. 

В 31.03.2020 в 18:01, markimax сказал:

Так обычно и бывает
К примеру большой облачный https://imageshack.com  так и сделал тоже
Был бесплатным облачным API для изображений, много пользователей, CMS, модулей там размещали безопасно изображения (очень удобно было замечу).
И в один прекрасный момент (в НГ 2019), бац и он уже платный.

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

В 31.03.2020 в 17:55, Denys сказал:

А как только появится спрос и популярность урезать квоты на бесплатный вызов API как и Google задрать цены и считать профит? Только одного меня смущает что якобы бесплатные сервисы не дают возможности зарегистрироваться пока не дашь им данные своей кредитки.

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

Кстати IBM как и Google раздает бесплатные ресурсы, дисковое пространство для файлов и SQL хранилище. Вполне можно что-то попробовать по этой теме. 
https://cloud.ibm.com/ 

В 07.03.2020 в 11:04, vamshop сказал:

Кстати, на searchengines тоже интересная тема появилась, на medium об этом тоже писали как-то статьи.

Магазин, сайт на гугл таблицах.

 

В качестве данных для магазина выступают таблицы excel.

+ обычный клиентский html + css + js на стороне сайта, без необходимости серверной части вообще.

 

Это тоже ведь возможно благодаря API гугл таблиц, не было бы доступа к "сырым" данных таблиц через api, ничего такого сделать нельзя было бы.

 

Да, я в теме API Google Spread Sheet. Активно пользуюсь загрузкой - выгрузкой  в Open Cart.
Единственное, мне не хватает в таблицах функциональности настоящих баз данных, сказывается тяжелое реляционное детство. 
А вот как интерфейс, таблицы самое то - быстрый ввод, формулы, пользователям удобно, не надо искать кодера, что бы сделать наценки, скидки.       
Вообще у Googl' а много разных API, есть где развернуться.

З.Ы. Интересно читать, как  на searchengines  "пинают ногами"  разработчика магазина - как можно обойтись без хостинга и баз данных!! ))) 
Да, такой магазин скорее для гиков, с большим количеством недостатков, но тенденция на лицо - ИМ только на сторонних сервисах. 
Все очень быстро меняется.  

В 04.03.2020 в 22:44, Bn174uk сказал:

Так уже говорили и обсуждали это, что такие сайты дорогие в обслуживании.

Вот как только эти технологии станут по цене разработки такие же как и эти движки + комьюнити будет такое же большое, тогда люди и перестанут жить в каменном веке.

 

Про стоимость поддержки соглашусь, но обратите внимание на рынок Landing Page. По моим наблюдениям, на фрилансе 80% заказов по LP, это настроить и доделать LP на конструкторах - генераторах. Мне кажется такое может случиться и с ИМ в ближайшие два-три года. 
Нет, это не  магазин как сервис в облаке. А магазин собранный из услуг, таких как serverless или FaaS. 
Например, что мешает тому же  cezerin ) обращаться не к API своего бэкэнда, а к API ресурса, где будут храниться товары? 
С возможностью быстрой фильтрации, масштабирования и бэкапов. Здесь даже админы - DevOps не нужны, например для оптимизации баз данных.

И админка, для управления товарами, экспортами - импортами, ценообразованием, тоже может быть как отдельный сервис.
И сама бизнес модель получается рентабельной, на serverless оплата идет за обращения к API или базам данных. Т.е. сайт не пользуется популярностью, нет запросов к API соответственно оплата за услуги падает.
З.Ы.Это не прогноз, это ощущения от прочтения некоторых материалов на тему ... )

vamshop, направление JAMstak смотрели?
Что скажете, какое впечатление?

16 часов назад, Yoda сказал:

а что у вас там в innodb_flush_log_at_trx_commit  ?

2

Я уже переустановил MySQL - 5.7 чтобы конфигурация была идентична десктопной.
По прежнему скорость ниже в три раза в тестовом скрипте - 1000 запросов INSERT, VPS ~0.3 s Desctop ~0.1 s
Но! Если сделать пакетное добавление - 100000 записей, пакетами по 100 INSERT в запросе, время ~1.2 s на десктопе ~1.1 s
Делаем вывод - неверная архитектура приложения сводит на нет вычислительные мощности VPS.

1 час назад, 100napb сказал:

виртуализация она такая =\

 

  Показать контент

вечером постараюсь снять результаты сисбенча с какого-нибудь мало-мальского физического сервера для сравнения и интереса

 

Ну вообще, если 
InnoDB Write Log efficiency: 88.9% (5286 hits/ 5946 total) - это наверное не плохо.
Гулю тему и вижу люди жалуются на этот показатель меньше 10%
Жду ваш sysbench )
 

После выполнения рекомендаций  mysqltuner, получил прирост скорости записи в 3-и раза. Но, скорость записи на VPS, все еще ниже скорости записи на десктопе ...  в 3-и раза.
Вот результаты sysbench
sysbench /usr/share/sysbench/oltp_write_only.lua --threads=4 --events=0 --time=30 --mysql-host=localhost --mysql-user=user --mysql-password=pass --mysql-port=3306 --tables=5 --table-size=10000 --range_selects=off --db-ps-mode=disable --report-interval=1 --db-driver=mysql run

SQL statistics:
    queries performed:
        read:                            0
        write:                           500850
        other:                           259226
        total:                           760076
    transactions:                        126679 (4221.99 per sec.)
    queries:                             760076 (25332.00 per sec.)
    ignored errors:                      1      (0.03 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          30.0028s
    total number of events:              126679

Latency (ms):
         min:                                  0.55
         avg:                                  0.94
         max:                                 17.17
         95th percentile:                      1.21
         sum:                             119326.31

Threads fairness:
    events (avg/stddev):           31669.7500/19.31
    execution time (avg/stddev):   29.8316/0.00

Если кто в теме, прокомментируйте ... 

11 часов назад, 100napb сказал:

ж) mysqltuner говорит что-то внятное?

 

За mysqltuner, отдельно спасибо! )
 

11 часов назад, 100napb сказал:

в) у Вас включен bin log (настроена репликация)? если нет, то убедитесь, что он не включен

Да! Это был он, скорость добавления записей значительно выросла.
Еще обратил внимание на наличие файлов  binlog.* в  /var/lib/mysql , но не стал разбираться.

100napb, спасибо за подсказку!
 

7 часов назад, ibond сказал:

 

 

Changes in MySQL 8.0.19 (2020-01-13, General Availability)

..... обновляйтесь.

Я неделю назад устанавливался ...

2 часа назад, 100napb сказал:

если с ходу, то:

а) банальный INSERT ~ 1000 записей - это 1000х инсертов или один инсерт вида insert into table_name (id, val) values(1,1),(1,2),(1,3),… ?

б) установленный уровень фиксации транзаций (innodb_flush_log_at_trx_commit  2) накладывает серьезные ограничения на скорость изменения данных; если нет жестких требований, обусловливающих необходимость именно такого уровня, то смело ставьте 0. Если у Вас не кассовое \ банковское ПО, конечно

в) у Вас включен bin log (настроена репликация)? если нет, то убедитесь, что он не включен

г) при установленном размере innodb_buffer_pool_size в 1гиг рекомендуется в общем случае использовать innodb_log_file_size = 128m и innodb_log_buffer_size = 32m

д) почитайте за возможные значения innodb_flush_method и их отличия.

е) зачем трогать довольно тонкие механизмы вроде innodb_max_dirty_pages_pct_* ? из коробки вроде иные значения. оставьте их - дефолтные.

ж) mysqltuner говорит что-то внятное?

 

а) Нет, тестовый скрипт, это 1000 отдельных запросов. Да, я  в курсе, как сделать одним запросом добавление нескольких записей. Но цель теста имитировать работу основного скрипта, который переносится с десктопа, он не оптимален, но он работает. Но это уже не моя тема а разработчика.
б,в,г,д,е,ж ) Спасибо, погугулю про эти параметры, попробую   

2 часа назад, esculapra сказал:

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

Пробовал - на MyISAM, аналогично.

4 часа назад, Yoda сказал:

все зависит не только от диска. Если к примеру взять очень большую таблицу, и внее делать insert и это mysql а не mariadb и таблицы innodb, то пересчет индекса - это напрямую мощность процессора, который зарезан на vps, а никак не скорость дисковой подсистемы. Это раз.

Два чем больше памяти может пользовать база - тем ей легче.

 

А еще, судя по всему, если вы говорите про mysql8, она у вас задеплоена через докер из ISP  панели, и есть большая проблема с базами которые работют в докере, у них реально очень большой лаг  с производительностью, используйте родную базу и будет все хорошо.

Нет, здесь без докера. Все ставится на пустую Ubuntu 18.04, никаких ISP или других GUI для управления.  Мониторится через Telegraf в InfluxDB и затем Grafana, все видно  - ресурсов море, но в INSERT не такой как хотелось бы.
И дисковую подсистему тестил -

dd if=/dev/zero of=sb-io-test bs=1M count=1k conv=fdatasync; rm -rf sb-io-test

1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.52426 s, 704 MB/s - это VPS.
скопировано 1073741824 байта (1,1 GB), 15,1642 c, 70,8 MB/c - это десктоп.

День добрый!
Есть консольный скрипт на PHP, работал на десктопе в офисе. 
На десктопной Ubuntu 16.04 ( i5-7200U 8Gb ) mySQL 5.7 - тестовый скрипт на PHP, банальный INSERT ~ 1000 записей, работает на порядок быстрее, чем на VPS Ubuntu 18.04 ( E5-2630, 24 Gb ) mySQL 8.0. 
my.cfg у 8

innodb_adaptive_flushing  ON
innodb_buffer_pool_instances  8
innodb_buffer_pool_size  1073741824
innodb_flush_log_at_trx_commit  2
innodb_flush_method  fsync
innodb_flush_neighbors  1
innodb_log_file_size  1073741824
innodb_max_dirty_pages_pct  90.000000
innodb_max_dirty_pages_pct_lwm  1.000000
max_allowed_packet  16777216

Куда копать?
Есть утверждения, что это нормально для VPS, но замер производительности дисковой подсистемы показывает что SSD на VPS на порядок быстрее, чем на десктопе обычного HDD, что логично.  

22 часа назад, Yoda сказал:

 

Скажите, а зачем вы эту дичь вашу сюда занесли?

 

Вроде в курилке можно обсуждать любые темы ...
Или разговоры на темы технологий альтернативных  OpenCart здесь запрещены?

Прочитал статью на хабре и еще более утвердился, в том, что мне ближе SQL подход в проектах ИМ.
И сам строгий подход к проектированию архитектуры данных, это тоже мое. ) 
Очевидно у нас с вами разный подход к решению подобных задач. )
Кстати, с учетом того, что в последних версия mySQL можно хранить и делать запросы  JSON, мы можем использовать mySQL как noSQL - запихать кучу всего в одно поле типа JSON.
Надо пробовать! 
 

Тема eCommerce c nodejs мне тоже  интересна.
Пробую node в локальных проектах - парсинг (puppeteer) , консольные обработчики и т.д. Посматриваю и на headless CMS, например strapi - выбираю, что попробовать если не для полноценного магазина, но для  создания админки для работы с MySQL OpenCart.  
Все интересно, но смущает один момент - NoSQL. Еще не пробовал, поэтому вопрос.
Как MongoDB себя чувствует в таких например задачах, как хранение нескольких прайсов в одной таблице ( ~300 тыс.  записей), когда я одним запросом получаю оптимальную цену для каждого товара с учетом приоритета прайса и срока поставки. Все в одном запросе.     
Какие преимущества в ИМ у MongoDB перед реляционными СУБД ?

Добрый день!
Рассматриваю Ваш модуль для приобретения. 
Вопрос.
На Yandex  Метрика в разделе 'Как подключить Электронную коммерцию' в самом низу есть ссылка на  плагины для CMS 
https://metrika.yandex.ru/about/info/integrations  
и там есть ссылка на другой модуль для Open Cart.
На мой неискушенный взгляд мне ваш модуль кажется более функциональным.  Это так?
 

День добрый!
Необходимо при определенном статусе на складе, выводить сообщение о необходимости предоплаты. 
Просто добавить к тексту статуса,  не подходит - необходимо разное оформление в карточке товара.
Есть вариант добавить prepayment VARCHAR (50) в _stock_status.
А затем в запросе сделать что-то типа concat_ws ( ";", name, prepayment ), и соответственно результат  explode.
Но все это выглядит как-то криво. )
Вопрос - а не поломает ли такой костыль какие либо модификаторы?
Какие еще есть варианты?
 

@mazein Ok! Спасибо.

@mazein Спасибо за ответ!
Посмотрел админку модуля, да, все понятно - есть установка соответствия категорий OC и Авито.
Еще вопросы
1. Модуль предполагает только загрузку новых объявлений и их последующее обновление в тарифах  Расширенный или Максимальный?

Т.е. Не надо выставлять соответствие product_id и AvitoId.
2. Формат файла соответствует вот этим требованиям 
http://autoload.avito.ru/format/zapchasti_i_aksessuary/
 

Добрый день!
Модуль будет работать в категории Автозапчасти ?
Необходима  какая-либо корректировка данных в ocStore ? Насколько мне известно, на Авито существует своя структура категорий запчастей.

Работает в ocStore  3.0 ?

Спасибо!