В замедлении веба не в последнюю очередь виноваты хостинги.
Какие проблемы вижу я:
1) Процессоры в погоне за ядрами становятся все медленнее.
Причем вам могут обещать какие-то высокие турбо-частоты, но в реальности на не пустующем сервере их практически никогда не будет. А будет скорей что-то около 2 Ггц.
2) SSD в погоне за ценой и объемом становятся все хуже.
Опять же, вам будут обещать супер-NVMe, в 10x быстрее, и т.п. маркетинговую чушь.
А по факту внутри TLC/QLC флэш, который без кэшей уверенно стремится к скоростям HDD.
Снова, речь про работающий сервер с кучей пользователей, а не однопользовательские бенчмарки на пустом диске.
3) Повсеместное увлечение vps. Когда берут 1-ядерную самую дешевую виртуалку и она этим единственным ядрышком (не забываем за п.1) должна и операционку содержать, и вэб-сервер и базы, и кто знает что еще понаустанавливают на нее.
Тоже сперва вызвало улыбку выражение «Гигабитный Wi-Fi» и один лишь кабель питания на выходе, но на самом деле каждый волен делать как хочет. Захотел человек сделать комп почти невидимым и самый минимум проводов — получил. В этом ведь и есть основная суть custom'а. Мне к примеру подавай как минимум пару lan кабелей — для локалки и инета раздельные, и чтоб еще минимум один из них был оптический. Кто-то не представляет как можно существовать с менее чем двумя видеокартами. Кто-то считает что и воздушного охлаждения за глаза. А кто-то вообще на звуке повернут и будут еще стоять всякие трансформаторные б.п., экраны, кабеля толщиной в два пальца и т.п.
В любом случае подобного уровня неколхозные самоделки заслуживают уважения.
Часто один из днс серверов физически расположен там же где и ваш сайт.
Спрашивается, в случае его падения, вам будет легче от того что днс работает, но сам сайт нет? В большинстве случаев без разницы, упал ли сайт с днс или только сайт, а днс нормально работает… направляя посетителей на нерабочий ip.
Исключение может быть лишь если у вас на уровне днс реализовано какое-то жонглирование хостингами какраз на случай падения одного из них. Или же если MX направлена куда-то в другое место, тогда да, даже если сайт упадет, хотелось бы чтоб почта продолжала работать.
Но не забываем за минусы стороннего днс хостинга:
а) Это всеж дополнительное звено цепи и потенциальная point of failure. Даже у великолепных cloudflare с гуглами случаются проблемы.
б) Масштабы несоизмеримы. Прикиньте количество доменов у днс хостинга и хостинга вашего сайта. Скорость ответа наверняка будет достаточно заметна.
в) В случае ЧП или просто какой-то технической необходимости хостер сможет оперативно сменить ip вашего сайта без вашего участия. В противном случае вы сами себе увеличиваете время даунтайма если вдруг будет необходимость смены ip сайта — сервер упал/заддосен и всех быстро переключили на другой ip… кроме вас потому что вы самый умный и пользуетесь чужими ns. :)
Вопрос звучал «зачем дома» — затем что нужен, затем что это не только интернет, но и домашняя локалка.
Мы же на хабре, совсем уж «рядовых» пользователей тут особо и нет наверное, у них от большинства здешних текстов голова начинает быстро болеть.
В общем согласен, всем подряд конечно оно не надо. Те поставят tplink самый дешевый и в 2.4 диапазоне вообще будут сидеть… какой wifi6, о чем там речь :)
И само понятие «дом» у всех разное. Кто в офисах насидится, дома никаких вайфаев, ничего уже не хочет, дома чисто отдых. Но ведь многие дома работают и имеют повышенную чувствительность к качеству сети/wifi/интернет.
Точно также раньше спрашивали — а зачем вам 100мбит? Мол мне вот 10 за глаза, значит и всем так же.
Кому-то и 100мбит локалки достаточно, а кому гигабитная вообще не вариант, и 10г как-то даже уже начинает быть маловато, учитывая скоростя современных ssd'шек.
Речь же не только про интернет (который гигабитный кстати тоже далеко не редкость уже), а просто про локальную сеть. Допустим с ноутбука на NAS домашний закинуть 50мбайт/сек может запросто быть мало и рука так прямо и тянется к кабелю за «соточкой»…
Ну а на стационарных компах уж точно не меньше 10G сеть должна быть.
Даже если речь не про ssd, а те же hdd 200-250мбайт/сек вовсе не редкость. Спрашивается почему надо себя ограничивать? Оптика 10-40г сейчас на ebay копейки стоит. А потом подсев на эти скоростя, зачем нужен wifi6 уже вопроса не возникает.
Ничего не мешало. просто хотел чтоб ни одного клиента не было в 2.4 у меня.
Сейчас отлично: соседских точек 1-3шт ловится и почти все на одних и тех же каналах. Я естественно съехал на незанятые и красота — 400+мбит всегда и почти из любого края квартиры.
Не знаю что понимается под отдельную виртуальную сеть… пока из wifi6 имею лишь AX200 в ноуте. Роутеры/ТД пока не доводилось щупать, может там как-то хитро реализовано. Но в нынешнем Ruckus R700 схема такая:
Так вот режимы b/g/n, n/ac, а также выбор канала, ширина канала — это все настраивается на уровне «wireless mode». И все виртуальные сети будут в одном выбранном режиме.
Т.е. нельзя сделать к примеру в 5G диапазоне одну виртуальную сеть AC и одну N например. Только один вариант канала, ширины, скорости и глубже уже 8шт виртуальных подсетей можно сделать.
Но возможно в других роутерах иначе и возможно в wifi6 рукусах (R550/R650/R750/R850) тоже возможно сделать такое, чтоб параллельно существовали AC и AX.
Поглядим…
Вот это самая большая проблема на самом деле.
Т.е. если останется хоть одно «старое» устройство, никаких wifi6 не видать?
Я год или два назад наконец изжил последний 2.4ггц девайс чтобы оставить точку доступа исключительно в 5ггц режиме. А теперь впереди новая борьба за AX…
Ну то есть по тарифу пользователя конфиги апача прописаны скажем на 10 процессов максимум и соотв. php под скажем 1гб памяти. Далее пользователь добавляет сколько-то сайтов и задействует все 8 версий php. Т.е. суммарно уже не 10, а 80 процессов, не 1, а 8гб памяти в его распоряжении. Так выходит? Подозреваю что нет и глобально весь пользователь всеж как-то урезается до тех же тарифных 10 процессов и 1гб. А следовательно сайты на одной из восьми веток довольствуются лишь 1/8 от возможного в подобной ситуации.
Вы понимаете суть? Если сделать чтоб nginx делал тот же самое, что и apache, то он уже не будет таким быстрым.
Аналогично можно вместо .htaccess все правила в конфиг apache записывать и чтоб он считывался только при перезапуске, а не при каждом запросе. И тогда можно allowoverride выключить — один из самых замедляющих апач нюансов (поиск и чтение .htaccess'ов при каждом запросе).
Но как этим будут управлять пользователи?
Или по вашей схеме — исправит чел что-то в .htaccess своем и как nginx должен будет узнать об этом? Только перечитав этот файл. Но если он начнет также как апач искать, читать и выполнять все .htaccess'ы, то он точно также станет медленней работать. Где вообще логика?
У себя использую уже несколько лет исключительно dedicated схему с персональными апачами для каждого пользователя даже на самых минимальных тарифах. До этого поначалу также был один общий apache itk и самый главный недостаток это когда у кого-то из клиентов случается какой-то «затык» — приходит запрос, php что-то долго думает, либо вообще запрашивает что-то из вне, а этот внешний источник «лежит», процесс зависает. Следующий запрос обрабатывает следующий свободный процесс и вродебы более-менее работает до тех пор пока на тот проблемный зависающий скрипт не приходит запросов больше, чем maxrequestworkers. В итоге зависшими оказываются все процессы apache и новые запросы, даже если они от других клиентов и беспроблемные быстрые, они просто стоят в очереди и все сайты на сервере оказываются зависшими.
Ну и память opcache была естественно занята в основном скриптами тех сайтов, где больше траффика. А клиенты с 2 запросами в день получается были ущемлены и у их скриптов почти каждый раз выходит «холодный старт».
Поэтому сейчас только выделенные процессы каждому с его личной памятью.
Плюс аналогично сделано с mysql. Т.к. одна общая это также плохо как shared apache.
Однако на данный момент сделано чтобы было: 1 пользователь = 1 ветка apache/mod_php с одной версией php. Все прозрачно и понятно, 1 пользователь = какое-то макс число памяти и процессов. Кому нужно больше — берет тариф выше с бо́льшими лимитами и на другом сервере с меньшим числом соседей.
Но. Изредка возникают вопросы у пользователей, которые в пределах одного аккаунта хотят разные версии php для разных сайтов. Сейчас просто делается ему новый аккаунт под новую версию php. Опять же, логично, пользователь хочет еще один «блок» из памяти и числа процессов, извольте доплатить +1 тариф.
Да, можно было бы сделать как у вас: 1 пользователь = до 8 пар (число версий php) apache/mod_php под разные версии, но как тогда ограничивать память и процессы, но чтоб все по справедливости было? А не так что одни сайты под одной веткой занимали чего-то больше и ограничивали другие под другой. Либо без ограничения, но тогда потенциально пользователь сможет 8-кратно превысить лимиты своего тарифа.
По вашей картинке выходит, что у user 2 его единственному сайту доступно все по максимуму в пределах его тарифа. А у user 1 как? Apache 7.1 и 7.2 делят пополам макс. предел по процессам и памяти? Или не пополам, что один из сайтов может перетянуть все одеяло на себя и клиент не будет понимать почему второй сайт хуже работает? Т.е. теоретически если человек добавит 8 сайтов и все под разными версиями php, то каждый из них будет по сути в 8 раз более ограничен, чем если бы все сайты были под какой-то одной версией php. В общем не понятно как у вас реализована дележка числа процессов и памяти между разными апачами в пределах одного аккаунта.
И снова в комментариях полно веганов, не понимающих зачем нужен apache, которым обязательно необходимо всему миру сообщить что они 10 лет уже не едят мясо не пользуются apache.
А те кто пользуются — просто злые из-за мяса тормозящих под apache сайтов.
Вы бы запустили свой хостинг, чисто с nginx + php-fpm. И объясняли бы каждому клиенту, что он просто тупой раз не может обойтись без apache.
Это прекрасно. Но опять же, hetzner — это далеко не все.
Лично не раз нужны были мелкие vps под тот же vpn или почту или dns.
И в «flags» было всего ничего…
Да откуда вы знаете «внутреннюю кухню» :)
Не каждый день, а постоянно. Плюс настроены мониторинги. В случае если вдруг кто-то сильно грузит процессор к примеру, сразу же прилетает уведомление и вручную разбирательство проводится. Чаще всего это набег какого-то тупого бота-брутфорсера или подобного. Тут же он банится и все, клиент даже не узнает о том что что-то было.
Бывают конечно сложней ситуации, когда просто сайт тормозной у клиента и даже небольшой наплыв посетителей или ботов превращаются в заметную нагрузку на cpu. В этом случае также вручную индивидуально все решается. Путем улучшения самого сайта клиента, а не путем завинчивания ему гаек или переселения на другой сервер.
Плотность рассадки зависит от тарифа. Все минимальщики на одном, там действительно в основном пару-страничники простенькие. Хотя всякие есть…
У кого размеры сайтов по-больше, тем и тариф выше требуется — эти на следующий сервер с существенно меньшей плотностью населения. И так далее, на сервере где максимальные, там вообще 4 аккаунта вот сейчас.
Самое главное что ничего не перегружено и ничего ни у кого не тормозит ни где, на любом тарифе/сервере.
Повторяю еще раз, если кого действительно заинтересовало то о чем говорю, обращайтесь. Бесплатно аккаунт на неделю чтоб расставить все точки и лично сравнить то что есть и то как может быть по-другому.
А теоретически философствовать можно конечно бесконечно. У каждого будет своя правда. Кто-то «наелся» шаредов на том самом cloudlinux с тучей мелких ограничений, не дающих спокойно дышать сайту и теперь конечно на vps ему вроде как хорошо. Или шареды были по железу серверов не лучше (или даже хуже) vps'ных — медленные процессоры, диски и т.п.
Опять же, не говорите за всех.
Есть сайты-магазины не маленькие, объемом всего добра под 100гб и траффиком иногда в районе 500мбит и 1000 запросов/сек. Да, это не на самом дешевом тарифе конечно, но все еще на shared'е.
В php можно практически все настроить под себя т.к. оно (apache/mod_php или php-fpm) работает независимо под каждого пользователя.
SSH — есть даже на самом мин. тарифе.
Мой посыл лишь в том что за те же или чаще большие деньги на vps конечный результат (скорость работы сайта) получается заметно хуже. Ввиду специфики — обрезан процессор по ядрам и слаб по частоте.
Как говорили в одном фильме — «не мы такие, жизнь такая».
«Они» — это почти 99% пользователей shared хостинга.
По вашей логике надо убрать апач и работать лишь с тем 1% с сайтами чисто на статике или без cms, использующих .htaccess?
А еще тут есть персонажи, кто с php 5.4 никак не съедет… а вы говорите апач выкинуть.
Все просто — если у этого хостера не будет нужного клиенту софта, он пойдет к другому.
А автору пожелаю лишь скорей прийти к пониманию, что от сторонних «продуктов» надо уходить. Есть вы и есть клиенты ваши. Они видят проблему и требуют решения именно от вас. Вы же вместо максимально быстрого решения оббиваете чужие пороги — cloudlinux, ispmanager…
По этой причине в своем хостинге изначально решил, что не будет никогда никаких чужих «панелек», в которых поди разберись в случае если что-то пойдет не так. Клиенты будут стоять над тобой и дышать в спину т.к. их не волнуют все эти нюансы. Они лишь видят что у этого хостера что-то не работает, значит пойдем к другому.
Так что весь используемый софт надо знать лично от и до, в точности понимать как и что работает, не надеясь что кто-то другой сделает лучше. Ошибки случаются у всех, но свои ошибки куда быстрей можно обнаружить и исправить.
С первых строк не понравилось как вы мощно обобщили все shared-хостинги.
Уж не знаю с кем именно и какой опыт был, но!
Если будет время/желание развеять мифы и стереотипы про шаред хостинг, обращайтесь.
По указанным вами пунктам: все ПО не из комплекта операционок, а самостоятельно собирается из исходников и есть все актуальные и самые свежие версии — php до 7.4 и собираюсь на днях даже для экстремалов собрать 8.0 alpha 1. Все сопутствующее барахло типа ioncube и т.д. запчастей также самое свежее имеется.
Базы MariaDB до 10.5 и тоже можно выбрать более раннюю версию. А возможно также добавлю в скором времени на выбор и оригинальные MySQL разных версий.
Nginx (последний), Let's Encrypt само собой есть и wildcard тоже.
За nginx фронтом у каждого пользователя стоят личные независимые процессы скриптового бэкэнда на выбор из apache/mod_php или php-fpm. Тоже самое с mysql — процессы независимые у каждого, а не один общий на всех. Естественно у каждого свои настройки php.ini и my.cnf
Т.е. если что-то у кого-то падает, тупит или нагружается, то на соседях это практически не отражается. И что даже еще более важно — вся занимаемая память процессами пользователя — его личная. Opcache в php весь ваш и соседские скрипты не будут пытаться вытеснить ваши из него. Кэш запросов и остальная память mysql — тоже принадлежит именно одному пользователю, а не тому кто больше запросов делает. Плюс в mysql слишком большой размер кэшей может сделать только хуже в плане производительности.
Оттюнить себе mysql как-то особенно, наставить модулей хитрых или наоборот максимально облегчить php — не проблема, практически ничего невозможного нет.
В общем по гибкости не сильно хуже VPS, но:
1) Вам не надо ничего администрировать и вообще вникать во что-то иное, кроме ваших сайтов. За вас все сделают, настроят и присмотрят как за детьми малыми. В отличии от VPS, где в вас обычно бросят root'ом и дальше живите как хотите.
2) Железо. Не заметил ни слова даже о частотах процессоров, только какие-то условные «ядра». Вы же понимаете, что это чуть ли не самое важное от чего зависит именно скорость работы сайтов. Если у хостера на сервере 128 ядер, то это лишь для того чтоб продать его большему числу клиентов, а вам то что с того? Почти любая VPS это обычно 2-2.5Ггц ядра. Если больше, то за это уже и совсем другие деньги просят. А вот shared'у не надо ядрами торговать и допустим на 4Ггц частоте сайты ворочаются раза в 2 шустрее.
SSD, а ныне новомодное NVMe в каждой рекламе. Но опять же, хостеру надо максимально большой объем чтоб визуально более выгодные тарифы предложить да и на большее число клиентов ее поделить. А вам? Именно вашему сайту скорей всего ни холодно ни жарко от 2-3Гб/сек при последовательном единоличном доступе крупными блоками, вы же не фильмы гонять будете по диску своему. И сотни тысяч IOPs тоже ведь достигаются лишь за счет множественных параллельных обращений клиентов/соседей.
Все что хочет среднестатистический сайт на том же wordpress к примеру — это по-выше частота процессора, по-больше памяти и быстрей да больше количество операций с диском при случайном доступе мелкими блоками. И сила тут либо за старыми добрыми SLC и MLC, либо за самыми передовыми Optane. В массовом хостинге же практически поголовно «оптимальные» по цена/объем TLC/QLC и т.д. ширпотреб и явный поворот не туда, в сторону к HDD, а не действительно к скорости и производительности. Хоть и под лэйблом NVMe. Там SLC кэш заканчивается и все, NVMe превращается в тыкву.
Также на shared'е вам доступны все ядра процессора и они полноценные, а не обрезки (без AES к примеру) как это часто бывает на VPS. Память выделяемая вам — она по максимуму используется именно сайтами вашими. На vps же надо тратиться еще на всю остальную операционку и доп. софт который по-любому ведь будет необходим — почта, фтп, возможно панелька какая-то и т.д.
В общем, если заинтересовал действительно правильный shared хостинг или не устраивает скорость работы сайта на каком-то существующем, приглашаю на бесплатный сравнительный тест.
Если вайфай работает плохо, значит виноват не роутер и не соседи, а провайдер!
Если какой-то сайт тормозит, виноват не сам сайт и не его хостинг, а провайдер!
«Я плачу деньги» провайдеру, и если что-то не получаю по заявленной в тарифе скорости, значит провайдер плохой!
Скорей вот так думают ваши соседи, а вовсе не бегут покупать новый роутер.
Анализ эфира это конечно хорошо, но есть две громадные проблемы:
1) В двух разных концах квартиры картина может меняться на противоположную. На какой тогда спрашивается канал вешать роутер, стоящий в центре?
2) Вы сейчас все оцените, настроите правильно, порадуетесь улучшению. А через 5 минут соседские точки перепрыгнут на другие каналы. На этом все и закончится.
Ну так Вы же сами смотрите лишь в сторону «крупняка». Там в поддержке наемный труд, которому глубоко плевать на все что с Вами связано. Им бы скорей конец дня/недели.
Возможно поэтому в lite host владелец работает один, предпочитает не связываться с наемными пока справляется и сам.
А тут же в статье речь про совсем другой уровень отношения. Владельцу хостинга не наплевать на каждого из своих клиентов. И у него ВСЕ под контролем. Каждый мелкий нюанс. А у крупных можно ожидать ответ лишь в области компетенции отвечающего. Запросто могут вас «буцать» по разным «спецам», каждый из которых еще в меру своей лени/загруженности должен вникнуть в Ваш вопрос…
Тоже кстати пользуюсь lite host'ом (один из 10+ самых разных) и доводилось однажды контактировать. Действительно очень быстро задача решалась, а не отмашки и отписки как это почти поголовно у любой крупной (не только хостинговой) компании.
А насчет пингов. Вы же понимаете, что геолокация тут очень большую роль играет. И это вовсе не показатель «быстроты». Но 20-75мс в любом случае не плохо, даже если пинг между ботом яндекса и сервером 1мс. Но это врядли заслуга LiteSpeed и врядли тот же Nginx сильно хуже результат бы показывал.
Но именно «sunlike» на али нет. Однажды уже пытался найти.
Оказывается надо искать sunlight… китайцы одним словом.
Интересно на сколько все заявленное соответсвует?
Хотелось бы для самоделок, фотоподсветки и т.п. взять на пробу, но приборов для проверки нет. Обидно если буду думать, что получаю ровный спектр, а на самом деле нет.
Какие проблемы вижу я:
1) Процессоры в погоне за ядрами становятся все медленнее.
Причем вам могут обещать какие-то высокие турбо-частоты, но в реальности на не пустующем сервере их практически никогда не будет. А будет скорей что-то около 2 Ггц.
2) SSD в погоне за ценой и объемом становятся все хуже.
Опять же, вам будут обещать супер-NVMe, в 10x быстрее, и т.п. маркетинговую чушь.
А по факту внутри TLC/QLC флэш, который без кэшей уверенно стремится к скоростям HDD.
Снова, речь про работающий сервер с кучей пользователей, а не однопользовательские бенчмарки на пустом диске.
3) Повсеместное увлечение vps. Когда берут 1-ядерную самую дешевую виртуалку и она этим единственным ядрышком (не забываем за п.1) должна и операционку содержать, и вэб-сервер и базы, и кто знает что еще понаустанавливают на нее.
В любом случае подобного уровня неколхозные самоделки заслуживают уважения.
Часто один из днс серверов физически расположен там же где и ваш сайт.
Спрашивается, в случае его падения, вам будет легче от того что днс работает, но сам сайт нет? В большинстве случаев без разницы, упал ли сайт с днс или только сайт, а днс нормально работает… направляя посетителей на нерабочий ip.
Исключение может быть лишь если у вас на уровне днс реализовано какое-то жонглирование хостингами какраз на случай падения одного из них. Или же если MX направлена куда-то в другое место, тогда да, даже если сайт упадет, хотелось бы чтоб почта продолжала работать.
Но не забываем за минусы стороннего днс хостинга:
а) Это всеж дополнительное звено цепи и потенциальная point of failure. Даже у великолепных cloudflare с гуглами случаются проблемы.
б) Масштабы несоизмеримы. Прикиньте количество доменов у днс хостинга и хостинга вашего сайта. Скорость ответа наверняка будет достаточно заметна.
в) В случае ЧП или просто какой-то технической необходимости хостер сможет оперативно сменить ip вашего сайта без вашего участия. В противном случае вы сами себе увеличиваете время даунтайма если вдруг будет необходимость смены ip сайта — сервер упал/заддосен и всех быстро переключили на другой ip… кроме вас потому что вы самый умный и пользуетесь чужими ns. :)
Мы же на хабре, совсем уж «рядовых» пользователей тут особо и нет наверное, у них от большинства здешних текстов голова начинает быстро болеть.
В общем согласен, всем подряд конечно оно не надо. Те поставят tplink самый дешевый и в 2.4 диапазоне вообще будут сидеть… какой wifi6, о чем там речь :)
И само понятие «дом» у всех разное. Кто в офисах насидится, дома никаких вайфаев, ничего уже не хочет, дома чисто отдых. Но ведь многие дома работают и имеют повышенную чувствительность к качеству сети/wifi/интернет.
Кому-то и 100мбит локалки достаточно, а кому гигабитная вообще не вариант, и 10г как-то даже уже начинает быть маловато, учитывая скоростя современных ssd'шек.
Речь же не только про интернет (который гигабитный кстати тоже далеко не редкость уже), а просто про локальную сеть. Допустим с ноутбука на NAS домашний закинуть 50мбайт/сек может запросто быть мало и рука так прямо и тянется к кабелю за «соточкой»…
Ну а на стационарных компах уж точно не меньше 10G сеть должна быть.
Даже если речь не про ssd, а те же hdd 200-250мбайт/сек вовсе не редкость. Спрашивается почему надо себя ограничивать? Оптика 10-40г сейчас на ebay копейки стоит. А потом подсев на эти скоростя, зачем нужен wifi6 уже вопроса не возникает.
Сейчас отлично: соседских точек 1-3шт ловится и почти все на одних и тех же каналах. Я естественно съехал на незанятые и красота — 400+мбит всегда и почти из любого края квартиры.
Не знаю что понимается под отдельную виртуальную сеть… пока из wifi6 имею лишь AX200 в ноуте. Роутеры/ТД пока не доводилось щупать, может там как-то хитро реализовано. Но в нынешнем Ruckus R700 схема такая:
2.4G
└ wireless mode
├ wireless network 1
├ …
└ wireless network 8
5G
└ wireless mode
├ wireless network 9
├ …
└ wireless network 16
Так вот режимы b/g/n, n/ac, а также выбор канала, ширина канала — это все настраивается на уровне «wireless mode». И все виртуальные сети будут в одном выбранном режиме.
Т.е. нельзя сделать к примеру в 5G диапазоне одну виртуальную сеть AC и одну N например. Только один вариант канала, ширины, скорости и глубже уже 8шт виртуальных подсетей можно сделать.
Но возможно в других роутерах иначе и возможно в wifi6 рукусах (R550/R650/R750/R850) тоже возможно сделать такое, чтоб параллельно существовали AC и AX.
Поглядим…
Т.е. если останется хоть одно «старое» устройство, никаких wifi6 не видать?
Я год или два назад наконец изжил последний 2.4ггц девайс чтобы оставить точку доступа исключительно в 5ггц режиме. А теперь впереди новая борьба за AX…
Аналогично можно вместо .htaccess все правила в конфиг apache записывать и чтоб он считывался только при перезапуске, а не при каждом запросе. И тогда можно allowoverride выключить — один из самых замедляющих апач нюансов (поиск и чтение .htaccess'ов при каждом запросе).
Но как этим будут управлять пользователи?
Или по вашей схеме — исправит чел что-то в .htaccess своем и как nginx должен будет узнать об этом? Только перечитав этот файл. Но если он начнет также как апач искать, читать и выполнять все .htaccess'ы, то он точно также станет медленней работать. Где вообще логика?
Ну и память opcache была естественно занята в основном скриптами тех сайтов, где больше траффика. А клиенты с 2 запросами в день получается были ущемлены и у их скриптов почти каждый раз выходит «холодный старт».
Поэтому сейчас только выделенные процессы каждому с его личной памятью.
Плюс аналогично сделано с mysql. Т.к. одна общая это также плохо как shared apache.
Однако на данный момент сделано чтобы было: 1 пользователь = 1 ветка apache/mod_php с одной версией php. Все прозрачно и понятно, 1 пользователь = какое-то макс число памяти и процессов. Кому нужно больше — берет тариф выше с бо́льшими лимитами и на другом сервере с меньшим числом соседей.
Но. Изредка возникают вопросы у пользователей, которые в пределах одного аккаунта хотят разные версии php для разных сайтов. Сейчас просто делается ему новый аккаунт под новую версию php. Опять же, логично, пользователь хочет еще один «блок» из памяти и числа процессов, извольте доплатить +1 тариф.
Да, можно было бы сделать как у вас: 1 пользователь = до 8 пар (число версий php) apache/mod_php под разные версии, но как тогда ограничивать память и процессы, но чтоб все по справедливости было? А не так что одни сайты под одной веткой занимали чего-то больше и ограничивали другие под другой. Либо без ограничения, но тогда потенциально пользователь сможет 8-кратно превысить лимиты своего тарифа.
По вашей картинке выходит, что у user 2 его единственному сайту доступно все по максимуму в пределах его тарифа. А у user 1 как? Apache 7.1 и 7.2 делят пополам макс. предел по процессам и памяти? Или не пополам, что один из сайтов может перетянуть все одеяло на себя и клиент не будет понимать почему второй сайт хуже работает? Т.е. теоретически если человек добавит 8 сайтов и все под разными версиями php, то каждый из них будет по сути в 8 раз более ограничен, чем если бы все сайты были под какой-то одной версией php. В общем не понятно как у вас реализована дележка числа процессов и памяти между разными апачами в пределах одного аккаунта.
веганов, не понимающих зачем нужен apache, которым обязательно необходимо всему миру сообщить что они 10 лет ужене едят мясоне пользуются apache.А те кто пользуются — просто злые из-за
мясатормозящих под apache сайтов.Вы бы запустили свой хостинг, чисто с nginx + php-fpm. И объясняли бы каждому клиенту, что он просто тупой раз не может обойтись без apache.
Лично не раз нужны были мелкие vps под тот же vpn или почту или dns.
И в «flags» было всего ничего…
Не каждый день, а постоянно. Плюс настроены мониторинги. В случае если вдруг кто-то сильно грузит процессор к примеру, сразу же прилетает уведомление и вручную разбирательство проводится. Чаще всего это набег какого-то тупого бота-брутфорсера или подобного. Тут же он банится и все, клиент даже не узнает о том что что-то было.
Бывают конечно сложней ситуации, когда просто сайт тормозной у клиента и даже небольшой наплыв посетителей или ботов превращаются в заметную нагрузку на cpu. В этом случае также вручную индивидуально все решается. Путем улучшения самого сайта клиента, а не путем завинчивания ему гаек или переселения на другой сервер.
Плотность рассадки зависит от тарифа. Все минимальщики на одном, там действительно в основном пару-страничники простенькие. Хотя всякие есть…
У кого размеры сайтов по-больше, тем и тариф выше требуется — эти на следующий сервер с существенно меньшей плотностью населения. И так далее, на сервере где максимальные, там вообще 4 аккаунта вот сейчас.
Самое главное что ничего не перегружено и ничего ни у кого не тормозит ни где, на любом тарифе/сервере.
Повторяю еще раз, если кого действительно заинтересовало то о чем говорю, обращайтесь. Бесплатно аккаунт на неделю чтоб расставить все точки и лично сравнить то что есть и то как может быть по-другому.
А теоретически философствовать можно конечно бесконечно. У каждого будет своя правда. Кто-то «наелся» шаредов на том самом cloudlinux с тучей мелких ограничений, не дающих спокойно дышать сайту и теперь конечно на vps ему вроде как хорошо. Или шареды были по железу серверов не лучше (или даже хуже) vps'ных — медленные процессоры, диски и т.п.
Есть сайты-магазины не маленькие, объемом всего добра под 100гб и траффиком иногда в районе 500мбит и 1000 запросов/сек. Да, это не на самом дешевом тарифе конечно, но все еще на shared'е.
В php можно практически все настроить под себя т.к. оно (apache/mod_php или php-fpm) работает независимо под каждого пользователя.
SSH — есть даже на самом мин. тарифе.
Мой посыл лишь в том что за те же или чаще большие деньги на vps конечный результат (скорость работы сайта) получается заметно хуже. Ввиду специфики — обрезан процессор по ядрам и слаб по частоте.
«Они» — это почти 99% пользователей shared хостинга.
По вашей логике надо убрать апач и работать лишь с тем 1% с сайтами чисто на статике или без cms, использующих .htaccess?
А еще тут есть персонажи, кто с php 5.4 никак не съедет… а вы говорите апач выкинуть.
Все просто — если у этого хостера не будет нужного клиенту софта, он пойдет к другому.
А автору пожелаю лишь скорей прийти к пониманию, что от сторонних «продуктов» надо уходить. Есть вы и есть клиенты ваши. Они видят проблему и требуют решения именно от вас. Вы же вместо максимально быстрого решения оббиваете чужие пороги — cloudlinux, ispmanager…
По этой причине в своем хостинге изначально решил, что не будет никогда никаких чужих «панелек», в которых поди разберись в случае если что-то пойдет не так. Клиенты будут стоять над тобой и дышать в спину т.к. их не волнуют все эти нюансы. Они лишь видят что у этого хостера что-то не работает, значит пойдем к другому.
Так что весь используемый софт надо знать лично от и до, в точности понимать как и что работает, не надеясь что кто-то другой сделает лучше. Ошибки случаются у всех, но свои ошибки куда быстрей можно обнаружить и исправить.
Уж не знаю с кем именно и какой опыт был, но!
Если будет время/желание развеять мифы и стереотипы про шаред хостинг, обращайтесь.
По указанным вами пунктам: все ПО не из комплекта операционок, а самостоятельно собирается из исходников и есть все актуальные и самые свежие версии — php до 7.4 и собираюсь на днях даже для экстремалов собрать 8.0 alpha 1. Все сопутствующее барахло типа ioncube и т.д. запчастей также самое свежее имеется.
Базы MariaDB до 10.5 и тоже можно выбрать более раннюю версию. А возможно также добавлю в скором времени на выбор и оригинальные MySQL разных версий.
Nginx (последний), Let's Encrypt само собой есть и wildcard тоже.
За nginx фронтом у каждого пользователя стоят личные независимые процессы скриптового бэкэнда на выбор из apache/mod_php или php-fpm. Тоже самое с mysql — процессы независимые у каждого, а не один общий на всех. Естественно у каждого свои настройки php.ini и my.cnf
Т.е. если что-то у кого-то падает, тупит или нагружается, то на соседях это практически не отражается. И что даже еще более важно — вся занимаемая память процессами пользователя — его личная. Opcache в php весь ваш и соседские скрипты не будут пытаться вытеснить ваши из него. Кэш запросов и остальная память mysql — тоже принадлежит именно одному пользователю, а не тому кто больше запросов делает. Плюс в mysql слишком большой размер кэшей может сделать только хуже в плане производительности.
Оттюнить себе mysql как-то особенно, наставить модулей хитрых или наоборот максимально облегчить php — не проблема, практически ничего невозможного нет.
В общем по гибкости не сильно хуже VPS, но:
1) Вам не надо ничего администрировать и вообще вникать во что-то иное, кроме ваших сайтов. За вас все сделают, настроят и присмотрят как за детьми малыми. В отличии от VPS, где в вас обычно бросят root'ом и дальше живите как хотите.
2) Железо. Не заметил ни слова даже о частотах процессоров, только какие-то условные «ядра». Вы же понимаете, что это чуть ли не самое важное от чего зависит именно скорость работы сайтов. Если у хостера на сервере 128 ядер, то это лишь для того чтоб продать его большему числу клиентов, а вам то что с того? Почти любая VPS это обычно 2-2.5Ггц ядра. Если больше, то за это уже и совсем другие деньги просят. А вот shared'у не надо ядрами торговать и допустим на 4Ггц частоте сайты ворочаются раза в 2 шустрее.
SSD, а ныне новомодное NVMe в каждой рекламе. Но опять же, хостеру надо максимально большой объем чтоб визуально более выгодные тарифы предложить да и на большее число клиентов ее поделить. А вам? Именно вашему сайту скорей всего ни холодно ни жарко от 2-3Гб/сек при последовательном единоличном доступе крупными блоками, вы же не фильмы гонять будете по диску своему. И сотни тысяч IOPs тоже ведь достигаются лишь за счет множественных параллельных обращений клиентов/соседей.
Все что хочет среднестатистический сайт на том же wordpress к примеру — это по-выше частота процессора, по-больше памяти и быстрей да больше количество операций с диском при случайном доступе мелкими блоками. И сила тут либо за старыми добрыми SLC и MLC, либо за самыми передовыми Optane. В массовом хостинге же практически поголовно «оптимальные» по цена/объем TLC/QLC и т.д. ширпотреб и явный поворот не туда, в сторону к HDD, а не действительно к скорости и производительности. Хоть и под лэйблом NVMe. Там SLC кэш заканчивается и все, NVMe превращается в тыкву.
Также на shared'е вам доступны все ядра процессора и они полноценные, а не обрезки (без AES к примеру) как это часто бывает на VPS. Память выделяемая вам — она по максимуму используется именно сайтами вашими. На vps же надо тратиться еще на всю остальную операционку и доп. софт который по-любому ведь будет необходим — почта, фтп, возможно панелька какая-то и т.д.
В общем, если заинтересовал действительно правильный shared хостинг или не устраивает скорость работы сайта на каком-то существующем, приглашаю на бесплатный сравнительный тест.
Если какой-то сайт тормозит, виноват не сам сайт и не его хостинг, а провайдер!
«Я плачу деньги» провайдеру, и если что-то не получаю по заявленной в тарифе скорости, значит провайдер плохой!
Скорей вот так думают ваши соседи, а вовсе не бегут покупать новый роутер.
1) В двух разных концах квартиры картина может меняться на противоположную. На какой тогда спрашивается канал вешать роутер, стоящий в центре?
2) Вы сейчас все оцените, настроите правильно, порадуетесь улучшению. А через 5 минут соседские точки перепрыгнут на другие каналы. На этом все и закончится.
Возможно поэтому в lite host владелец работает один, предпочитает не связываться с наемными пока справляется и сам.
А тут же в статье речь про совсем другой уровень отношения. Владельцу хостинга не наплевать на каждого из своих клиентов. И у него ВСЕ под контролем. Каждый мелкий нюанс. А у крупных можно ожидать ответ лишь в области компетенции отвечающего. Запросто могут вас «буцать» по разным «спецам», каждый из которых еще в меру своей лени/загруженности должен вникнуть в Ваш вопрос…
Тоже кстати пользуюсь lite host'ом (один из 10+ самых разных) и доводилось однажды контактировать. Действительно очень быстро задача решалась, а не отмашки и отписки как это почти поголовно у любой крупной (не только хостинговой) компании.
А насчет пингов. Вы же понимаете, что геолокация тут очень большую роль играет. И это вовсе не показатель «быстроты». Но 20-75мс в любом случае не плохо, даже если пинг между ботом яндекса и сервером 1мс. Но это врядли заслуга LiteSpeed и врядли тот же Nginx сильно хуже результат бы показывал.
Оказывается надо искать sunlight… китайцы одним словом.
Интересно на сколько все заявленное соответсвует?
Хотелось бы для самоделок, фотоподсветки и т.п. взять на пробу, но приборов для проверки нет. Обидно если буду думать, что получаю ровный спектр, а на самом деле нет.