alexeyymanikin

Рейтинг
131
Регистрация
20.09.2008
apollion:
Файл-менеджер бегета как раз таки гуано, он не видел скрытых файлов и .htacsess. Не знаю может сейчас починили, я им не пользуюсь. Но нахрен он нужен если есть Файлзилла - наше всё. Про всякие CuteFTP и т. д. я и не говорю.

Я бы это прокомментировал, так как в принципе разрабатывал sprut.io, настоял что бы его выложили в OpenSource. Вы написали не правду - в низу я приложил скриншот. Опять же все изменения есть на github.com, так что это работало всегда. Основное преимущество данного файлового менеджера - он работает на стороне сервера.

То есть если Вам надо скопировать сайт скажем который весит 20-50 гигабайт, это можно сделать на скорости сервера, не копируя все данные к себе на компьютер. В принципе это же можно сделать и в консоли с помощью mc - это вопрос удобства.

В принципе считаю, что если бы в России хостинг компании выкладывали свои разработки в OpenSource было бы гораздо больше хороших продуктов.

miketomlin:
Вы заинтересованное лицо =). Я многолетний держатель сайтов и там, и там. Уже сто раз сравнивал. И не только я.

Вы переоцениваете мою заинтересованность с точки зрения рекламы или клиентов. Но вот опыт подбора оборудования и куча экспериментов - у меня явно есть. Я повторюсь все зависит от множества факторов, начиная от того что за проект, заканчивая тем какая нагрузка. И вы явно недооцениваете мою любовь в цифрам и измерениям =)

Грубо говоря, если один запрос в сутки - это одна конфигурация оборудования, если высоко-нагруженный проект - другая. Как сравнивать скорость ? При одном запросе или при 50 одновременных. Так же можно нарисовать график изминения скорости загрузки при увеличении нагрузки.


[offtopic]
Алексей, приветствую! Когда пофиксите? :) или тема мертвая?
[/offtopic]

Починил - mysql -hmanikin.beget.ru -P3306 -uread_only -pread_only, там на серваке бардак, все руки не доходят в порядок все привести.


Подскажите частоту процессора на ваших серверах.

Частота это не показатель, для примера если сравнивать чистоты Xeon E5 первого поколения и E5 четвертого поколения - разница производительности будет в некоторых случаях более 100 процентов. А вот конфигурацию с удовольствием покажу:


digger : ~ [0] # cat /proc/cpuinfo

....

processor : 71
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz
stepping : 4
microcode : 0x2000043
cpu MHz : 2300.000
cache size : 25344 KB
physical id : 1
siblings : 36
core id : 27
cpu cores : 18
apicid : 119
initial apicid : 119
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb invpcid_single ibrs ibpb stibp kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 4603.45
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:

digger : ~ [0] # free -m
total used free shared buff/cache available
Mem: 515472 274353 68014 64203 173103 17859
Swap: 0 0 0


digger : ~ [0] # df.sh -h
Filesystem Size Used Avail Use% Mounted on
udev 252G 4.0K 252G 1% /dev
tmpfs 51G 3.7M 51G 1% /run
/dev/md0p2 92G 46G 42G 53% /
none 5.0M 0 5.0M 0% /run/lock
none 252G 0 252G 0% /run/shm
/dev/nvme0n1p1 1.8T 557G 1.2T 32% /ssd
/dev/md0p3 6.9T 5.5T 1.5T 80% /home
none 2.0G 1.3G 798M 62% /tmp/php_sess
none 8.0G 16K 8.0G 1% /home/tmpfs
/dev/loop0 20G 420M 20G 3% /home/beget/sprutio
cgroup 252G 0 252G 0% /sys/fs/cgroup
digger : ~ [0] #

но опять же все еще сильно зависит от ПО, количества клиентов, настроек MySQL, настройке кешей.

miketomlin:
Бегет никогда не славился скоростью работы. По цене/качеству я однозначно за FOZZY.

Не соглашусь =). Достаточно сравнить нагрузку и параметры серверов что бы опровергнуть это утверждение.

Had:
Окей

alexeyymanikin, скажите, пожалуйста, на показатель - Время до первого байта (TTFB) влияет ли на чём сайт? На SSD или HDD или SAS?

Очень сложно ответить на Ваш вопрос - больше да чем нет. Это тоже самое что спросить: влияет ли тип двигателя на грузоподъемность автомобиля.

В большинстве случаев, по логике вещей ответ будет - Да.

team-voice:
Коллега, СХД это не полка на 24 диска, это могут быть 30 шкафов битком забитые полками SAS 15000
и такие системы без проблем конкурируют по IOPS с SSD системами.
Но в рамках 1 сервера , с локальными накопителями, безусловно лидерство за ССД, тут никаких сомнений. (речь правда про интерпрайз ССД высокого уровня)

Хоть 60 шкафов, при этом все еще и медленней работать будет. Скорость доступа к конкретному байту будет медленной если данные не закешированы в RAM. Фактически то, что Вы говорите 5200/7200/15000 - это скорость вращения шпинделя, она как раз и влияет на скорость рандомного чтения/записи. И разница с SSD будет на порядок. Так как SSD не нужно позиционировать механику.

Странно что приходится приводить такой пример: но предположим SSD - это порше, небольшого объема но который может быстро доставить чепловека из точки А в точку Б. HDD - это микроавтобус, медленный но может перевозить много людей.

У них есть параметры: скорость доставки, количество пассажиров (в данном случае линейное чтение, а не объем и SSD тоже выигрывает), цена...

Вы говорите: смотри берем парк минивенов, грузим их людьми и везем, в итоге среднее время на одного человека не такое уж и большое. Но время перевозки конкретного человека на порядок больше чем у порша.

В итоге: нет, хранить БД в 2018 году на HDD, это идиотизм, сделайте обычный тест - загрузите в MySQL 2 гига данных без индекса и сделайте поиск. И посмотрите как это будет работать на SSD и как будет работать на HDD.

Если Вам надо хранить бекап, холодные данные, архивы, возможно картинки - ok, HDD имеет место быть, стоимость гигабайта на нем сильно ниже, других преимуществ у него нет. Если Вам нужен быстрый доступ к данным - только SSD, или кешировать в RAM.

По этому еще раз повторюсь - исключительно SSD.

Если Вы говорите что это нормально, назовите 5 провайдеров в России или в мире которые для хостинга используют hdd ? Подключаемые хранилища на VPS/облаках не в счет.

team-voice:
СХД на HDD может быть значительно производительнее одиночного SSD
само по себе хостинг на ХДД не говорит ровно ни о чем.
1. нормальная и для 2018 и для 2019 и даже для 2020
2. не нормально.

я редко отвечают на данном форуме, господа Вы не правы в этом. Ключевой параметр отличающий 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. Оригинальные значения сохраняются в полях:

X-Beget-Rewrite: original from 'begettest@mail.ru'
X-Beget-Rewrite: original reply-to 'vasya@mail.ru'

Отдельная логика используется для сервисов на подобии CloudFire, где A запись указывает не на наш сервер.

Вся рассылка клиентам идет исключительно с *@beget.com

Я точно не помню, но по моему site_name@unverified.beget.com - это подставляется когда не корректно указан отправитель в php mail.

все верно правилами партнерской программы это запрещено:

удешевление услуг путем перечисления пользователям вознаграждения. Это как минимум не логично и я не очень понимаю в чем сложность любому написать - хостинг со скидкой. И это нормально - продавая например битрикс мы не можем сделать его цену дешевле чем на официальном сайте. Как раз из-за сообщений на этом форуме это правило и было введено =).

Одни из крупных наших партнеров - это сайты сравнения хостингов и я понимаю, что в некоторых случаях проделана большая работа. Сделаны рейтинги, отзывы, техническое сравнение, кто-то даже видео обзоры делал (при этом количество хостингов не маленькое). Или вебстудии, которые сопровождают клиентов даже после сдачи сайтов , и в принципе когда что-то не работает пишут нам от имени клиентов - но зачем это все, можно же было просто написать - сделаю скидку.

Всего: 143