Yoda

Сессии являются простым способом хранения информации для отдельных пользователей с уникальным идентификатором сессии. Это может использоваться для сохранения состояния между запросами страниц. Идентификаторы сессий обычно отправляются браузеру через сессионный cookie и используются для получения имеющихся данных сессии. Отсутствие идентификатора сессии или сессионного cookie сообщает PHP о том, что необходимо создать новую сессию и сгенерировать новый идентификатор сессии. Сессии используют простую технологию. Когда сессия создана, PHP будет либо получать существующую сессию, используя переданный идентификатор (обычно из сессионного cookie) или, если ничего не передавалось, будет создана новая сессия. PHP заполнит суперглобальную переменную $_SESSION сессионной информацией после того, как будет запущена сессия. Когда PHP завершает работу, он автоматически сериализует содержимое суперглобальной переменной $_SESSION и отправит для сохранения, используя сессионный обработчик для записи сессии. По умолчанию PHP использует внутренний обработчик files для сохранения сессий, который установлен в INI-переменной session.save_handler. Этот обработчик сохраняет данные на сервере в директории, указанной в конфигурационной директиве session.save_path. Сессии могут запускаться вручную с помощью функции session_start(). Если директива session.auto_start установлена в 1, сессия автоматически запустится, в начале запроса. Сессия обычно завершает свою работу, когда PHP заканчивает исполнять скрипт, но может быть завершена и вручную с помощью функции session_write_close().

Оптимизировать магазин, начиная от базы, заканчивая конфигом nginx.

Скажите, а зачем вы эту дичь вашу сюда занесли?

Дружище, у меня в кейсе порядка 500-600 очень быстрых проектов, среди которых магазины с несколькими миллионами товаров и посещаемостью в полсотни тысяч уникальных посетителей в день. Так вот.Я тебе обстоятельно заявляю Gtmetrix - никакого отношения не имеет к гуглу. И к Яндексу. Это исключительно приблуда, которой сеошники-аферисты раззодят клиентов. Так что с такими советами. ДАЖЕ НЕ ДУМАЙ СПОРИТЬ С УВАЖАЕМЫМИ ЛЮДЬМИ! Иди сходи на профильные форумы, на коворки фрилансы, и там разводи кроликов. А если хочешь со мной поспорить, вступить в дискуссию, покажи проект к которому ты имел дело и там есть хотя бы 10к хостов в день, потом может и поговорим! А то развелось нищебродов-специалистов с кейсами ниже плинтуса. И да ЧСВ - это мое все.

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

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

Я с вас со всех худею дорогая редакция. Откуда столько глупостей в голове? 1. Если падает сервер и не срабатывает sheduled task - надо просто менять сервер. 2. Любые хранимые процедуры, триггеры и таски в базе - в конечном итоге оборачиваются некой головной болью при смене окружения, особенно если используется shared хостинг. 3. Нет принципиальной разницы это cron скрипт php, cron команда mysql или bash скрипт. Это все серверные пережитки и они все обладают одним большим недостатком - при смене окружения, паролей в базу, пользователя базы, про них можно случайно забыть. 4. Если делать совсем дубово в рамках идеи opencart - надо делать какой то шедаллер в виде событий при инициализации генераций страниц с файлом или записью базы содержащими временную метку последнго успешного события. Если вы уверены в своих силах и втом, что вы не забудете перенести кроны - крон. Если знаете как решить потенциальные проблемы с пользователем, от которого работюат триггеры и процедуры - делайте в базе. В том или ином виде задача решается однозначно и малыми костами. Просто кому то удобно за 10 минут скрипт сваять, а кому то в базу пару запросов воткнуть. Единого верного решения здесь быть не может. Следуйте принципу write less do more и будет вам счастье!

UPDATE table SET table.field = table.field + 3 не годится? Ну и если правильно погуглить то видим по заросу cron mysql query Первая же ссылка на стаковерфлоу и очень простое решение задачи personally find it easier use MySQL event scheduler than cron. Enable it with SET GLOBAL event_scheduler = ON; and create an event like this: CREATE EVENT name_of_event ON SCHEDULE EVERY 1 DAY STARTS '2014-01-18 00:00:00' DO DELETE FROM tbl_message WHERE DATEDIFF( NOW( ) , timestamp ) >=7; and that's it.

школоло лайнэдж детектед. Лучший гарант - репутация. Когда при вопросе о предоплате, нет аргументов. В репу школавеб текст кидало = школавеб не получит заказов!

А толку от него. sql запросы ограничены, просто взять и взять пихнуть в индекс базу не выйдет. Конфликтов с любым дополнением не оберешься. Любой фильтр в целом на категории до 5к товаров настраивается и с mysql базой. Как и любой магазин до 200-300к. Менять архитектуру хранилища, жертвуя совместимостью имеет смысл только в очень специфических случаях, когда вы будете уверены, что в любой момент сможете помочь клиенту со сторонними расширенями. Проблемы с индексацией начинаются где-то с 100к товаров, и зачастую их решение - это какие то не то что костыли а КОСТЫЛЮГИ! Чтобы подружить любой фильтр - надо как минимум написать самому фильтр. Поэтому там где не надо 50к товаров в одной категории, разворачивать сфинкс под каталог - это просто садить на иглу потенциального заказчика. Намного утилитарней, проще и эффективнее, сделать сводные таблицы (исключив лишние джоины) и расставить правильный порядок таблиц в запросе, как в фильтре у маэстро @SooR, так как в итоге это решение, в котором может разобраться любой разработчик.

mysql> SELECT COUNT(*) as qty FROM product; +---------+ | qty | +---------+ | 1871817 | +---------+ 1 row in set (0.02 sec) mysql> SELECT id FROM main ORDER BY name DESC; +---------+ | id | +---------+ | 5989213 | | 6091563 | | 4350213 | | 4350196 | | 4350195 | | 4350197 | | 4350194 | | 4350192 | | 4350191 | | 4350193 | | 4350190 | | 4350217 | | 4350216 | | 5827378 | | 5827377 | | 5827376 | | 5827375 | | 5827374 | | 5827373 | | 5827372 | +---------+ 20 rows in set (0.16 sec) Но у вас так не получится! Сфинкс не всем раскрывает свои загадки!

Да проверка скорости вам все правильно показала. Но кешировать html, который по сути динамический - ЗАЧЕМ ? Ну там же в ваших инструкциях достаточно понятно все!

Устраиваем новогодний флешмоб. Есть всякие дурдомы, детские дома, коты бездомные и еще куча живых существ, которые сами не очень могут себе помочь. У вас тут у всех все хорошо, мясо в холодильнике, новые адики на ногах. Давайте делиться. Делайте праздник тем, кто не может его сделать сам. И отчеты в телеграм в @opencarpchat! Кто не сделает ни одного доброго дела до нового года тот редиска!

слушайте ну вот это ExpiresByType text/html "access 3 month" Вы реально кешируете в браузере html у пользователя. Естественно ничего не будет работать! мало того, подобная конструкция в принципе будет косячить у вас всю работу магазина!

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

https://www.mail-tester.com/

Ничего не дает в этой ситуации. Кроме снижения нагрузки на базу, необходимо еще и устранять паразитный трафик. И корректировать индексацию. Хостинг - не нормальный. У нормальных хостеров нет phpmyadmin c доступом в базы всех клиентов и стажеры не сидят в чатах.

Разбираться с сайтом, чтобы он не падал!

А где же ваш буст? Рекламный пшик ?

Это на курсах личностного роста такой бред рассказывают. Верьте им и дальше плачьте и нойте как у вас плохо все в жизни. Еще всем я думаю будет интересно как у вас там с женой, или с мужем. Давайте расскажите сколько раз у вас в день и сколько вы там оплачиваете. Это всем нужно! Я просто предложил ответить за свои слова.

Вы же там бедны, денег у вас нет.. Неудачный бизнесмен судя по всему... Ваше мнение ничтожно , так как вы не умеете зарабатывать деньги, а только умеете ныть. Но несмотря на это я отвечу. Представьте что у вас гемморой, вы сидите и у врача и у вас пылает задний проход. А вам какой-то молодой интерн советует аспирин. А он не поможет. Заведомо непоможет. Но вы слушаете его и еще страдаете пару дней. Я считаю что такие советчики должны гореть в аду. А те кто их поддерживают, жариться в аду в отдельном котле с повышенной температурой. Тут развели дилетантсво. Никто не ценит вопрос простоя магазина с оборотом в миллион в полдня, делают проверки лицензий и сервера лежат, дыры зашивают. Таким бедным и неудачливым как вы, я понимаю, все равно, вы все равно профукаете ваши инвестиции и пойдете работать на дядю. Но есть несколько иной уровень ответственности, который вашему пониманию не доступен и никогда не станет доступен. Так что не меряйте все по себе - сидите в сторонке клянчите и нойте потихонечку, может найдутся те кто проникнется и будет вам за три копеечки помогать.

Что касается непосредственно темы топикстартера. Проблема кроется скорее всего в трех моментах, либо у него установлен кривой модуль компресор от сссистекриатора с кривым кешем webp, который не очень дружит с датами и головой и вызывает подобные проблемы,либо у него стоят длинные сессии, либо некорректная настройка системного кеша и кешей установленных модулей. По всем косвенным признакам - это проблема garbage collection. Предугадывая гипотезу о хостинге. Если бы на хостинге была такая же проблема у всех - оттуда все разбежались. А учитывая что подобных инцидентов я вылечил наверное сотни две и ни разу не было проблемы с хостингом, то на 99.9% я уверен что проблема локальная в движке.

Это у вас была, а я утверждаю, что вы несете бред и пишите некомпетентные комментарии. И могу за это ответить 50 000 рублями. Соответственно, вы или признаете что вы оставили глупый бредовый комментарий и абсолютно некомпетентны, либо ставите 50 000 рублей, чтобы доказать обратное. А отмазки. Пойдите к неосео с ними. Это же проблемы @dinox глоабальные. Он развел тут полное отсутствие экспертизы. Какие-то дилетанты несут дикую чушь... А люди должны вас слушать и все это жрать. С какого перепугу ?

Давайте тысяч на 50 рублей заспорим, что это не хост.

Может не будете говорить глупости? У подобного поведения системы может быть десяток причин не связанных с хостером.