Все достаточно просто, в 2010 году у всех хостинг компаний была партнерка отдельно от хостинга, в итоге многие регистрировались в партнерской программе и потом регистрировали себе аккаунт. В правилах это обычно запрещалось и хостингам приходилось блокировать такие аккаунты - и вот тут начинался конфликт.
Мы решили эту проблему по другому - аккаунт хостинга и партнерки единый, мы не запрещаем сами себе регистрировать аккаунты по партнерской программе. Ну и мы подумали, если пользователь нас рекомендует - почему же он не использует наши услуги ?
Отзывы о продукте который используешь (вне зависимости от того плохие они или хорошие) будут более объективные чем просто отзывы для привлечения клиентов.
У нас есть несколько исключений из этого правила, но по каждому из них можно сказать "так исторически сложилось".
Тоже не совсем корректно - sprutio еще стоит у netangels https://www.netangels.ru/company/news/2016/fm и насколько мне известно у нескольких европейских компаний.
Хотя у меня другой вопрос - а какое у Вас отношение к панели управления cp.beget.ru - нравиться/не нравиться ?
Я бы это прокомментировал, так как в принципе разрабатывал sprut.io, настоял что бы его выложили в OpenSource. Вы написали не правду - в низу я приложил скриншот. Опять же все изменения есть на github.com, так что это работало всегда. Основное преимущество данного файлового менеджера - он работает на стороне сервера.
То есть если Вам надо скопировать сайт скажем который весит 20-50 гигабайт, это можно сделать на скорости сервера, не копируя все данные к себе на компьютер. В принципе это же можно сделать и в консоли с помощью mc - это вопрос удобства.
В принципе считаю, что если бы в России хостинг компании выкладывали свои разработки в OpenSource было бы гораздо больше хороших продуктов.
Вы переоцениваете мою заинтересованность с точки зрения рекламы или клиентов. Но вот опыт подбора оборудования и куча экспериментов - у меня явно есть. Я повторюсь все зависит от множества факторов, начиная от того что за проект, заканчивая тем какая нагрузка. И вы явно недооцениваете мою любовь в цифрам и измерениям =)
Грубо говоря, если один запрос в сутки - это одна конфигурация оборудования, если высоко-нагруженный проект - другая. Как сравнивать скорость ? При одном запросе или при 50 одновременных. Так же можно нарисовать график изминения скорости загрузки при увеличении нагрузки.
Починил - mysql -hmanikin.beget.ru -P3306 -uread_only -pread_only, там на серваке бардак, все руки не доходят в порядок все привести.
Частота это не показатель, для примера если сравнивать чистоты Xeon E5 первого поколения и E5 четвертого поколения - разница производительности будет в некоторых случаях более 100 процентов. А вот конфигурацию с удовольствием покажу:
но опять же все еще сильно зависит от ПО, количества клиентов, настроек MySQL, настройке кешей.
Не соглашусь =). Достаточно сравнить нагрузку и параметры серверов что бы опровергнуть это утверждение.
Очень сложно ответить на Ваш вопрос - больше да чем нет. Это тоже самое что спросить: влияет ли тип двигателя на грузоподъемность автомобиля.
В большинстве случаев, по логике вещей ответ будет - Да.
Хоть 60 шкафов, при этом все еще и медленней работать будет. Скорость доступа к конкретному байту будет медленной если данные не закешированы в RAM. Фактически то, что Вы говорите 5200/7200/15000 - это скорость вращения шпинделя, она как раз и влияет на скорость рандомного чтения/записи. И разница с SSD будет на порядок. Так как SSD не нужно позиционировать механику.
Странно что приходится приводить такой пример: но предположим SSD - это порше, небольшого объема но который может быстро доставить чепловека из точки А в точку Б. HDD - это микроавтобус, медленный но может перевозить много людей.
У них есть параметры: скорость доставки, количество пассажиров (в данном случае линейное чтение, а не объем и SSD тоже выигрывает), цена...
Вы говорите: смотри берем парк минивенов, грузим их людьми и везем, в итоге среднее время на одного человека не такое уж и большое. Но время перевозки конкретного человека на порядок больше чем у порша.
В итоге: нет, хранить БД в 2018 году на HDD, это идиотизм, сделайте обычный тест - загрузите в MySQL 2 гига данных без индекса и сделайте поиск. И посмотрите как это будет работать на SSD и как будет работать на HDD.
Если Вам надо хранить бекап, холодные данные, архивы, возможно картинки - ok, HDD имеет место быть, стоимость гигабайта на нем сильно ниже, других преимуществ у него нет. Если Вам нужен быстрый доступ к данным - только SSD, или кешировать в RAM.
По этому еще раз повторюсь - исключительно SSD.
Если Вы говорите что это нормально, назовите 5 провайдеров в России или в мире которые для хостинга используют hdd ? Подключаемые хранилища на VPS/облаках не в счет.
я редко отвечают на данном форуме, господа Вы не правы в этом. Ключевой параметр отличающий SSD от HDD - это время доступа. Данный параметр влияет как на время случайного чтения, так и на время случайной записи.
Если со временем случайного чтения, еще можно бороться увеличивая объем оперативной памяти, так как дисковый кеш храниться как раз в RAM, скажем так у нас на серверах с 500+ гигабайт памяти чтения с дисков почти нет. То со записью все сложней, есть RAID контролеры с встроенной памятью и такими страшными словами как write-through и write-back. Но это не дает нужного результата, требует батареек или суперконденсаторов (которые тоже раз в 2 года надо менять, хотя по диагностики все ок).
Если горячие данные то о HDD речи идти не может, есть гибридные технологии - но в плане виртуального хостинга сейчас это уже не оправдано - уже давно есть серверные SSD на 2 терабайта. Скорее сервер упрется в процессор, память, сеть, масштабируемость ПО нежели в объем диска.
Конечно из каждого правила есть исключение, но не думаю что в данном случае речь идет про такое исключение.
Подмена заголовков писем, отправляемых через php mail()
При отправке почты через данную функцию на конечных серверах выполняется проверка "направлен ли домен из поля from на наши сервера?" И является ли владельцем данного домена аккаунт, с которого осуществляется отправка:
1) Проверяется, что A запись этого домена принадлежит нашим диапазонам ip адресов.
2) Проверяется, что к текущему аккаунту прикреплен домен.
3) Оба условия не проверяются если для аккаунта или ящика установлено исключение.
Если хотя бы одно из условий не соблюдается, то значение поля from письма заменяется на noreplay@unveriified.beget.com. Оригинальное значение поля from сохраняется и записывается в reply-to. Оригинальные значения сохраняются в полях:
Отдельная логика используется для сервисов на подобии CloudFire, где A запись указывает не на наш сервер.
