Вы бы чтоль сервер указали что ли, сбоит то скорее всего конкретная нода, а не весь парк машин разом.
PS. У меня тоже все норм, тьфу-тьфу))
Она всегда у них глючит после обновления. Потому что:
1. Нужно подбить фичи под релиз... то есть их надо сделать ровно настолько, чтобы все работало на шоу презентации.
2. Там работаю студенты за хлеб. Спецов там очень мало, а работы очень много по жтому есть умный тим лид и шайка дешевеньких программеров за еду :)
Не парьтесь у них так всегда, ближе к следующей обнове поправят баги :)
Ну если они имеют хоть какой то траф эти страницы, то например можно показать писульку, мол извините по заданным параметрам ничего не найдено и показать товары по ближайшим параметрам где есть товары, ну например выкинув один из фильтров или какие нибудь персональные рекомендации
Многое зависит от кейса, в сессию многое не складывают, авторизацию, какую то юзерскую инфу и тогда получается что в сессию вы пишите при авторизации, для чего вам постоянно писать и каким должен быть кейс чтоб побить данные при одновременном чтении и записи сессии одного юзера?
Вы же в стандарте тут блочите сессию не в момент записи в неё, а в момент открытия, то есть когда вызван session_start и до момента session_write_close. В этот промежуток вы можете ничего не делать с сессией, но у вас например какой нибудь ajax запрос ресурсоемкий повесит все остальные ajax запросы на странице при это никак не работая с сессией вообще. Тут корапшен как вы говорите будет только в одном случае, если ваш кейс пишет в чужие сессии, ну или чистит чужие сессии, ну вообщем при воздействии из вне. Я работаю на достаточно больших ИМ и хз, какой кейс может побить сессию в редисе если честно. Ну а скорости конечно прибавляется, так как сессия используется на каждом хите и не мучается дисковая подсистема, хотя можно под сессии выделить и виртуальную папочку в оперативке, кому как интереснее.
Когда это информация о товаре стала динамической? Все зло в технологиях только в том, что люди не могут их попросту освоить.
Динамическая информация это та, которая должна меняться, например список рекомендаций, ранее просмотренные товары, корзина в шапке и любая информация которая меняется при посещении страницы либо для разных юзеров либо при разных условиях, как меняется информация о товаре то?
Просто допустим у вас есть контентная часть с картинкой, текстом и характеристиками, это все уйдет в кеш битрикса и соответственно при открытии страницы оно из статики загрузится моментально, а вот обвес вокруг этой информации, блоки новостей, акций и прочее плодит кучу запросов к базе, которые без композита должны сначала отработать все перед тем как сервер отдаст страницу. Есть блоки, как новости, конечно можно закешировать, но вот например персональные рекомендации ну никак не получится, или например доступность, многие магазины не включают кеш на каталоге потому что им нужно постоянно проверять остатки, вот с композитом можно кнопку купить и строку есть в наличии запихнуть в динамическую область и вот уже и кэш работает и остатки проверяются на возможность купить. Так же цена, которая для разных юзеров разная это динамическая информация, а вот подсчет рейтинга можно и закешировать. Так что тут главное проявить смекалку :)
PS. Когда руки из попы, ничего не спасет :)
Все обычно видят следствие, а я попробую донести причину на 2х примерах.
Пример первый, 2 человека покупают новое авто, один его гоняет на плановые ТО, меняет масло, ремни, запчасти там разные, второй чисто заправляет и что то меняет ровно тогда когда автомобиль встает на прикол, как думаете у кого авто прослужит дольше и кому первому понадобится кругленькая сумма на покупку нового авто?
Второй пример касается технического долга (как и первый конечно), есть понятия технического долга, когда мы программисты в угоду бизнеса плодим костыли (быстрее сдать фичу), эти костыли и есть технический долг (эти костыли когда нибудь надо будет переписать). Так вот технический долг сравним с кредитом. Вот вы взяли деньги в кредит (написали костыли) для дорогой покупки сразу (выпустить что то быстро в продакшен), вы начинаете платить ежемесячный платеж (читай пожертвовали архитектурой проекта, скоростью, связностью, запутаности и соответственно ростом сложности проекта), далее не погасив один кредит, вы берете второй, потом третий, потом четвертый и рано или поздно количество ежемесячных платежей превышает вашу платежеспособность.
Я вот к чему веду, на чем бы вы не написали проект, будь то yii или битрикс или еще что то, вам надо поменять отношение к проекту и работу с подрядчиками. Любой проект станет легаси, просто насколько быстро зависит от отношения заказчика к проекту
Вам же сказали, что это не php блокировки, а блокировка файловая на запись. Тут не в скорости ФС дело, а дело в том, что вы файл открыли на запись и начали делать бэкап, так вот пока бэкап не сделается (вы же не закрыли дескриптор файла), то система не отдаст блокировку.
Сессии в php в своем стандарте очень примитивны, просто пишет в файл, а так в большинстве случаев достаточно сложить их в БД, главное реализовать очистку протухших сессий, но редис тоже вполне пойдет. Либо не дергать session_start для каждого хита.
Тут больший вопрос к самой архитектуры движка, а не к хостингу.
У кувалды тоже есть один большой недостаток, ей неудобно закручивать шурупы.
Если битрикс это гоночный болид, то зачем его использовать на поездку до деревенской дискотеки чтоб потискать местных доярок? Используйте битрикс там, где вам нужен его функционал, не используйте его там где не нужен - все просто. У битрикса есть свои ниши где его вряд ли кто то переплюнет в ближайшее время, если вы не из тех ниш - не используйте.
Я много видел печальных ситуаций, когда не инструмент подбирают под задачу, а задачу пытаются подогнать под инструмент - это боком выходит обычно и не важно битрикс это или не битрикс. CMS тут не при чем, её тоже люди пишут, не скажу что шибко умнее нас с вами, но все же, а вот сайты уже собирают совсем другие люди, которые как правило к битриксу имеют очень косвенное отношение и от туда получается что получается, нашли рукожопа (ну там знакомый, племянник, студенты в веб студии, фрилансер, просто мимо проходил и дешевле всех предложил), он собрал сайт (пофигу на какой системе), рукожопный сайт и получится, Как не крути - другого не дано, какая то другая CMS не защитит от рукожопства.
Покажите мне пожалуйста систему где ничего не надо допиливать - я буду делать все проекты на ней? Для примера о насущем (opencart), добавить товар можно только с окружения админки, при том, чтоб добавить свои поля придется попотеть неслабо git, потому что со стороны магазина есть только выборки, ну и если вы захотите логику немного поменять или полей добавить, вы понимаете сколько всего отгребете.
Вы немного подменяете понятия. В битриксе есть готовые компоненты, бери и пользуйся как есть, ненравится? бери и допиливай, битрикс это позволяет и приветствует. Где по другому? Только у многих в ядре и готовых компонент то нет, там только допиливай или ставь полукривые, непонятного происхождения плагины. Я не говорю что битрикс это верх совершенства, просто я всегда встречаю из разряда "видел, пару кнопок тыкал - не понравилось", у битрикса много боли, но далеко не там где все копают, все что на него выливают в виде цены, маркетинга, партнерки, старого легаси кода и прочее это все просто слабая осведомленность, самое главное что он позволяет запускать большие магазины в короткие сроки - это основное его преимущество. Второе - переносимость своих модулей/наработок. То есть студия напилила свои решения, свои сервера обновлений и поддерживают сотни сайтов клиентов 2-3 программистами.
PS. Забираю про prestashop свой гон обратно (1.7.х), пошел в исходники на гитхаб, а её на symfony 2.8 переписали, когда я её видел последний раз там был полнейший трэш. А делеко ходите не надо, предыдущая ветка вот например моделька престы версии 1.6.х на 6к строк кода, попробуйте туда что нибудь добавить и не сломать ничего.
По аналитике лучше либо roistat либо очень хорошо освоить гугл аналитикс.
Есть еще один очень дорогой вариант, там есть конечно и бесплатный клиент, но внедрение в ваш бизнес очень дорого - qlik
По срм, сложно сказать, нужно знать полностью потребности, амо хороша для отдела продаж, но разве что только для отдела продаж, все остальное надо сверху саморезами приделывать.
