HTTPS по своей природе медленнее, чем HTTP, так как к обычному HTTP протоколу добавляется еще и шифрование.
При этом само шифрование еще пол-беды, главное падение скорости происходит про установке соединения. Если при обычном протоколе клиент сразу шлет HTTP GET (или другой запрос), то при HTTPS вначале шлется запрос HTTP CONNECT, который устанавливает TCP-соединение, затем просходит обмен ключами (в спецификации SSL его называют "handshake", или "рукопожатие"). Этот обмен и приводит к основной затрате времени - как процессорного, так и реального.
Сделать можно мало что. В любом случае HTTPS будет медленней HTTP. Для того, чтобы ускорить, можно попробовать следующие идеи:
1. Использовать более мощный процессор - ну это из серии "капитан очевидность", конечно, но в данной ситуации вполне логично.
2. Можно использовать более короткий ключ асимметричного шифрования - именно ассиметричного, симметричное шифрование и так быстрое для современных процессоров. Однако, скорее всего, ключ и его размер вы приобрели у центра сертификации, так что этот вариант может требовать покупки другого ключа. Кроме того, более короткий ключ будет и более криптографически слабым. Так что этот вариант скорее теоретический.
3. Для ускорения работы сайта с реальными пользователями, используйте HTTP-заголовки кеширования, например, Expires, однако, я не уверен, что боты, которые определяют быстродействие сайта, учитывают эти заголовки.
Сомневаюсь, что кого-то в гарантийке парит закон. Часто не ведутся признавать гарантийными даже явные поломки вроде сгоревшей видеокарты, не то что монитор, от которого болят глаза.
Печально, но не верится, что гарантийка тут поможет, только время потратишь. А экспертиза часто стоит дороже, чем само устройство, и ее результат тоже не очевиден. Плюс вопрос, кто будет экспертизу проводить - самое смешное, что у ментов может просто не быть эксперта, и они дадут делать экспертизу твоему же гарантийщику - даже такие случаи бывают.
Ты прав, коллега.
Но действительно, страниц у тебя на сайте много, и решения два:
1. Либо переписать часть кода на уровне PHP - это действительно самое лучшее решение, но оно влетит в копеечку.
2. Либо действительно через .htaccess, но в любом случае этот выход менее элегантный.
Попробуй что-то вроде такого:
RewriteRule "(.*?)/(by,product_name|by,product_in_stock)$" "/$1" [L,R=301]
Это правило будет переадресовывать все URL, который заканчиваются на by,product_name и by,product_in_stock на аналогичные без этих окончаний. Подредактируй это правило под свой сайт. Могут быть и другие окончания, все 18000 ссылок я не просмоатривал.
Судя по теме, автор - не программист и переписывать PHP врядли будет. А без этого добиться удаления дублей надолго врядли выйдет.
TF-Studio, я понимаю, что ты на этом форуме рекламируешься и стремишься казаться профессионалом. Пишешь в темы, касающиеся разработки или администрирования веб-сайтов, и стремишься заполучить заказ. Все мы люди и у каждого свой способ (само)рекламы.
Но все же жизненный совет, веди себя более корректно, врядли клиентам нравятся люди, которые пытаются сделать себе рекламу нападками на коллег-форумчан.
Возьмем для примера вот эту страничку:
/index.php/shop-store/monetnicu/steklopalstikovye-monetnitsy/
Её дубли будут, к примеру, эти:
/index.php/shop-store/monetnicu/steklopalstikovye-monetnitsy/orderDesc
/index.php/shop-store/monetnicu/steklopalstikovye-monetnitsy/by,product_name
Чтобы отфильтровать эти дубликаты, в robots.txt можно добавить:
Disallow: /index.php/shop-store/monetnicu/steklopalstikovye-monetnitsy/*
И так для каждого дубликата. robots.txt - файл довольно простой, и сложный фильтр с его помощью не описать.
Чтобы не мучиться с ручным управлением 18 тыс. страниц, есть смысл написать PHP-скрипт, который бы генерировал robots.txt "на лету" или обновлял его расписанию через cron.
Выложи примеры дублей, чтобы можно было ответить. Так как ссылки могут генерироваться разными компонентами и по-разному выглядеть.
Новичок - это сколько лет стажа?
Я пользовался Джумлой лет 5 назад. Тогда ее плюсами были большое количество компнентов и удобная админка. Главный минус был быстродействие (просто ужасно тормозила) и недостаточно документирована. Всяких туториалов по ней была куча, а вот хорошего системного изложения, как у Друпал, явно не хватало.
В итоге написал свою приватную CMS. Думаю, многих PHP-сты приходят к такому решению.
Я такое делал путем написания скрипта на ASP.NET, но если БД не суперсложная, то можно и через экспорт. О версии MSSQL, можно попробовать SQL Server Express 2008 with Advanced Tools, он официально бесплатный, можно скачать у Майкрософта: https://www.microsoft.com/en-us/download/details.aspx?id=1842
Конечно, если БД с ним совместима. Последние версии этого сервака не поддерживают Windows 7 и 32-битные системы.
Определение ботов - это как войне, нет однозначного ответа, ведь автор бота делает все, чтобы его не поймали.
Простые методы против простых ботов - проверяйте, интерпретируют ли ваши посетители JavaScript, загружают ли рисунки и CSS и т. д.
Думаю, что раздел "Роботы" в IP-статистике определяет "легальных" ботов по юзер-агенту, и, конечно, ботов для накрутки он не определит.
Более продвинутые методы - это определять, двигает ли ваш постетитель мышью, и вообще как он себя ведет - так борятся с ботами "большие мальчики".
