Александр Воробьев

Александр Воробьев
Рейтинг
63
Регистрация
03.02.2020
Сайты на ВП у которых я сомневаюсь что маленький трафик

https://news.microsoft.com/ru-ru/

Вот у этих ребят не хватило средств чтоб сделать себе сайт по красоте и им пришлось создавать вот такие дико тормозящие сайты?

Sly32 #:
На серьезном магазине с кучей вариаций - начнет дико тормозить.
А куча это сколько?
Sly32 #:
Ты выбросил ту часть, где я говорю что каждому инструменту свое место.

Об этом и я говорил и другие участники.

Sly32 #:
Ты выбросил ту часть, где я говорю , что именно любители вордпресса приходят и страются на нем решать ЛЮБЫЕ задачи.

Может быть я был не внимателен. Я не хожу по всем другим темам форума. Подозреваю как и многие кто заходит в подобные темы. Получается эта тема конкретно кому то адресована. ок.

Я читал, что кто писал, среди твоих апонентов не видел где явно говорили о абсолютно любых задачах. Ну даже вот ты упомянул про 5000 посетителей.  Опять же нет ни где в теме определения серьезному проекту. Тогда уж так и стоило указать в первоначальном посте: тема исключительно про проект с такими то характеристиками: [перечень попугаев]

В целом тема холиваров достаточно популярная, потому без этого уточнения она и воспринимается как обычная тема этой серии.

"Насыплю" немного ИИ в тему  :)

Как выше писал ИИ сейчас тоже хороший помощник в обучении. С ним можно что то "обсудить", на что то собрать информацию и дать выжимку. (Конечно контролируя не понесло ли его). Была у меня в этом плане забавная ситуация.

разрабатывая в ходе челенджа фреймворк пришла мне в голову одна идея и я ее как то не достаточно глубоко обдумал, "удивился" почему это не реализовано в существующих фреймворках. Ну и обсудил с ИИ. тот мне "идея классная, стоит развивать, готовых реализаций нет". Ну я начал реализацию, попутно "обсуждая" с ИИ какие то тонкости (он мне даже некоторую статистику собирал по источникам). все ответы вроде как были разумными и даже ссылки подтверждающие были.  По скольку разработка была в режиме (по шагам): гипотеза - прототип, то тестов не писал. В общем вот идея реализована, начинаю писать тесты..... И тут до меня доходит, что все это не нужно, т.к. по сути (я детали сейчас уже даже не готов описать - не помню) все это пусть косвенно, но железобетонно обеспечивает сам PHP..... (в самом начале я почему то упустил из виду, хотя вообще там ответ был "на поверхности", но видим мысль стороной прошла).... я все это вываливаю ИИ.. и он мне тираду в духе: "Вы молодец, вы сами дошли до того, что эта идея нахрен не нужна...." :D

Sly32 #:
Покажи хоть один свой прект живой который тебе достаточно денег принес, не скрины.
Ну т.е. тебе всетаки надо чтобы водитель газели представил тебе документы подтверждающие, что он перевозил 140 тонн. (хинт: тому эти 140тонн по прежнему нахрен не нужны)
У меня был проект в свое время для энергетики: в режиме реального времени общается с овердохрена железяками и передает информацию дальше (это если упрощено). По мне так это серьезный проект (кстати говоря конкретно этот бал написан для подстанции обсуживающей Москва-сити - время прошло много может уже заменили, но когда то там и работала она). Докажешь, что твой FastApi для этого крут? (я на сях писал)

Тут уже были аналогии мне пришла в голову другая. Есть Вася он водитель БелАЗа и возит камни по 140 тонн за ходку. Есть водители газелей которые тоже возят камни, но по 2 тонны. И вот Вася приходит к ним и требует доказать, что Газель крутая машина. При этом по условиям его задачи доказывать нужно исходя из того что надо перевозить по 140 тонн. Не понимая, что 140тонн за раз им вообще ни кому нахрен не уперлось перевозить, а так же у них есть важная необходимость передвигаться по обычным дорогам в т.ч. и в населенных пунктах. Так же он только по 140тонн считает "серьезной"  грузоперевозкой, т.к. он оперирует своими личными критериями серьезности. А для газелиста Пети важнее, что он подписал контракт на поставку с крутым ландшафтным дизайнером у которого клиенты звезды и получает по ляму за камень. (да может быть еще 100500 причин по которым дела тех газелистов могут считаться серьезными)

Итак погнали

Sly32 #:
Ну мне было интересно, вдруг счас придут местные гуру и разобьют меня в пух и прах, ты не прав, ВП уже не тот это серьезная платформа

Для этого в первую очередь ты должен понять их цели и задачи, а не пытаться натянуть сову на глобус. Им не нужны твои 140тонн. Это только в твоем мире это критерий серьезности. Для большинства критерии иные. Для них твои перевозки лишь частный случай перевозок со своей спецификой.

Sly32 #:
А в итоге мне рассказывают про плоские таблицы, которые и 20 лет были назад и про которые я говорю что это проблема и костыль.

Костыль они только для тебя потому что это не подходит для твоих задач. (Напоминаю 140 тонн перевозить нахрен ни кому не надо кроме Васи)

Sly32 #:
Не понимая что такой метрики вообще нет для нагрузочного тестирования

А может потому что изначально обсуждение не подразумевает технической четкости обоснований  ввиду несуразности поставленных условий.

Sly32 #:
Вот обьясни им сам, что когда начинает работать кэш - перестает ВП))

Зачем мне объяснять им то, что я считаю глупостью? Да Вася перевозит по 140тонн за раз и не понимает, зачем газелисту Пете склад (ведь это уже не газель). А так же, по прежнему, не понимает, что Пете не нужно ни 140тонн за раз перевозить ни, даже, склад на 140тонн.

Хочешь грамотного обсуждения возможностей ВП, так и обсуждай его в контексте задач для которых его используют. 

Ведь есть еще танкеры который перевозит 320тысяч тон, и капитан которого считает БелАЗ Васи абсолютно дебильным ни чего не умеющим транспортным средствам. Он придет к Васе и потребует доказать что белаз это круто для задачи перевозки 320 тысяч тонн

Sly32 #:
Это нормальное решение для простых задач, отличное для блогов. Я уже устал это твердить. И ужасное, когда нужно собрать чтото серьезное. 

Вот именно в этом и ключ. У тебя есть свое восприятие серьезности ввиду твоей работы. И ты начинаешь измерять абсолютно все этими мерками. Примерять на свой рабочий проект ВП. (об этом тут уже не раз говорили по сути). Инструмент должен соответствовать задаче. Возможно для тебя 300К товаров и 3000 свойств товаров не серьезно, возможно RPS 1500 не серьезно. Но, поверь, это ситуация далеко не всех и даже не большинства интернет магазинов. И задачи там бывают достаточно интересные под капотом. Согласись на многих сайтах то что видит посетитель может быть лишь вершиной большого айсберга. И задачи бывают такие, что не "уровень джуна" или читателя "Сайт за 24 часа".

Ну а если такими аршинами как у тебя измерять. Так серьезных проектов то не так много ну может тыща - десять тысяч на весь мир - нет смысла обсуждать. Ни кто с ВП в их нишу не суется. 

В общем если суть темы "Вп не подходит для создания ВК" да ты прав. точка. ни кто не пытается и даже не говорит что ВП годен для этого. тему можно закрывать :)

Sly32 #:
Если ты почитал про ВП , то знаешь, что там есть 2 основные таблицы - wp_posts/wp_postmeta. Вторая по факту - ключ-значение. Давай представим себе запрос к товару, у которого есть с десяток вариаций? Вместо того чтобы сделать нормальные связанные таблицы что мы имеем? 

Ну и что? Это нормальное решение цель которого универсальность. Плюс минус такая же ситуация и в битрикс.  Вот тебе пример из мира битрикс запрашиваю типовым методом элемент из инфоблоков (аналог того к чему у тебя претензия в ВП). Способ получения устаревший, но уверен 3/4 если не больше разработчиков сделают именно так:

$res = CIBlockElement::GetList(
    [],
    [
        'IBLOCK_ID' => '15',
    'PROPERTY_PATTERN' => 'manstan'
    ],
    false,
    ['nTopCount' => 1],
    ['ID','NAME'],
);

Это порождает (уточню я фильтр сделал всего лишь по одному свойству)

SELECT  BE.ID as ID,BE.NAME as NAME
    FROM b_iblock B
                        INNER JOIN b_lang L ON B.LID=L.LID
                        INNER JOIN b_iblock_element BE ON BE.IBLOCK_ID = B.ID
                        INNER JOIN b_iblock_element_prop_s15 FPS0 ON FPS0.IBLOCK_ELEMENT_ID = BE.ID
                                        WHERE 1=1
                        AND (
                                ((((BE.IBLOCK_ID = 15))))
                                AND ((((FPS0.PROPERTY_135 LIKE 'manstan'))))
                        )
                        AND (((BE.WF_STATUS_ID=1 AND BE.WF_PARENT_ELEMENT_ID IS NULL)))
                                        LIMIT 1

И многие кто ушел продукт и "когда то имел дело с этим ужасным битрикс" сделают так же и будут мне показывать "безумное количество джоинов", которое по мерками их текущих крупных проектов кажется чем то ужасным..

Но вот кто в теме изменений, тот уже сделает иначе 

\Bitrix\Iblock\Elements\ElementPatternTable::query()
        ->setCustomBaseTableAlias('e')
        ->setSelect(['ID', 'NAME',])
        ->setLimit(1)
        ->where('PATTERN.VALUE', 'manstan')
        ->exec();

И получим уже менее ужасный запрос 

SELECT `e`.`ID` AS `ID`, `e`.`NAME` AS `NAME`
    FROM `b_iblock_element` `e`
    INNER JOIN `b_iblock_element_prop_s15` `iblock_element_prop_s15`
        ON `e`.`ID` = `iblock_element_prop_s15`.`IBLOCK_ELEMENT_ID`
    WHERE `iblock_element_prop_s15`.`PROPERTY_135` = 'manstan' AND `e`.`IBLOCK_ID` = 15 LIMIT 0,

Так что уверяю - я представляю запросы. :) Но еще раз уточним: это решение из коробки, и оно используется до тех пор, пока все устраивает. Как только упираемся в ограничения - можно принимать другие решения. Как частный случай в ВП есть некие плоские таблицы, в Битрикс из коробки под это можно заточить так называемые HighloadBlock  . Но и так же можно создать нужную для задачи структуру таблиц (хочешь нормализованную, хочешь нет)

Согласись любая CMS это попытка уменьшить работу программиста до минимума. Т.е. достаточно странно примерять высоконагруженную систему на универсальное гибкое решение и клеймить за неповортливость cms. Если эти таблицы узкое горлышко - не используй. Таким образом условно всякие статьи, блоги, и прочее подобное (по сути статический контент) храниться в штатной системе, а каталог (возможно только свойства) в отдельных таблицах... тут уж дело архитектуры конкретного проекта - все решаемо.

Sly32 #:
Вместо того чтобы сделать нормальные связанные таблицы что мы имеем? 

Мы имеем универсальное годное решение для минимизации вложений в проект. По крайней мере в пору "до ИИ" время программиста стоило дорого. А тут контент менеджер зашел в админку потыкал мышкой, а то и вообще просто в 1Ске новое свойство товарам  завезли, произошел обычный обмен ... и вот уже на сайте пользователи в фильтре выбирают товары по этому свойству. И это все без участия разработчика. 

Sly32 #:
А ты понимаешь что именно для вариаций использование плоских таблиц - хуже некуда?  Или ты не знаешь за нормализацию? Я вообще то об этом и говорю, как о проблемме, что для всего есть три таблицы, которые приходится собирать самыми тяжелыми запросами.

Не согласен. (по крайней мере с рядом оговорок)

1. Денормализация данных вполне распространенное решение там где встает вопрос производительности

2. Я погуглил про ВП и вариации. Т.е. если я правильно понял "вариация" === "торговое предложение в Битрикс" и основное проблема это большие запросы. Так наверно эти "плоские таблицы" которые из коробки просто надо грамотно использовать.

3. Вообще я считаю тут нет проблемы вообще. Из коробки имеем гибкую систему, но дорогую. Как только это начинает напрягать - переписываем часть проекта без использования этой системы. и все.

Всего: 947