sitecreator
-
Публікації
6 116 -
З нами
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Усі публікації користувача sitecreator
-
да, есть. Если вам удобно хранилище амазона S3, то, пожалуйста, без проблем. Думаю, что подавляющему большинству юзеров будет достаточно делать бекап по фтп (sftp) в хранилище, которое можно взять у того же хостера, который предоставляет хостинг VDS. Так и есть. И никаких ограничений по кол-ву доменов/поддоменов. Работает все довольно стабильно. Есть более продвинутый файловый менеджер если сравнивать с ISPmanager. Если говорить про работу с хранилищами для бекапов, то у ISPmanager будет преимущество, т.к. она умеет работать с любым хранилищем S3, а в aaPanel - пока только с амазоном, т.к. жестко зашит url обращения, но, думаю, что это вопрос времени. Да и в 90% случаев все пользуются фтп-хранилищами от провайдера, а многие вообще забили на бекап, хоть это неверно совсем. Будут вопросы - задавайте. Я работал с очень разными панелями. Поэтому довольно хорошо знаю отличия. Разумеется, что все их нет смысла добавлять в описание. Но тонкости про S3 я написал. Если чего-то будет не хватать по сравнению с ISPmanager, то хотелось бы услышать чего именно. Я пока не нашел ничего принципиального, что могло бы заставить оставаться на ISPmanager. Безусловно, что у ISPmanager есть преимущество - ее знают все поддержки любых хостеров, а потому по возможности вам всегда поможет поддержка хостинга. Но если вы сами ставите панель управления, то тут уже нужно рассчитывать на свои силы или на вашего специалиста, который работает с вашим проектом/сайтом. -
Восстановить БД при необходимости из архива backup-а:
-
Уже добавил подробное описание. Как получить ключ для Google Drive также могу подробно расписать если это нужно. Но, пожалуй, описание получения ключа займет больше места и времени чем описание самой процедуры бекапа в aaPanel. Прошу оценить насколько понятно и подробно я осветил данный вопрос. Все же старался для людей. Особенно учитывая, что толком документации по этому вопросу нет, а подводных камней и ошибок хватает.
-
можно. постепенно все подробно опишу как. Главное - это чтобы был интерес к теме. Пока, как видите, тему намеренно минусят в оценке. Или моя информация, действительно, никому не нужна или сильно страдает подача материала. Если информация полезна для вас и нужна еще более подробная информация, то можете заявить об этом своей оценкой блогу (звездочки) и лайком.
-
@alinalessioYandex у вас в настройках сняты галочки. потому и перестали создаваться.
-
не имеет значения каким модулем они выводятся. преобразование в webp от этого не зависит. причина в другом, например, может быть закрыта запись в какую-то папку. Лучше пишите в личку сразу с доступами.
-
Есть еще один момент, который если не учитывать, то можно "наизмерять" совсем неверные параметры скорости сайта. Дело в том, что по-умолчанию для сайта работает дефолтный профиль, который ограничивает принудительно скорость передачи данных (пропускную способность) с сайта очень низкой величиной. Это приведет к тому, что общее время загрузки файла может существенно возрасти, не смотря на то, что параметр TTFB при этом будет хорошим. Т.е. будет увеличенным параметр Content Download. На такой существенный нюанс можно и не обратить внимания, да и в официальном описании разработчика вы не увидите описания того, на что влияет этот параметр. Без ограничения ситуация выглядит значительно лучше, т.к. как "стало в два раза быстрее". А в случае Апачи или Nginx по-умолчанию не будет никаких ограничений. Т.е. чтобы получить корректные результаты измерений нужно все же учитывать некоторые мелкие моменты, которые вы не заметите если будете оценивать ситуацию лишь поверхностно. Вариант "быстро установил и пошел тестировать LiteSpeed" также быстро может привести к неверному заключению и разочарованию. Кстати, параметр скорости Content Download зависит еще от нескольких параметров, вплоть до используемого браузера. У меня есть сомнения, что в этой теме, действительно, найдется много специалистов, глубоко разбирающиеся в подобных тонкостях.
- 84 коментаря
-
- 1
-
-
- linux
- cyberpanel
- (і ще %d)
-
Я нигде не писал, что он лучше. Я не знаю почему у вас сложилось такое впечатление. Какое мое сообщение приводит к такому выводу? Я еще мог бы предположить, что возникает мысль о некоем равенстве возможностей, но почему может появиться мысль о превосходстве litespeed над NGINX - этого не могу понять. Я рассматривал litespeed при условии, что необходима поддержка htaccess. Если заказчик осознанно ставит такое условие, то приходится с ним считаться. Примеры когда это, действительно, необходимо я показывал выше. Т.е. получается, что litespeed - это не худший вариант как здесь пытались заявлять? И сайты могут все же быть быстрыми на litespeed? Даже с использованием php? Согласитесь, что все же не очень то компетентно выглядят некоторые заявления, что litespeed - это "худший вариант из всех возможных"?
-
Все же переход от nginx+apache к LiteSpeed самого крупного хостинга Украины заставляет задуматься, что сделали они это не просто так. С их опытом и статистикой, думаю, что они разбираются получше нас с вами. Или вы считаете, что они не делали всевозможные тесты, не собирали месяцами статистику с десятков тысяч сайтов? Ведь что-то их побудило к такому переходу? Т.е. можно предположить, что, как минимум, для них LiteSpeed работает не медленнее чем nginx+apache. А зачем же менять шило на мыло? Что-то же они должны были получить в итоге полезное? Думаете, что выигрыша не получили? А зачем тогда перешли? Я могу сделать вывод, что они пришли к выводу, что в их высоконагруженных условиях LiteSpeed справляется лучше. Или вы допускаете мысль, что они намеренно выбрали более тормозной вариант? Тогда в чем профит такого выбора для провайдера? Тут же престиж и хорошие отзывы о работе компании будут на первом месте? К чему бы им рисковать и ставить что-то заведомо худшее? Вот как-то не вяжется этот осознанный выбор (отказ от nginx+apache в пользу LiteSpeed ) крупнейшего хостинг-провайдера с "самым худшим выбором". Лично у меня нет такого большого опыта с тысячами сайтов чтобы делать далеко идущий вывод о LiteSpeed . Разумеется, что я вначале с сомнением и опаской отношусь к отказу от "классики" в виде nginx+apache. Но могу судить на своем небольшом опыте, что в случае LiteSpeed сайты не стали работать медленнее. А с чистым NGINX работаю много лет. И всегда его советую если есть возможность полного отказа от htaccess и нет проблем с удаленным доступом к серверам 1С из некоторых программ, которые построены исключительно под Апачи. Поэтому агитировать меня за NGINX не нужно, я всеми руками только за, и был в первых рядах за него когда еще известный форумный борцун "против всего плохого" был против NGINX.
-
в том то и дело, что выключено в nginx по-умолчанию. Вы используете open_basedir совместно с nginx? В панелях управления даже такой опции нет для nginx. Чтобы включить нужно специально прописывать конфиги. Но этого практически никто не делает, т.к. и нужды в open_basedir нет. И для чего сравнивать в режиме, который в 99% случаев не используется и в принципе для опенкарт не нужен? Если выбрали опенкарт, то и настройки окружения должны быть соответствующие, но не излишние. К слову , Битрикс категорически предупреждает о важности отключать open_basedir для нормальной работы. Если сравнивать с включенным open_basedir, то в таком случае с apache или nginx+apache тоже с включенным open_basedir. Выражаясь вашими словами, то в apache или nginx+apache будет все "вообще печально" в таком случае. Только почему-то странным образом apache или nginx+apache - это не самый худший вариант в плане скорости, а litespeed - самый худший? Где логика? То, что nginx будет впереди планеты всей, это я всегда говорил. Но если вам нужен непременно поддерживаемый .htaccess, то у вас будет выбор: apache nginx+apache litespeed Т.е. вы не сможете использовать NGINX если вам нужен непременно htaccess. Что важно конечному пользователю? Ему важна работа его реального сайта и важен конечный TTFB, т.е. отклик. Ранее было довольно странное заявление о невозможности создать на litespeed быстрый сайт, что не соответствует истине. Я показал, что можно если брать мерило в виде TTFB. Что не так? Вы не находите нелепым утверждение, что на litespeed быстрым может быть только HTML, но не сайт с использованием php? Если подходить с такой же жесткой позицией к apache или nginx+apache, то на них, получается, что тоже невозможно создать быстрый сайт? Но, однако, на nginx+apache есть полно быстрых сайтов. Владельца сайта обычно интересует увидит ли он реальный прирост производительности при переходе на чистый NGINX. Вот его интересует то, что он может увидеть глазами. А увидит он TTFB. Т.е. я говорю о том, что довольно нелепое было высказывание насчет якобы тормознутости litespeed на фоне таких же тормознутых вариантов как apache или nginx+apache. смелое предположение. Но это лишь ваше предположение. вы вполне можете ошибаться в "несколько раз", не думаете? Посмотрите на этот анализ: https://blog.herecura.eu/blog/2020-06-16-openlitespeed-vs-apache-vs-nginx/ И, еще раз, я рассматривал litespeed как альтернативу для: apache nginx+apache Т.е. для случая, когда NGINX не может быть использован по причине необходимости обработки htaccess веб-сервером. Пожалуйста, не стоит забывать об этом важном условии. Не надо пытаться приписывать мне заявление о превосходстве (или полном равенстве) litespeed над NGINX. Но когда пишут нелепости, что litespeed - это якобы худший выбор (при обязательном использовании htaccess ), то это уже явный перебор в необъективности.
-
Backup файлов сайта и его базы данных Допустим, что вы решили в качестве хранилища использовать Google Drive. Сначала установите соответствующее расширение для панели управления aaPanel . У вас должен быть в наличии ключ для google drive. Как его получить - это отдельная тема, опишу это тоже подробно. Итак, ключ есть (это файл с расширением .json). Делаете импорт ключа, т.е. просто его как файл загружаете с вашего ПК. Далее переходите по ссылке, которая указана как 3-й шаг. (2-й шаг не нужен). Входите в ваш аккаунт гугла если еще не вошли, далее даете разрешение сервису aaPanel-GDrive. Потом вас ждет сюрприз в виде попытки перехода браузера непонятно куда и вываливанием ошибки. Тут господа разработчики просто не доработали. Пугаться не нужно, ошибка не страшна. Хотя я потратил несколько часов чтобы понять что же это означает. Могли бы разработчики где-то предупредить об этом, тем более, что на Centos 7 установка google drive завершалась появлением на пару секунд пустого информационного окошка с красным (предупреждающим?) знаком, что сразу наводило на мысли, что проблема была на этапе установки. ВАЖНО IMPORTANT Будет сообщение об ошибке в браузере. Так и задумано. Не волнуемся. Просто читаем внимательно текст выше и смотрим скриншоты. Нужно просто скопировать из адресной строки ссылку полностью. Да, в ней есть "localhost". И вставить эту ссылку в окошко 5-го шага. Подтверждаете. Верификация удачно пройдена. Создайте задание cron для backup. Исключите папку кеша изображений: Код: image/cache И другие папки, копировать которые не имеет смысла по вашему мнению. Кеш всегда сам восстановится, но в backup-е он занимал бы напрасно слишком много места. После создания задания запустите его. После запуска вы увидите всплывающее окошко "Успешно запущено", которое через пару секунд исчезнет. Чтобы понять что происходит и насколько успешно нужно нажать "Log". Тогда увидим, что успешно создан архив файлов для сайта. В вашем аккаунте google drive вы увидите архив сайта, который можете скачать и проверить. Можно убедиться, что в архиве есть нужные папки, а исключенные не попали в архив. В моем примере вся папка image была целиком исключена из архива. Бекап базы данных. Задание cron будет аналогичным как для файлов. Время начала измените чтобы оно не совпадало с временем начала бекапа файлов, это желательно. Восстановить БД при необходимости из архива backup-а:
-
Создание сайта/домена. Создайте через dnsmanager (данные для доступа предоставляет провайдер) соответствующие записи для домена. Выбирайте "master". Внесите название домена и IP вашего сервера. Удобно сразу создать соответствующий FTP аккаунт и базу данных (пользователь и название БД будут совпадать) Поставьте нужные редиректы: для домена с www на домен без www на HTTPS с HTTP (если выбрали создание SSL) Если сертификат не был создан сразу, то можно сделать это позже. Бесплатный сертификат будет автоматически продлеваться. Чтобы сертификат автоматически продлевался необходимо чтобы была включена соответствующая cron-задача. По-умолчанию эта задача выключена. Включите ее. Статус должен быть Enable. Если забыть это выполнить, то вы рискуете пропустить момент когда закончится действие сертификата SSL и сайт окажется недоступным в таком случае. Должно быть так: Чтобы работали ЧПУ для опенкарт нужно в конфигурацию nginx для сайта добавить: Код: location / { try_files $uri $uri/ @opencart; } location @opencart { rewrite ^/(.+)$ /index.php?_route_=$1 last; } Также необходимо закрыть от доступа некоторые типы файлов и папки. Это также прописывается в конфиге. Нужно также добавить в конфиг статические файлы webp и шрифты, и назначить для них время жизни кеша браузера 30d (желательно не меньше). Стат. файлам js, css по умолчанию задается 12h, замените на 30d. rewrite правила для конкретного сайта можно внести на отдельной вкладке настроек сайта. Все эти правила сохраняются в отдельном файле конфигурации. Немного позже я добавлю как пример полный вид файла конфигурации здесь. Кстати, ранее на этом форуме я уже приводил варианты конфигурации NGINX для opencart.
-
Установка на примере Centos 7 Код: yum install -y wget && wget -O install.sh http://www.aapanel.com/script/install_6.0_en.sh && bash install.sh После завершения установки получим сообщение с данными для доступа в панель управления. Скопируйте эти данные. Во время установки было получено сообщение: Код: Requirement already satisfied: cachelib in /www/server/panel/pyenv/lib/python3.7/site-packages (0.1.1) WARNING: You are using pip version 20.3.3; however, version 21.1.3 is available. You should consider upgrading via the '/www/server/panel/pyenv/bin/python3.7 -m pip install --upgrade pip' command. Воспользуемся советом и обновим pip3 до 21.1.3: Код: /www/server/panel/pyenv/bin/python3.7 -m pip install --upgrade pip Далее осуществляем вход в панель управления по предложенной ранее ссылке: При первом входе будут предложены быстрые варианты установки: Рекомендуется выбирать NGINX. Но вы в любой момент можете изменить веб-сервер. Сервер БД предпочитаю MariaDB. Кстати, есть делать установку необходимых компонентов отдельно, а не из начального окна, то будут доступны более свежие версии софта. Например, Nginx будет доступен 1.21 вместо предлагаемого на стартовом экране 1.19. Установите отдельно необходимые версии PHP. Сделайте настройку php для каждой версии отдельно, подключите необходимые расширения, хотя все необходимые для опенкарт уже включены по-умолчанию. Но в списке возможных расширений imagick не значится, к примеру. Профиль FPM можно оставить пока по-умолчанию. Но в зависимости от реальной нагрузки и параметров сервера можно менять параметры настройки FPM. При смене настроек PHP нужно перезагружать PHP. После смены настроек PHP нужно перезагружать PHP.
-
aaPanel Описывая возможности панели управления aaPanel буду временами сравнивать ее с другими панелями управления. Не ставлю целью категорически выделить лучшую панель управления и/или операционную систему и/или лучший веб-сервер. Предоставляю самостоятельно делать окончательный выбор. Если я что-то описываю, то это не обязательно означает, что я описываю собственные предпочтения и даю рекомендации использовать вот именно "то, а не это", скорее всего, это будет анализ собственного опыта, в том числе анализ ошибок (ошибочного выбора). Без практического опыта и практического сравнения невозможно заранее точно понять, что же окажется самым удобным и самым быстрым (производительным). Поэтому я выбрал вариант "пощупать" разные панели управления VDS/VPS под разными ОС Linux, и уже потом решил сделать более осознанный окончательный выбор на основе сравнения возможностей, удобства, глючности (точнее - отсутствие оных), требовательности (прожорливости) к ресурсам и т.п. Поэтому даже не вполне удачные конфигурации я также описывал и описываю. Итоги и выводы будут позже. Пока могу сказать, что выбор aaPanel видится более предпочтительным по сравнению с CyberPanel. Кстати, нередко люди делают поспешные и необоснованные выводы, не разобравшись толком в вопросе. Бывает, что делают просто некорректное сравнение разных веб-серверов в заведомо неодинаковых условиях. Просто пример. Веб-сервер Apache (или Nginx+Apache) может оказаться с включенным по умолчанию open_basedir, что сильно сказывается на производительности и буквально увеличивает время отклика (TTFB) в два раза. Но некоторые упорно будут сравнивать отклик такого сервера с веб-сервером NGINX, в котором не будет open_basedir. В итоге сравнение будет некорректным, а результат для одного из тестируемых занижен раза в два. К веб-серверу OpenLiteSpeed точно также относится правило "отключите опцию open_basedir защиту" прежде чем делать делать сравнительный тест с Nginx. В случае aaPanel эта опция для OpenLiteSpeed будет включена по-умолчанию, поэтому тест вам даст отклик сервера в два раза медленнее чем это возможно без open_basedir. В aaPanel для Apache не используется open_basedir. Поэтому когда слышишь что-то вроде "Да OpenLiteSpeed - это тормоз по сравнению с NGINX", то хочется спросить: "а вы тестировали OpenLiteSpeed с включенным open_basedir, но NGINX - без него, верно?" Почти всегда NGINX будет быстрее чем OpenLiteSpeed, это верно. Но все же смотрите реальную разницу в цифрах чтобы понять насколько она значима. Панель aaPanel позволяет сделать вполне объективное сравнение 3-х вариантов веб-серверов для вашего сайта. Забегая вперед скажу, что по производительности все три варианта будут примерно на одном уровне если брать для сравнения параметр TTFB (отклик сервера, т.е. время до передачи начального байта), но это при условии отсутствия стресс-нагрузки, т.е. при единичном посетителе одновременно. Почему Apache будет в этом случае на одном уровне с NGINX? Это потому, что будет использован Apache + php-fpm. Но тест при одном условном посетителе не позволит сравнить в полной мере NGINX и Apache, но позволит лишь в первом приближении сделать сравнение. Полная документация на панель управления: документация aaPanel Панель управления бесплатная. Поддерживает выбор конфигурации веб-сервера и PHP. Возможные варианты веб-сервера и PHP: Nginx + php-fpm Apache + php-fpm OpenLiteSpeed + LSPHP С точки зрения производительности самый интересный вариант - это Nginx + php-fpm. Для каждого сайта возможно использование своей версии php. Операционные системы Linux, которые поддерживает aaPanel: Ubuntu 16.04 / 18.04 / 20.04 Debian 9+ Centos 7 / 8 Набор дополнительных возможностей в aaPanel зависит от операционной системы. Самый большой выбор дополнительных функциональных возможностей будет при установленной Linux Centos 7. Это не означает, что Centos 7 чем-то превосходит остальные ОС, просто это особенность данной панели управления. Различные панели управления тяготеют в той или иной степени к тем или иным ОС. Например, в случае панели управления ISPmanager также наблюдалась поддержка в первую очередь Centos 7, т.е. новый функционал появлялся сперва именно для этой Linux, потом - для остальных. В любом случае выбор дистрибутива Linux (FreeBSD или иной вариант UNIX) - это дело вкуса и привычки, и опыта . Но учитывайте, что некоторая (небольшая) часть дополнительных приложений для aaPanel рассчитана только на Centos или Centos / Ubuntu. Основной же функционал одинаково работает на любой из поддерживаемых ОС Linux. При прочих равных имеет смысл всегда смотреть в сторону наиболее свежего дистрибутива (с более свежим ядром соответственно) и одновременно не забывать о долговременной поддержке разработчиком того или иного дистрибутива. UPD от января 2022. Замечу, что панель управления активно развивается. То, что несколько месяцев тому назад было доступно для ограниченного набора ОС, то теперь доступно для всей линейки поддерживаемых ОС. По сравнению с панелью управления CyberPanel панель управления aaPanel выглядит более гибкой и удобной. Во-первых, вы можете с aaPanel переключать при желании (ради тестов и т.п.) тип сервера с одного на другой без переустановки сайта. Менеджер файлов Менеджер файлов в отличие от CyberPanel в aaPanel позволяет работать с любыми папками, а не только с папками сайтов. Можно всегда посмотреть суммарный вес всех файлов папки, что довольно удобно. Например, в той же панели ISPmanager нет кнопки для просмотра размера всех файлов в папке. В aaPanel нет проблем с кириллическими названиями файлов. Отдельным недостатком файлового менеджера aaPanel можно назвать отсутствие для браузера FireFox использовать режим перетаскивания drag & drop, но в Crome это работает. В ISPmanager 5 такой функции нет совсем. Корзина. Корзине стоит уделить отдельное внимание. По-умолчанию все удаляемые файлы помещаются в корзину. В ISPmanager, к примеру, корзины нет. Такое поведение по-умолчанию может быть неудобно, т.к. может быть съедено бесполезными файлами пространство жесткого диска. Вы можете отключить корзину. Кнопка корзины всегда присутствует в файловом менеджере. Правда если корзину отключить, то удаление файла превращается в "интеллектуальную задачу", т.к. файловый менеджер начинает вам подкидывать арифметические упражнения, правильно решив которые вы можете удалить файл. Где изменить такое поведения я не смог пока найти, т.к. в основных настройках панели управления нет чего-то подобного, переключение настроек на "develop mode" вопрос не решает. Зачем в панели управления такой квест пока непонятно. Импорт и экспорт в БД В отличие от CyberPanel в aaPanel есть удобный функционал импорта/экспорта данных в базу данных и бекапа (backup) БД. Такой функционал также есть в ISPmanager. Это позволяет не использовать для этого PHPmyAdmin, который делает подобные операции крайне медленно, а из-за лимита времени (на выполнение php) может не завершиться за один проход импорт большого файла SQL. дописываю и добавляю описание ...
- 91 коментар
-
- 11
-
-
Для теста была использована база товаров реального магазина, в указанной выше теме она использовалась для тестов фильтра. Надо сказать, весьма недурного фильтра, необоснованно и голословно обруганного некоторыми господами, которые даже не пожелали разобраться и понять его особенности. Т.е. с порога фильтр был назван "тормозным". Какие были аргументы? Да никаких! Точно также и в этой теме прозвучало категоричное заявление о невозможности "создать быстрый сайт" на OpenLiteSpeed. Заявление, мягко говоря, сомнительное и ничем не подтвержденное. Я оперирую только цифрами. Реальными цифрами на реальных магазинах. Лучше ли будет чистый NGINX по производительности? Да, будет лучше. Но и OpenLiteSpeed позволяет работать магазину на опенкарт довольно шустро.
- 84 коментаря
-
- 1
-
-
- linux
- cyberpanel
- (і ще %d)
-
Сравнение NGINX + PHP-FPM vs LiteSpeed + LSPHP Использовались для теста VDS с одинаковыми параметрами: 1 ядро 2.4 ГГц, 2 Гбайт памяти, 20 Гбайт диск SSD, ОС Linux Centos 7.9 PHP 7.2 Для веб-сервера Nginx+php-fpm использовалась панель управления aaPanel. Для OpenLiteSpeed +LSPHP - CyberPanel соответственно. Была использована база товаров реального магазина на 17 000 позиций. Измерялся параметр TTFB для: главной страницы страница Категория на 15 товаров страница Категория на 100 товаров OpenLiteSpeed NGINX Итак, результат. Ожидаемо, что NGINX+PHP-FPM оказался несколько быстрее. Нужно также учитывать, что это был т.н. "спокойный тест", т.е. когда одновременной нагрузки на сервер в виде многочисленных пользователей не было, был условный один пользователь. При "стресс-тесте", когда происходят одновременно массовые запросы, результаты должны быть несколько иные. Никаких кеширований HTML средствами серверов не использовалось. Настройки серверов БД были идентичные. Главная страница: 56 ms (LiteSpeed) / 52 ms (NGINX) Страница Категория на 15 товаров: 94 ms (LiteSpeed) / 81 ms (NGINX) Страница Категория на 100 товаров: 173 ms (LiteSpeed) / 152 ms (NGINX) ВАЖНО IMPORTANT Для верности тестов open_basedir защита была отключена. Это крайне важно для правдивых тестов, т.к. для LiteSpeed (впрочем, как и для Apache или Nginx+Apache) при включенном open_basedir параметр TTFB, т.е. время отклика возрастает в 1.5-2 раза. Бывает, что по-умолчанию в настройках опция open_basedir включена, тогда вы получите неверные результаты тестов при сравнении с NGINX, т.е. будут изначально неравные условия тестирования. Нередко такой нюанс не учитывают, а потому получается ошибочный вывод, что LiteSpeed якобы работает в два раза медленнее чем Nginx. Вопрос потребления памяти веб-серверами - это отдельный вопрос. Выше был тест производительности.
- 84 коментаря
-
- 1
-
-
- linux
- cyberpanel
- (і ще %d)
-
а не рассматривали такой аргумент как наличие готового модуля кеширования HTML для опенкарт средствами веб-сервера? Для nginx есть что-то подобное? Я имею ввиду не само кеширование (оно есть в nginx ), а готовое средство в виде модуля для опенкарт. Зачем ставить всяческие кешеры HTML если есть нативное кеширование веб-сервером? Разумеется, можно сказать, что надо делать грамотно изначально сайт быстрый и т.п. Но если уже есть тормозной сайт и оптимизацией БД можно лишь отчасти решить проблему?
-
а я выше как раз описал один из случаев когда жизненно была необходимость оставить совместимость с .htaccess. если коротко, то работали постоянно сео-спецы, которые что-то мудрили с поддоменами, и работали они исключительно с rewrite htaccess. Они не создавали сами поддомены и в принципе не лезли в код опенкарт постоянно, но время от времени экспериментировали с htaccess. это всегда будет лучший выбор. поэтому LiteSpeed есть смысл рассматривать если нельзя отказаться от htaccess. В том то и дело, что имеется ввиду не под себя, где я вправе сам решать "как и что", а в случае если есть ограничения со стороны заказчика и тп. Для себя любимого поставил бы nginx и обошел бы ограничения софта на php, которые возникают при обмене данными по протоколу 1С (и подобные) с удаленным сервером. При возможности почти всегда ставлю чистый nginx. Если же nginx+php-fpm, то отлично подойдет панель управления aaPanel. При этом можно не удаляя сайта переключиться на apache или LiteSpeed если поняли, что htaccess жизненно необходим.
-
Я не встречался с такой проблемой если кодировка документа UTF-8. Некоторые несущественные баги в панели управления, конечно, присутствуют, но не сказал бы, что раздражают. В каждой панели управления мне (да и другим пользователям) чего то не хватает, идеальной нет. Меня, например, не раз спрашивали почему в ISPmanager нет возможности загружать файлы перетаскиванием и нет возможности увидеть размер всех файлов в конкретной папке? Вот в других панелях управления это есть, но нет в ISPmanager... Я попозже попробую выкатить сводную таблицу недостатков каждой панели управления. Но и достоинств, соответственно. Повторюсь, что у меня нет цели нахваливать какую-то определенную ОС или панель управления. Просто делюсь опытом применения. И бывают иногда веские причины использования .htaccess.
-
вот тут не понял. Если открыть редактор из файлового менеджера, то проблем с редактированием не заметил. Кириллица нормально вводится и отображается. Кодировка UTF-8. Причем, есть два редактора на выбор: простой и с подсветкой синтаксиса. Вот оба варианта с кириллицей: Возможно, что вы имели ввиду файлы конфигурации? Там используется для этого свой редактор. Там не проверял кириллицу. Да и там она будет редким и ненужным гостем.
-
Если быть точным, то не в полной мере поддерживает. Есть лишь небольшое (кому как, правда) неудобство, которое в целом не мешает пользоваться файловым менеджером. использование кириллицы, пробелов и т.д. в названиях файлов - это довольно дурная привычка, которая всегда где-то негативно проявится. Но, к сожалению, многие пользователи продолжают следовать этой дурной привычке. И вы правы, загрузить через файловый менеджер файл с кириллицей не получится. Уже загруженные файлы файловый менеджер отображает нормально. Также можно создавать новые папки с кириллическими именами. Разумеется, что можно загрузить архив с картинками с кириллическими названиями, тут тоже нет проблем разархивировать и получить кириллические файлы. Также без проблем можно производить операции с кириллическими файлами (копирование, перемещение и т.д.) Сомневаюсь, что кто-то будет через эту панель управления загружать по одной штуке кириллические картинки на сайт. А кроме картинок какие еще могут быть файлы с кириллицей в названиях? Все же панель управления не для этого. Для загрузки картинок вполне годится фтп или менеджер в самом опенкарт с поддержкой массовой загрузки перетаскиванием. Например, этот файловый менеджер для Опенкарт: Но если хочется прямо в панели управления файловый менеджер, который работает без проблем с кириллицей в любых ситуациях, то стоит смотреть в сторону панели управления aaPanel. Я уже упоминал ее. Там файловый менеджер позволяет работать с любыми папками, а не только с папками сайтов. Но в aaPanel метод drag & drop работает только в Хроме и подобных браузерах, но не в FireFox. В ISPmanager, кстати, нет в файловом менеджере drag & drop. Пример файлового менеджера aaPanel: Описание aaPanel я готовлю в настоящий момент. Пока отмечу еще раз, что панель управления aaPanel позволяет вам использовать на выбор несколько сценариев веб-сервер + PHP (с aaPanel ): nginx + php-fpm (без поддержки .htaccess) openLiteSpeed + lsphp (с поддержкой .htaccess) apache + php (apache module ) Используя aaPanel у вас есть прекрасная возможность сравнить производительность разных серверов на одном железе и одинаковом программном окружении (сервер БД и т.д.) с одинаковыми настройками. Т.е. один и тот же сайт без переустановки можно протестировать под управлением разных веб-серверов. Чем не база для объективной и непредвзятой оценки? Повторюсь еще раз, что я решил сделать детальный обзор разных достойных панелей управления под разными операционными системами Linux/ Если интересно, то могу и под FreeBSD 11, 12, 13 также рассмотреть варианты, т.к. с ними я тоже работал, но это сильно на любителя, но в целом для профессионала FreeBSD также может быть интересна, хоть для нее нет полноценных панелей управления как для Linux. Т.е. я предлагаю к ознакомлению разные панели управления чтобы была у вас возможность понять чем же они принципиально отличаются. Я работал с ними довольно продолжительное время на разных проектах. Практически все они неидеальные, приходится мириться с их отдельными недостатками. Но они сильно облегчают работу непрофессионалу. И позволяют сделать некоторую экономию средств по сравнению с платной панелью управления. На мой взгляд, если есть возможность для вашего сайта использовать чистый nginx + php-fpm, то стоит отдать ему предпочтение. Если же по тем или иным причинам вы не можете отказаться от htaccess, то тут на выбор: OpenLiteSpeed Nginx + Apache Использование веб-сервера Apache (в чистом виде) можно оправдать в случае небольшого магазина с небольшой нагрузкой. Но, как правило, на VDS не переходят с небольшим магазином, а, как раз наоборот, поэтому этот вариант получается самым неудачным выбором.
-
Так надо было вам сразу писать, что вы экспериментируете на локалке с непонятно как работающим и настроенным софтом. Это же совсем не та ситуация, которая может возникнуть на площадке хостинг-провайдера. Нюанс, так сказать, который в вашем случае решает все.
-
Т.е. получается, что вы просто слукавили, говоря о "худшем окружении"? Вы сравниваете все исключительно с nginx? А сравнивать веб-сервер LiteSpeed c Апачи или с nginx+apache, получается, что не нужно? Притом, что это, как раз, будет самым распространенным вариантом веб-серверов, используемых с опенкарт. Повторюсь, что я исходил из того, например, владелец сайта хочет просто сделать безболезненный перенос магазина без правок конфигов, т.е. без отказа от htaccess. И он это может сделать при переходе с того же nginx+apache. В htaccess может быть сотня правил rewrite (с заумной переадресацией на поддомены), и владелец сайта не хочет с этим разбираться и/или переписывать. Вот есть у владельца сайта требование - должны работать htaccess. Про "костыль" - это отговорка такая? Т.е. сравнивать не будем потому, что придумали отговорку про "костыль"? А если все же сравнить, то как тогда распределятся места? Apache, nginx+apache будут впереди или позади LiteSpeed?
