Ну не божественная, но однозначно лучше чем у опенкарта :)---------- Добавлено 05.11.2017 в 00:51 ----------
Модели для фронтед части отличаются от моделей бэкенд части. На фронтед части вы не сможете например получить сресдствами ядра модель бэкенда. Расширить таблицу товара вы не можете, точнее можете но ни одна часть опенк карта никогда об этом не узнает. И все с этим связанное, вы пробовали например отгружать один заказ из трех складов? оплачивать один заказ двумя способами оплаты? Разбивать на филиальную сеть и выводить свои пункты выдачи с проверкой по складам и показам где можно забрать сегодня а где через 1-2-3 дня? Битрикс больше к уровню энтерпрайз, на нем делают ИМ не для баловства, а чтоб бизнес работал.
С опенкартом все проще, это не модульная система это монолит и при том очень деревянный монолит: шаг влево, шаг вправо - расстрел. Там в ядре есть конечно все основное чтоб начать торговать ширпотребом с али, но тогда действительно нет разницы, что опен карт, что вордпресс, все одно
Вы сильно заблуждаетесь, стоимость работы в нашей сфере отличается лишь стоимостью человекачаса, а этот час зависит от опыта и квалификации человека, а не от системы управления сайтом, я сомневаюсь, что один и тот же человек пишет для разных систем по разным ценам... увы, хорошие разработчики стоят очень дорого и не важно, хоть полы заставьте мыть стоимость часа они не уменьшат.
Далеко не каждый сайт может хранить все в статике. Да и грамотная инвалидация сложный вопрос, когда это блог это одно, а когда это какой то сервис, интернет магазин или еще что то сильно зависещее от динамических данных это совсем другая история.
PS. Если вы можете сложить все в "вечный кеш", почему просто не отрендерите сайт в статику и не выложить настоящей статикой? Вам БД тогда и не нужна будет и нагрузка 0, и ответа от бэкенда не будет и 502 не будет))
---------- Добавлено 02.11.2017 в 23:54 ----------
Поискать ошибки можно установив свои логи которые перехватывают исключения/ошибки. Например воспользоваться сервисом https://rollbar.com/ он отловит все ваши ошибки и он частично бесплатный (с лимитами).
Но 502 ошибку вы можете не поймать, так как это ошибка когда nginx рвет соединение с бэкендом, а так как это шаред, затормозить сервер может не только ваш акк, если кто то в момент времени загрузил проц, ваш процесс может дольше ожидать процессорного времени, чем может ждать nginx, процесс то в итоге отработает, но nginx уже выкинет 502. Именно по этой причине сервисы разбивают на несколько серверов, фронт отдельно, бэк отдельно, бд отдельно - это все приоритетные процессы и являются сильноконкурирующими за процессор.---------- Добавлено 03.11.2017 в 00:08 ----------У меня у товарища аккаунт на бегете есть, сервис специализированный, пристройка к популярной облачной срм, так вот у него в статистике нагрузка на аккаунте была больше 1500% от лимита (не знаю как сейчас), вот такие клиенты и создают видимо 502 ошибки на сайтах других клиентов ))
PS. Не знаю, выгнал ли его еще бегет или нет :))
Что это за ИМ запчастей на 3000 товаров? Или это чисто тюнинг?
Сколько делал ИМ автозапчастей, там номенклатура начинается от 50к-60к товаров. У меня только по фордам 3 года назад получился каталог на 800 000 позиций это с кроссами конечно.
Автозапчасти это очень сложная тема в разработке и очень специфичная, я бы лучше обратился и выбрал специализированное решение, хоть на битриксе, хоть не на битриксе, где вам как минимум помимо всего магазина выдадут базу с номерами, кроссами и импортами/экспортами, потому что ручками все это заполнять можно всю жизнь и не заполнить.
Вы бы чтоль сервер указали что ли, сбоит то скорее всего конкретная нода, а не весь парк машин разом.
PS. У меня тоже все норм, тьфу-тьфу))
Она всегда у них глючит после обновления. Потому что:
1. Нужно подбить фичи под релиз... то есть их надо сделать ровно настолько, чтобы все работало на шоу презентации.
2. Там работаю студенты за хлеб. Спецов там очень мало, а работы очень много по жтому есть умный тим лид и шайка дешевеньких программеров за еду :)
Не парьтесь у них так всегда, ближе к следующей обнове поправят баги :)
Ну если они имеют хоть какой то траф эти страницы, то например можно показать писульку, мол извините по заданным параметрам ничего не найдено и показать товары по ближайшим параметрам где есть товары, ну например выкинув один из фильтров или какие нибудь персональные рекомендации
Многое зависит от кейса, в сессию многое не складывают, авторизацию, какую то юзерскую инфу и тогда получается что в сессию вы пишите при авторизации, для чего вам постоянно писать и каким должен быть кейс чтоб побить данные при одновременном чтении и записи сессии одного юзера?
Вы же в стандарте тут блочите сессию не в момент записи в неё, а в момент открытия, то есть когда вызван session_start и до момента session_write_close. В этот промежуток вы можете ничего не делать с сессией, но у вас например какой нибудь ajax запрос ресурсоемкий повесит все остальные ajax запросы на странице при это никак не работая с сессией вообще. Тут корапшен как вы говорите будет только в одном случае, если ваш кейс пишет в чужие сессии, ну или чистит чужие сессии, ну вообщем при воздействии из вне. Я работаю на достаточно больших ИМ и хз, какой кейс может побить сессию в редисе если честно. Ну а скорости конечно прибавляется, так как сессия используется на каждом хите и не мучается дисковая подсистема, хотя можно под сессии выделить и виртуальную папочку в оперативке, кому как интереснее.
Когда это информация о товаре стала динамической? Все зло в технологиях только в том, что люди не могут их попросту освоить.
Динамическая информация это та, которая должна меняться, например список рекомендаций, ранее просмотренные товары, корзина в шапке и любая информация которая меняется при посещении страницы либо для разных юзеров либо при разных условиях, как меняется информация о товаре то?
Просто допустим у вас есть контентная часть с картинкой, текстом и характеристиками, это все уйдет в кеш битрикса и соответственно при открытии страницы оно из статики загрузится моментально, а вот обвес вокруг этой информации, блоки новостей, акций и прочее плодит кучу запросов к базе, которые без композита должны сначала отработать все перед тем как сервер отдаст страницу. Есть блоки, как новости, конечно можно закешировать, но вот например персональные рекомендации ну никак не получится, или например доступность, многие магазины не включают кеш на каталоге потому что им нужно постоянно проверять остатки, вот с композитом можно кнопку купить и строку есть в наличии запихнуть в динамическую область и вот уже и кэш работает и остатки проверяются на возможность купить. Так же цена, которая для разных юзеров разная это динамическая информация, а вот подсчет рейтинга можно и закешировать. Так что тут главное проявить смекалку :)
PS. Когда руки из попы, ничего не спасет :)
Все обычно видят следствие, а я попробую донести причину на 2х примерах.
Пример первый, 2 человека покупают новое авто, один его гоняет на плановые ТО, меняет масло, ремни, запчасти там разные, второй чисто заправляет и что то меняет ровно тогда когда автомобиль встает на прикол, как думаете у кого авто прослужит дольше и кому первому понадобится кругленькая сумма на покупку нового авто?
Второй пример касается технического долга (как и первый конечно), есть понятия технического долга, когда мы программисты в угоду бизнеса плодим костыли (быстрее сдать фичу), эти костыли и есть технический долг (эти костыли когда нибудь надо будет переписать). Так вот технический долг сравним с кредитом. Вот вы взяли деньги в кредит (написали костыли) для дорогой покупки сразу (выпустить что то быстро в продакшен), вы начинаете платить ежемесячный платеж (читай пожертвовали архитектурой проекта, скоростью, связностью, запутаности и соответственно ростом сложности проекта), далее не погасив один кредит, вы берете второй, потом третий, потом четвертый и рано или поздно количество ежемесячных платежей превышает вашу платежеспособность.
Я вот к чему веду, на чем бы вы не написали проект, будь то yii или битрикс или еще что то, вам надо поменять отношение к проекту и работу с подрядчиками. Любой проект станет легаси, просто насколько быстро зависит от отношения заказчика к проекту
Вам же сказали, что это не php блокировки, а блокировка файловая на запись. Тут не в скорости ФС дело, а дело в том, что вы файл открыли на запись и начали делать бэкап, так вот пока бэкап не сделается (вы же не закрыли дескриптор файла), то система не отдаст блокировку.
Сессии в php в своем стандарте очень примитивны, просто пишет в файл, а так в большинстве случаев достаточно сложить их в БД, главное реализовать очистку протухших сессий, но редис тоже вполне пойдет. Либо не дергать session_start для каждого хита.
Тут больший вопрос к самой архитектуры движка, а не к хостингу.
