У себя использую уже несколько лет исключительно 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… китайцы одним словом.
Интересно на сколько все заявленное соответсвует?
Хотелось бы для самоделок, фотоподсветки и т.п. взять на пробу, но приборов для проверки нет. Обидно если буду думать, что получаю ровный спектр, а на самом деле нет.
никакого проекта нет. просто решил глянуть результат на одном из своих серверов (300+ сайтов на борту).
скачал демо и установил на пустой истекший домен.
оно конечно не всегда столько, в среднем 230-250, но и до 260 проскакивает.
можно на ник клацнуть и найти ссылки на хостинг.
если заглянуть в прошлую статью, то все станет ясно.
там была именно термопаста и именно вот так — не полностью со всеми частями процессора соприкосалась. так задумано.
ну результат есть? есть. значит стоило.
другой вопрос что может и правда другая термопаста дала бы почти тот же эффект.
это узнаю лишь еще через пол года.
и если тогда получится ближе к 80 градусов результат, то и в 3й раз намажу жм :)
проверю, но еще через пол года.
сейчас была задача намазать жм заново и убедиться что все снова заработает (медный радиатор не утратил безвозвратно теплопроводность в том месте)
Ну и память 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… китайцы одним словом.
Интересно на сколько все заявленное соответсвует?
Хотелось бы для самоделок, фотоподсветки и т.п. взять на пробу, но приборов для проверки нет. Обидно если буду думать, что получаю ровный спектр, а на самом деле нет.
а ночью наверное 300+ стабильно будет.
обращайтесь кого заинтересовало. неделю бесплатно потестировать можно.
скачал демо и установил на пустой истекший домен.
оно конечно не всегда столько, в среднем 230-250, но и до 260 проскакивает.
можно на ник клацнуть и найти ссылки на хостинг.
Производительность: 260.12
на shared'е за 50р/мес.
в который раз убеждаюсь, что vds и скорость несовместимы :-\
вот, то же самое проделали. и тоже на голый медный радиатор.
или я не вижу нужной кнопочки.
там была именно термопаста и именно вот так — не полностью со всеми частями процессора соприкосалась. так задумано.
это просто железки, что над ними трястись от страха.
они морально устаревают гораздо быстрее.
другой вопрос что может и правда другая термопаста дала бы почти тот же эффект.
это узнаю лишь еще через пол года.
и если тогда получится ближе к 80 градусов результат, то и в 3й раз намажу жм :)
сейчас была задача намазать жм заново и убедиться что все снова заработает (медный радиатор не утратил безвозвратно теплопроводность в том месте)