Вадим Казнин

Проверьте число макс. соединений и потоков (процессов на линуксе) MySQL. Сами понимаете, что каждый из требует память.

Проверьте выставленные значения key_buffer_size (исп. MyISAM, один буфер на все потоки), thread_stack (стек нужен каждому потоку), net_buffer_length (свой у каждого потока), read_buffer_size (у каждог опотока свой), read_rnd_buffer_size, sort_buffer, pool_buffer_size, как вам выше написали.

Вообще, MySQL довольно предсказуемая система и ест столько памяти, сколько ей скажут. Ссылочка dev.mysql.com/doc/refman/5.0/en/memory-use.html вам в помощь.

Перестаньте пользоваться нехорошему вещами, вроде JOIN или fulltable row scan на больших таблицах. Они все тоже едят память, да еще как.

В openCart и OsCommerce ф-ция поиска по товарам отрабатывает 8 минут

А в остальном устраивает? Я не в курсе, но подозреваю, что можно туда прикрутить Solr или Sphinx, ситуация должна значительно улучшиться.

Отпишусь пожалуй о своем опыте.

Ситуация схожая, но изначально товаров нужно было 250 кпозицией. Анализ коробочных решений (который не я делал) показал, что либо коробка на таких объемах не может гарантировать быстрой работы, либо производители коробки хотят таких денег на энтерпрайз, что пилить свое дешевле. Собственно чем в настоящее время и занят.

Свое требует времени, но позволяет полностью контролировать движок и быть точно уверенным в нагрузках, которые он потянет. Кроме того гарантирует более выгодную схему модификации движка, т.е. супорт движка становиться проще как технически, так и финансово. А сапорт движка собственно и есть основная статья расхода для ПО. Что удалось получить на данный момент, так это каталог. Т.е. дерево категорий, карточки товара, админка для менеджеров (создать товар, добавить к товару атрибуты). Количество товаров не ограничено, количество и тип характеристик товаров так же не ограничено и ведется через админку (т.е. дополнительно кодить ни чего не нужно). Нагрузочные тесты показали, что при ~200 МБ ОЗУ под PHP движок держит 300 запросов/сек (при попадании в кэш страница генерится за 10-15 мс) долговременно (т.е. где-то до 25 миллионов хитов в сутки) и может держать пик в 1000 запрос, но не дольше 5 сек, потом начинаются валится 50-ые. Это при каталоге в 250 кпозиций по 10 характеристик на товар. В целом вся связка (веб сервер, субд, кэш) кушает 1-1,5 ГБ ОЗУ. При этом полная развязка данных и шаблонов, поэтому можно иметь сколько угодно вариантов верски, т.е. ни какой смеси из php+html нет.

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

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

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

Есть два подхода к разработке:

• медленное протипирование, медленный дизайн, медленная верстка и медленная "натяжка" на WordPress.
  
• Elementor позволяет сократить время прототипирования, верстки и всего остального, сведя эти все этапы в один
  

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

Можно ещё нажать F6 (начиная с версии 12) или Ctrl+L.

Ужас, какие же люди говнистые бывают! Заморачиваться как обмануть вебмастера, который дает ему необходимую информацию.

Сначала делаешь
1. Скачиваете оба архива к себе.
2. У первого архива (который с расширением .gz ) ставим расширение 001.
3. У второго архива (который с расширением .1 ) — ставим расширение 002.
4. И т.д. для всех частей архива

Далее никакого 7-zip. Качаешь Total Commander. Открываешь
Выделяешь все части архива, заходишь в меню "Файлы", там есть функция "Собрать файлы" (как-то так) .
Собираешь архив. После этого выбираешь собранный архив и архиватором Total Commander разархивируешь.

17500 - это ничтожно малое количество записей.
У Опенкарта основная проблема - говнокод на уровне обращений к базе данных. Много запросов в цикле и т.д.
Решается обычно установкой MySQL на нормальную машину с хорошим объемом памяти и SSD, миграцией на InnoDB, анализом запросов и построением необходимых индексов. Кроме индексов необходимо отследить размеры буферов и т.д. В вашем случае объем памяти должен быть в районе от 8 GB RAM. Из решений рекомендую использовать не MySQL, а MariaDB или PerconaDB. Не используйте виртуальный (shared) хостинг.
Еще поищите, есть хорошая утилита mysqltuner, она подсказывает оптимальные характеристики для СУБД.
Включите лог медленных запросов и запросов неиспользующих индексы.
Проанализируйте сетевой стек вашего соединения с MySQL, работа через сокет значительно ускоряет работу приложения. Некоторые горе-мастера выставляют адрес домена, который система переодически ресолвит и это увеличивает издержки на время соединения.
При высокой посещаемости и некритичности актуальности данных используется подход с переписыванием слоя абстракции БД опенкарта с применением кеширования результатов в Memcached. Актуально для высокопосещаемых ресурсов с разного рода предзаказами или проверкой остатков непосредственно при добавлении заказа.

https://www.reg.ru/support/hosting-i-servery/sajty...

Вариант 1

RewriteEngine On
RewriteCond %{HTTPS} =off 
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]

Вариант 2

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

если оба первых варианта не помогли и возникает циклическая переадресация:

Вариант 3

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Первый: да. Еще и скриншоты параллельно снимать можно.
Кстати, за динамические ссылки вас убьют сеошники.

Второй:
1. нет
2. потенциальный бан/пессимизация
3. не сработает, поскольку парсинг давно уже делается через огромный список прокси
4. клоакинг в чистом виде, бан сразу

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