А что за хостер? таймвэб какой нибудь или спейсвэб? или можордомо?
То есть вы считаете, что за оптимизацией скачивания статичных файлов надо обращаться к вэб разработчикам (написано в том же письме хостером). Далее дан запрос, скорее всего есть какая то страница для скачивания аудиофайлов, для её формирования идут запросы к БД, там выводится листинг файлов, вытащенный с БД и вот именно формирование этого листинга и грузит хостинг. Ведь там может быть тысячи строк песен, а надо отобрать по фильтру, БД постоянно читает с диска кусками так как индексов нет, вместо того чтобы читать сразу нужный кусок с диска.---------- Добавлено 20.02.2020 в 14:09 ----------
Да, реплики это сильный механизм, на реплике можно даже построить другие индексы, другие типы таблиц, но запись в мастер, делает запись и во все реплики, так что если уничтожают запросами на запись мастер, то скорее всего лежат и все реплики.
Не совсем понимаю, что мешает изменить модуль каталога переписав структуру и обращения к нему? Это бы не сломало бы обновления, не сломало бы остальной функционал, но самописом был бы только один единственный модуль, написанный по правилам самой CMS.
Я почему на самом деле говорю за cms, хотя у меня b2b например сделан на симфони, как и многие модули и прочее (то есть мне есть с чем сравнить). Так вот я к тому, что в любой (из тех CMS что я юзал по крайней мере) можно выкинуть неподходящий модуль и заменить его на свой, то есть сделать самопис как нужно, но не целиком все, а только куска системы. И именно так у нас и происходит, у нас поиск свой на эластике основан, интегрирован в битрикс, настраивается с админки битрикса, а от туда уже идут и поиск и фасеты (агрегирование) и все это бесшовно добавлено в CMS, свои интеграции с мастер системами и партнерами (нам могут партнеры грузить свои товары), свои правила скидок (не весь механизм скидок, а лишь кастомные наши условия) и так далее. Я к тому что не совсем понимаю зачем переписывать абсолютно всё, если не устраивает что то одно. Да конечно если не подходит архитектура (например нужны микросервисы в кубернетес), то тут вариантов как бы не остается, но 90% проектам это не нужно, так лучше сосредоточится на том, чтобы пилить уникальный функционал и развивать ИМ, а не то чтобы пилить то что уже давно запилено, протестировано и работает на тысячах сайтов. По сути то CMS это админка, тот же OctoberCMS это надстройка с админкой над ларавелем, поставил CMS наклепал своих табличек вот тебе и проект, где под капотом проверенные решения, расширенные модульной системой и всякими няшками. Я единственно не очень люблю опенкарт, потому что там вот прям все в код вшито, в моделях прям прописана бизнес логика и прям гвоздями прибита архитектура БД и сравнительно странное расширение через модификаторы. Но и то в принципе юзабельная система. Я уж не говорю о том что у меня в подписе (магенто думаю еще вскоре добавить) :D
PS. А про самописы, я не сдам клиенту проект на elixir/phoenix наверное никогда, хотя очень крутая штука, я пишу свои пет проекты, развиваюсь в экосистеме эрланга, но вот сдать клиенту такой проект мне не позволит совесть, потому что хз где он потом будет искать поддержку, если вдруг у меня не будет времени.
Это всегда было так, индексы ускоряют выборку, но замедляют запись/изменение/удаление, по этому если в таблицу в основном пишут, то ей индексы противопоказаны. У меня был один ИМ на поддержке, там БД была 17Гб, а в месте с индексами занимала место на диске больше 100Гб, ну и все операции записи/удалении/изменения естественно работают дольше с индексами, чем без. По этому например рекомендуют записи с таблицы не удалять а помечать как уаленные, потому что перестроить таблицу индексов на например 30 млн строк операция не быстрая))
На самом деле глупо расставлять индексе с "заделом на будущее", если нет функционала, который будет юзать этот индекс, то индекс будет только тормозить и увеличивать место занимаемое БД. Часто бывает так, что при разработке каких то своих выборок, ты начинаешь делать SQL с фильтрами которые раньше нигде не использовались и они начинают промахиваться и CMS начинает "тормозить". Очень часто решается анализом SQL и доустановкой нужных индексов + я видел как индексы слетали, не интересовался по какой причине, но случаи бывали. Ну и вполне возможно самописный модуль, сообщество J не сильно отличается по скилам от сообщества W, многие даже не знают что такое индексы
Вообще я отвечал ребятам за скорость их самописов и удобство использования. При том они дальше старта (который закрывают CMS на 99%) в самописах не продвинулись, именно там где самописы в основном и раскрываются. При том люди, которые сами эти самописы пишут для себя и поддерживают. Они не понимают как это выглядит со стороны клиента и поиска и работы с подрядчиками.
А так, как количество товаров определяет сложность интернет магазина, это вот самое сравнение меня ставит в ступор периодически, неужели вы считаете, что для той же MySQL есть разница работать с 500 строками в таблице или с 500к строк?
И именно, тут речь что человеку нужно всего то развернуть магазин на 3.5 калеки, с функционалом который есть в опенкарте + шаблон за 3500р + 10 часов доработки напильником от спеца в итоге по времени за пару дней. А тут про самописы загоняют, чего нет то.
У одного витрина, у другого блокируемая напрочь SQLite при записи и они доказывают за скорость, самописы и ИМ =))) Я с вами согласен ребят, инструмент надо выбирать под задачу, я рад что у вас такие задачи, что вам хватает 3х файлов и БД SQLite и вы даже не в курсе что такое очереди, nosql, шардинг, реплики и прочая херня, без которой и так можно сделать 3000 rps или 30000 rps. К сожалению у меня таких задач как у вас нет.
Банерная реклама не в сервисах, а во вкладке маркетинг. А в сервисах расположен сам компонент
Вот тут правильное направление, самописом должна быть частная логика конкретного бизнеса, а рутинные задачи, типо роутинга, шаблонизации, орм, авторизаций и прочее лучше взять что то готовое, начиная от фремймворка, заканчивая CMS, писать все механизмы самостоятельно сейчас просто глупо.
Это не противоречие, например вы будучи на самописе можете все поля товара запихнуть в одну таблицу - это будет эффективнее, потому что в CMS как правило EAV паттерн, чтоб можно было добавить любое кол-во полей, что по сути не столь эффективно как в одной таблице. Эта неэффективность скорее всего на магазине не выявится никогда и по общей работе сайта это никак не скажется.
Вы поймите, ваш набор не отличается ничем от CMS, просто это ваша cms. А вот насколько это оправданно уже зависит от конечной цели. Вы поймите, за несколько дней можно как на своей CMS так и на коробке сделать, самопис - это когда вы с нуля пишите под ТЗ, а не используете какое то свое решение. Вернитесь на несколько сообщений выше, тащить свою CMS без сопровождения старых клиентов неоправданно, именно по этому многие собственные разработки студий загнулись. При том сильно непонятно что лучше для конечного клиента, платить символических N денег ежегодно для обновления и получения новых функций или не платить и не получать ничего (так как вы как разработчик уже давно забили на этого клиента со своей CMS из набора готовых модулей/классов/кодовой базе)
