Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Pirks

Пользователи
  
  • Posts

    198
  • Joined

  • Last visited

Everything posted by Pirks

  1. Бесплатно попробовать сервисы, развернуть прототип проекта и т.д. Ну а когда стал зарабатывать, почему бы и не заплатить за ресурсы? ) Да, не отрицаю, бесплатность - это маркетинговый ход. Но мне кажется он выгоден не только поставщику услуг, но и покупателю.
  2. На мой взгляд, это вполне нормально. На бесплатных ресурсах обкатываешь проект, если есть положительный результат, покупаешь ресурсы. А идентификация по карте, это вообще не обсуждается. )) Очень нормально. Иначе быстро превратиться в ботнет.
  3. Кстати IBM как и Google раздает бесплатные ресурсы, дисковое пространство для файлов и SQL хранилище. Вполне можно что-то попробовать по этой теме. https://cloud.ibm.com/
  4. Да, я в теме API Google Spread Sheet. Активно пользуюсь загрузкой - выгрузкой в Open Cart. Единственное, мне не хватает в таблицах функциональности настоящих баз данных, сказывается тяжелое реляционное детство. А вот как интерфейс, таблицы самое то - быстрый ввод, формулы, пользователям удобно, не надо искать кодера, что бы сделать наценки, скидки. Вообще у Googl' а много разных API, есть где развернуться. З.Ы. Интересно читать, как на searchengines "пинают ногами" разработчика магазина - как можно обойтись без хостинга и баз данных!! ))) Да, такой магазин скорее для гиков, с большим количеством недостатков, но тенденция на лицо - ИМ только на сторонних сервисах. Все очень быстро меняется.
  5. Про стоимость поддержки соглашусь, но обратите внимание на рынок Landing Page. По моим наблюдениям, на фрилансе 80% заказов по LP, это настроить и доделать LP на конструкторах - генераторах. Мне кажется такое может случиться и с ИМ в ближайшие два-три года. Нет, это не магазин как сервис в облаке. А магазин собранный из услуг, таких как serverless или FaaS. Например, что мешает тому же cezerin ) обращаться не к API своего бэкэнда, а к API ресурса, где будут храниться товары? С возможностью быстрой фильтрации, масштабирования и бэкапов. Здесь даже админы - DevOps не нужны, например для оптимизации баз данных. И админка, для управления товарами, экспортами - импортами, ценообразованием, тоже может быть как отдельный сервис. И сама бизнес модель получается рентабельной, на serverless оплата идет за обращения к API или базам данных. Т.е. сайт не пользуется популярностью, нет запросов к API соответственно оплата за услуги падает. З.Ы.Это не прогноз, это ощущения от прочтения некоторых материалов на тему ... )
  6. vamshop, направление JAMstak смотрели? Что скажете, какое впечатление?
  7. 2 Я уже переустановил MySQL - 5.7 чтобы конфигурация была идентична десктопной. По прежнему скорость ниже в три раза в тестовом скрипте - 1000 запросов INSERT, VPS ~0.3 s Desctop ~0.1 s Но! Если сделать пакетное добавление - 100000 записей, пакетами по 100 INSERT в запросе, время ~1.2 s на десктопе ~1.1 s Делаем вывод - неверная архитектура приложения сводит на нет вычислительные мощности VPS.
  8. Ну вообще, если InnoDB Write Log efficiency: 88.9% (5286 hits/ 5946 total) - это наверное не плохо. Гулю тему и вижу люди жалуются на этот показатель меньше 10% Жду ваш sysbench )
  9. После выполнения рекомендаций 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 Если кто в теме, прокомментируйте ...
  10. Да! Это был он, скорость добавления записей значительно выросла. Еще обратил внимание на наличие файлов binlog.* в /var/lib/mysql , но не стал разбираться. 100napb, спасибо за подсказку!
  11. а) Нет, тестовый скрипт, это 1000 отдельных запросов. Да, я в курсе, как сделать одним запросом добавление нескольких записей. Но цель теста имитировать работу основного скрипта, который переносится с десктопа, он не оптимален, но он работает. Но это уже не моя тема а разработчика. б,в,г,д,е,ж ) Спасибо, погугулю про эти параметры, попробую
  12. Нет, здесь без докера. Все ставится на пустую 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 - это десктоп.
  13. День добрый! Есть консольный скрипт на 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, что логично.
  14. Вроде в курилке можно обсуждать любые темы ... Или разговоры на темы технологий альтернативных OpenCart здесь запрещены?
  15. Прочитал статью на хабре и еще более утвердился, в том, что мне ближе SQL подход в проектах ИМ. И сам строгий подход к проектированию архитектуры данных, это тоже мое. ) Очевидно у нас с вами разный подход к решению подобных задач. ) Кстати, с учетом того, что в последних версия mySQL можно хранить и делать запросы JSON, мы можем использовать mySQL как noSQL - запихать кучу всего в одно поле типа JSON. Надо пробовать!
  16. Тема eCommerce c nodejs мне тоже интересна. Пробую node в локальных проектах - парсинг (puppeteer) , консольные обработчики и т.д. Посматриваю и на headless CMS, например strapi - выбираю, что попробовать если не для полноценного магазина, но для создания админки для работы с MySQL OpenCart. Все интересно, но смущает один момент - NoSQL. Еще не пробовал, поэтому вопрос. Как MongoDB себя чувствует в таких например задачах, как хранение нескольких прайсов в одной таблице ( ~300 тыс. записей), когда я одним запросом получаю оптимальную цену для каждого товара с учетом приоритета прайса и срока поставки. Все в одном запросе. Какие преимущества в ИМ у MongoDB перед реляционными СУБД ?
  17. Добрый день! Рассматриваю Ваш модуль для приобретения. Вопрос. На Yandex Метрика в разделе 'Как подключить Электронную коммерцию' в самом низу есть ссылка на плагины для CMS https://metrika.yandex.ru/about/info/integrations и там есть ссылка на другой модуль для Open Cart. На мой неискушенный взгляд мне ваш модуль кажется более функциональным. Это так?
  18. День добрый! Необходимо при определенном статусе на складе, выводить сообщение о необходимости предоплаты. Просто добавить к тексту статуса, не подходит - необходимо разное оформление в карточке товара. Есть вариант добавить prepayment VARCHAR (50) в _stock_status. А затем в запросе сделать что-то типа concat_ws ( ";", name, prepayment ), и соответственно результат explode. Но все это выглядит как-то криво. ) Вопрос - а не поломает ли такой костыль какие либо модификаторы? Какие еще есть варианты?
  19. @mazein Спасибо за ответ! Посмотрел админку модуля, да, все понятно - есть установка соответствия категорий OC и Авито. Еще вопросы 1. Модуль предполагает только загрузку новых объявлений и их последующее обновление в тарифах Расширенный или Максимальный? Т.е. Не надо выставлять соответствие product_id и AvitoId. 2. Формат файла соответствует вот этим требованиям http://autoload.avito.ru/format/zapchasti_i_aksessuary/
  20. Добрый день! Модуль будет работать в категории Автозапчасти ? Необходима какая-либо корректировка данных в ocStore ? Насколько мне известно, на Авито существует своя структура категорий запчастей. Работает в ocStore 3.0 ? Спасибо!
×
×
  • Create New...

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.