Это просто значит, что либо нет загрузки на этой ноде, либо просто и не надо столько ресурсов.
Но это всё может очень быстро измениться. Вариант с меньшим количеством выделенных ядер, надёжнее и более прогнозируем. В вашем случае надо рассматривать эту виртуалку как 1,5 ядра в лучшем случае, и сравнивать именно в этом ключе. А вообще, всё даже хуже, потому, что многие операции не распараллеливаются, и выгоднее иметь меньше но более быстрых ядер.
Ну и да, конечно это не надо менять на сервер.
На аукционе того же хетзнера можно взять начального уровня сервер на чём-то типа e3-12xx с ssd от e35 где-то.
Такая же по характиристикам виртуалка без оверсела у них стоит e83. Это ccx31. Даже с 4 ядрами ccx21 стоит уже дороже сервера(e41.88).
cpx31, которая дешевле значительно, не имеет гарантированных вычислительных ресурсов. Вам там не отдают реальные 4 ядра, собственно она и стоит так поэтому.
Хетзнер хорош только лоу кост серверами. Для размещения vps я бы смотрел на что-то другое...
Grenuy wrote: с базой экспериментировал поднять несколько на docker и разделить нагрузки. но профита не увидел, даже наоборот.
Конечно. База в докере будет медленее. И несколько инстансов баз в рамках одного сервера даже без контейнеров, будут затратнее по ресурсам и не будут быстрее.
Распределение нагрузки, это когда есть несколько дополнительных серверов СУБД, а не несколько инстансов СУБД на том же железе.
Тюнинг настроек происходит не так. Это цикл из измерений и изменений, и это даже если знаешь, что как работает.
Каких-то настроек, которые во всех случаях сделают wow, просто нет. Поэтому довольно бесполезно смотреть какие-либо примеры. Особенно в вашем случае, со сборной солянкой из разных проектов.
Сейчас, конфиг по умолчанию что для mysql, что для mariadb сносен, уже не задавлен так innodb_buffer_pool тот же как раньше.
Единственный хороший совет: не искать готовые советы. Просто не существует универсального решения на все случаи жизни.
По уму, надо осваивать mysql, смотреть что и как можно настроить для именно вашего случая, или найти кого-нибудь, кто это уже знает.
В самом простейшем случае, можно проверить конфигурацию каким-нибудь mysqltuner, и разобраться что, и почему именно, он советует изменить, а не просто копипестить советы в конфиг. И надо понимать, что это всё равно советы для общего случая, не более - им далеко не всегда имеет смысл следовать.
Конфиг базы очень зависит от проекта и наличных ресурсов.
Тот что по умолчанию по ссылке, часто будет совсем не оптимальным, тем более на сервере - он для очень скромных ресурсов, чтобы этот контейнер можно было на любом чайнике запустить, вероятно.
Как и при простой установке, в реальном проекте, надо менять настройки. Контейнеры отнюдь не избавляют от необходимости самостоятельного конфигурирования серверного ПО, просто иногда делают процесс развёртывания удобнее, не более - обратное это очень опасное заблуждение...
Там просто встретились неквалифицированный пользователь с неквалифицированной Дашей. Один делал не то, и не понимая, что делает, другая просто сказала фигню.
Не важно какой там debian - я о том, что ispmanager 5 совместим с MariaDB 10.3.x, и будет под ней работать без проблем.
И если нет сайтов которые не поддерживают 10.3(а такие проблемы бывают очень редко, и часто можно пофиксить изменением sql_mode, например) можно не плодить лишние инстансы mysql и просто обновиться.
Много версий php, кстати, не ведёт к лишним накладным расходам, только на диске немного больше занимают, что обычно не так важно. Там важно сколько всего процессов php запущено, а не сколько версий есть среди них.
Кем не рекомендуется? Страшилки какие-то очередные с сёрча?
Ispmanager 5 замечательно поддерживает mariadb 10.3.x, т.к. именно она в debian 10, а он там ставится и работает.
Альтернативные версии в докере можно теперь развёртывать, но это не выгодно с точки зрения использования ресурсов.
Вполне можно обновить, это не проблема и с панелькой. Она будет замечательно работать и с более свежей mariadb. Конечно, делать бекапы надо всегда.
Можно создать и какой-то внешний mysql сервер на другой виртуалке, но зачем?
Релиз Mariadb 10.1 вышел в 2014году, и это практически ещё mysql 5.5. У этого релиза был просто очень долгий срок поддержки, но он кончился, прям сегодня. Это реально очень устаревшая версия.
Апгрейд между версиями будет работать, с очень большой вероятностью. Каждую следующую нет смысла ставить, это обычно, не уменьшает вероятность проблем. Но конечно всегда надо бекапиться перед этим.
Почему D9 хочет прям 10.3.7 не очень понятно. Должен бы и с 10.2.х веткой работать.
Мне как постоянному покупателю, было бы удобно получить на странице такого товара ссылки на ближайшие аналоги, если таковые есть.
А как пользователю, который пользуется поисковиком, было бы удобно, если бы этих товаров в каталоге не было вовсе. Чтобы не получать лишней выдачи перейдя по которой я не смогу купить искомого, и только время потрачу.
Вообще всё больше определяется тем, что это за товары, на самом деле, и можно-ли сделать продажу чего-то похожего пользователю пришедшему по такому запросу.
Нет ещё стандарта. Есть черновики. Некоторые библиотеки, реализуют определённые версии черновиков. Подавляющее большинство частично. Практически никто не поддерживает самые свежие. Всё это экспериментальные возможности.
Не всегда разумно ссылаться на википедию, как на единственный источник, к тому же, не разбираясь в вопросе. Там часто очень поверхностные данные, как в данном случае. Да и откровенных ошибок не мало, и заведомо искажённой информации хватает.
Вообще, прежде чем тиражировать какую-то информацию, стоит в ней хорошенько разобраться.
Не надо наивно верить рекламе, и надо внимательно читать, что именно тестируется.
Это не сравнение веб серверов, это по факту, сравнение кеша, причём в одном определённом случае, к тому же наверняка специально созданном.
Причём тестирование "низкого качества": ничего не написано о нагрузке, которая была в процессе тестирования, что было узким место в каждом случае и.т.п.
Тем что потратив деньги вы не получите чего-то работающего заметно лучше.
Или, даже, получите нечто работающее хуже.
На drupal 8/9 определённый смысл мигрировать есть, по крайней мере, планировать это мероприятие уже стоит. И как правильно тут писали, заодно, стоит сформулировать то, что надо будет изменить/доделать. А сейчас, возможно, вам просто надо решить конкретные проблемы в рамках вашего нынешнего сайта.
Для начала, возможно, вообще стоит заняться не самим сайтом, а его окружением. Попробовать всё нормально настроить, поставить php посвежее и.т.п.
Переезд на bitrix будет дорог, и бесполезен, а если сайт сейчас сделан не очень уж плохо, то даже вреден.
много спецов (как по самому Битриксу, так и смежным - типа SEO)
Проблема в том, что уровень подавляющего большинства не высок.
проще интеграции (с 1С, с локальными сервисами типа яндекс.маркет), в тч много доступно из коробки.
Проблема в том, что тут что-то отличается от решений, под практически любую другую CMS, кроме какой-то совсем экзотики, только в речах маркетологов битрикса.
WP мало подходит для таких целей. Сравнивать их по таким параметрам довольно бессмысленно.
Ключевые фичи вордпресса простота и красивая и удобная админка, позволяющая просто и удобно публиковать какие-нибудь статьи. И масса готовых плагинов, приносящих полностью готовый, но сложно изменяемый функционал.
Он позволяет простыми методами решить очень много простых задач, именно поэтому так распространён.
Вполне понимаю. Как и многие другие формулировки в статье эта не корректна.
Но и ваше возражение настолько же не корректно.
Найти не open source CMS, наверное, можно сейчас только в виде SааS.
А платность не влияет никак на открытость кода. Это параллельные понятия. И бесплатное ПО может быть с закрытым кодом, и платное с открытым.
Возражение отчасти резонно, но тоже не соответствует действительности.
Как ни странно, код bitrix как раз-таки открыт. Там не используется какого-нибудь ioncube, например. Он даже не подвергнут обфускации. И на это убожество вполне можно посмотреть и понять, как нельзя писать код и проектировать CMS.
Drupal 8/9 давай скоростью (mysql 8 \ mariadb 10.3)
Это просто значит, что либо нет загрузки на этой ноде, либо просто и не надо столько ресурсов.
Но это всё может очень быстро измениться. Вариант с меньшим количеством выделенных ядер, надёжнее и более прогнозируем. В вашем случае надо рассматривать эту виртуалку как 1,5 ядра в лучшем случае, и сравнивать именно в этом ключе. А вообще, всё даже хуже, потому, что многие операции не распараллеливаются, и выгоднее иметь меньше но более быстрых ядер.
Ну и да, конечно это не надо менять на сервер.
Drupal 8/9 давай скоростью (mysql 8 \ mariadb 10.3)
Это не сочетается с "быстрее и лучше".
Drupal 8/9 давай скоростью (mysql 8 \ mariadb 10.3)
На аукционе того же хетзнера можно взять начального уровня сервер на чём-то типа e3-12xx с ssd от e35 где-то.
Такая же по характиристикам виртуалка без оверсела у них стоит e83. Это ccx31. Даже с 4 ядрами ccx21 стоит уже дороже сервера(e41.88).
cpx31, которая дешевле значительно, не имеет гарантированных вычислительных ресурсов. Вам там не отдают реальные 4 ядра, собственно она и стоит так поэтому.
Хетзнер хорош только лоу кост серверами. Для размещения vps я бы смотрел на что-то другое...
Drupal 8/9 давай скоростью (mysql 8 \ mariadb 10.3)
Конечно. База в докере будет медленее. И несколько инстансов баз в рамках одного сервера даже без контейнеров, будут затратнее по ресурсам и не будут быстрее.
Распределение нагрузки, это когда есть несколько дополнительных серверов СУБД, а не несколько инстансов СУБД на том же железе.
Drupal 8/9 давай скоростью (mysql 8 \ mariadb 10.3)
Тюнинг настроек происходит не так. Это цикл из измерений и изменений, и это даже если знаешь, что как работает.
Каких-то настроек, которые во всех случаях сделают wow, просто нет. Поэтому довольно бесполезно смотреть какие-либо примеры. Особенно в вашем случае, со сборной солянкой из разных проектов.
Сейчас, конфиг по умолчанию что для mysql, что для mariadb сносен, уже не задавлен так innodb_buffer_pool тот же как раньше.
Drupal 8/9 давай скоростью (mysql 8 \ mariadb 10.3)
Единственный хороший совет: не искать готовые советы. Просто не существует универсального решения на все случаи жизни.
По уму, надо осваивать mysql, смотреть что и как можно настроить для именно вашего случая, или найти кого-нибудь, кто это уже знает.
В самом простейшем случае, можно проверить конфигурацию каким-нибудь mysqltuner, и разобраться что, и почему именно, он советует изменить, а не просто копипестить советы в конфиг. И надо понимать, что это всё равно советы для общего случая, не более - им далеко не всегда имеет смысл следовать.
Drupal 8/9 давай скоростью (mysql 8 \ mariadb 10.3)
Конфиг базы очень зависит от проекта и наличных ресурсов.
Тот что по умолчанию по ссылке, часто будет совсем не оптимальным, тем более на сервере - он для очень скромных ресурсов, чтобы этот контейнер можно было на любом чайнике запустить, вероятно.
Как и при простой установке, в реальном проекте, надо менять настройки. Контейнеры отнюдь не избавляют от необходимости самостоятельного конфигурирования серверного ПО, просто иногда делают процесс развёртывания удобнее, не более - обратное это очень опасное заблуждение...
Drupal 8 Feeds charset windows-1251 и header User-Agent
Всё это надо решать написанием своего fetcher, а не хакать модули...
Версия сервера базы данных 10.1.38-MariaDB-0+deb9u1 меньше, чем минимальная требуемая версия 10.3.7
Там просто встретились неквалифицированный пользователь с неквалифицированной Дашей. Один делал не то, и не понимая, что делает, другая просто сказала фигню.
Версия сервера базы данных 10.1.38-MariaDB-0+deb9u1 меньше, чем минимальная требуемая версия 10.3.7
Не важно какой там debian - я о том, что ispmanager 5 совместим с MariaDB 10.3.x, и будет под ней работать без проблем.
И если нет сайтов которые не поддерживают 10.3(а такие проблемы бывают очень редко, и часто можно пофиксить изменением sql_mode, например) можно не плодить лишние инстансы mysql и просто обновиться.
Много версий php, кстати, не ведёт к лишним накладным расходам, только на диске немного больше занимают, что обычно не так важно. Там важно сколько всего процессов php запущено, а не сколько версий есть среди них.
Версия сервера базы данных 10.1.38-MariaDB-0+deb9u1 меньше, чем минимальная требуемая версия 10.3.7
Кем не рекомендуется? Страшилки какие-то очередные с сёрча?
Ispmanager 5 замечательно поддерживает mariadb 10.3.x, т.к. именно она в debian 10, а он там ставится и работает.
Альтернативные версии в докере можно теперь развёртывать, но это не выгодно с точки зрения использования ресурсов.
Версия сервера базы данных 10.1.38-MariaDB-0+deb9u1 меньше, чем минимальная требуемая версия 10.3.7
Вполне можно обновить, это не проблема и с панелькой. Она будет замечательно работать и с более свежей mariadb. Конечно, делать бекапы надо всегда.
Можно создать и какой-то внешний mysql сервер на другой виртуалке, но зачем?
Версия сервера базы данных 10.1.38-MariaDB-0+deb9u1 меньше, чем минимальная требуемая версия 10.3.7
Релиз Mariadb 10.1 вышел в 2014году, и это практически ещё mysql 5.5. У этого релиза был просто очень долгий срок поддержки, но он кончился, прям сегодня. Это реально очень устаревшая версия.
Апгрейд между версиями будет работать, с очень большой вероятностью. Каждую следующую нет смысла ставить, это обычно, не уменьшает вероятность проблем. Но конечно всегда надо бекапиться перед этим.
Почему D9 хочет прям 10.3.7 не очень понятно. Должен бы и с 10.2.х веткой работать.
Что делать с товарами которых не будет
Мне как постоянному покупателю, было бы удобно получить на странице такого товара ссылки на ближайшие аналоги, если таковые есть.
А как пользователю, который пользуется поисковиком, было бы удобно, если бы этих товаров в каталоге не было вовсе. Чтобы не получать лишней выдачи перейдя по которой я не смогу купить искомого, и только время потрачу.
Вообще всё больше определяется тем, что это за товары, на самом деле, и можно-ли сделать продажу чего-то похожего пользователю пришедшему по такому запросу.
P.S. Ну и думать лучше об этом, а не о 404 и.т.п.
Что делать с товарами которых не будет
Возможно потому, что это, не слишком важно, проблема-то логическая, а не техническая и с применённой CMS не связана.
Ошибка Drupal
Судя по ошибке, это mysql, всё же.
Простое нагрузочное тестирование с помощью phoronix-test-suite в ubuntu 18.04
Есть ещё классический apache bench(ab), но главное тут, в понимании методики тестирования и правильной интерпретации результатов, а не в инструментах.
Сравнение производительности веб серверов на друпале
Нет ещё стандарта. Есть черновики. Некоторые библиотеки, реализуют определённые версии черновиков. Подавляющее большинство частично. Практически никто не поддерживает самые свежие. Всё это экспериментальные возможности.
Не всегда разумно ссылаться на википедию, как на единственный источник, к тому же, не разбираясь в вопросе. Там часто очень поверхностные данные, как в данном случае. Да и откровенных ошибок не мало, и заведомо искажённой информации хватает.
Вообще, прежде чем тиражировать какую-то информацию, стоит в ней хорошенько разобраться.
Сравнение производительности веб серверов на друпале
Не надо наивно верить рекламе, и надо внимательно читать, что именно тестируется.
Это не сравнение веб серверов, это по факту, сравнение кеша, причём в одном определённом случае, к тому же наверняка специально созданном.
Причём тестирование "низкого качества": ничего не написано о нагрузке, которая была в процессе тестирования, что было узким место в каждом случае и.т.п.
об установке composer
Drupal vs Bitrix
Тем что потратив деньги вы не получите чего-то работающего заметно лучше.
Или, даже, получите нечто работающее хуже.
На drupal 8/9 определённый смысл мигрировать есть, по крайней мере, планировать это мероприятие уже стоит. И как правильно тут писали, заодно, стоит сформулировать то, что надо будет изменить/доделать. А сейчас, возможно, вам просто надо решить конкретные проблемы в рамках вашего нынешнего сайта.
Для начала, возможно, вообще стоит заняться не самим сайтом, а его окружением. Попробовать всё нормально настроить, поставить php посвежее и.т.п.
Drupal vs Bitrix
Переезд на bitrix будет дорог, и бесполезен, а если сайт сейчас сделан не очень уж плохо, то даже вреден.
Проблема в том, что уровень подавляющего большинства не высок.
Проблема в том, что тут что-то отличается от решений, под практически любую другую CMS, кроме какой-то совсем экзотики, только в речах маркетологов битрикса.
Drupal или Wordpress? Что влияет на выбор CMS
WP мало подходит для таких целей. Сравнивать их по таким параметрам довольно бессмысленно.
Ключевые фичи вордпресса простота и красивая и удобная админка, позволяющая просто и удобно публиковать какие-нибудь статьи. И масса готовых плагинов, приносящих полностью готовый, но сложно изменяемый функционал.
Он позволяет простыми методами решить очень много простых задач, именно поэтому так распространён.
Drupal или Wordpress? Что влияет на выбор CMS
Вполне понимаю. Как и многие другие формулировки в статье эта не корректна.
Но и ваше возражение настолько же не корректно.
Найти не open source CMS, наверное, можно сейчас только в виде SааS.
А платность не влияет никак на открытость кода. Это параллельные понятия. И бесплатное ПО может быть с закрытым кодом, и платное с открытым.
Drupal или Wordpress? Что влияет на выбор CMS
Возражение отчасти резонно, но тоже не соответствует действительности.
Как ни странно, код bitrix как раз-таки открыт. Там не используется какого-нибудь ioncube, например. Он даже не подвергнут обфускации. И на это убожество вполне можно посмотреть и понять, как нельзя писать код и проектировать CMS.