Самые быстрые хостинг для РФ

я лишь хотел донести мысль, что если надо именно скоростной, то вот вам критерии скоростного. по ним и выбирать нужно. а не по лапше ушной по форумам, отзывам купленным, репутациям ничего не значащим.

даже в пределах одного хостера, железки могут очень сильно отличаться.

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

и снова вот эти недопонимания... "проц менее 20%", "хватит и 2.2" - нет! это никак к "быстрые" не относится.

загруженность проца никак не связана с его именно скоростью.

это грубо говоря очередь к кассе, а не скорость с которой вас на кассе обслужат.

даже если очереди не будет (0% загруженность) не значит что вас быстро обслужат.

может казаться что достаточно и 2.2, но лишь до поры пока не попробуете тот же сайт на 3.5+ к примеру.

согласен, что 90% народу пофиг на это все. они не отличат 0.5с от 1с.

но все же повесить один и тот же сайт (практически любой) на 2.2 и 3-4ггц - даже визуально будет заметна разница. просто мало кто сравнивал в одинаковых условиях. максимум 2-3 хостеров пробовали наугад, без конкретной цели найти быстрый.

а большинство какраз медленные и есть.

Как правило в современных CMS всё так закэшировано, что практически всегда nginx отдаёт html а не php выполняется в Apache.

nginx-у частота процессора не столь критична.

1. Кто бы что ни говорил, а расположение сервера тоже имеет значение. В этом плане предпочтительнее хостить проекты имеено в России.

2. Если долгий отклик html файлах, то грешить на корявость движка, как минимум глупо.

3. Выбирайте хостинг на NVMe SSD дисках c CloudLinux + CageFS для разделения ресурсов между пользователями. Еще можете посмотреть в сторону серверов LiteSpeed.

---------- Добавлено 16.05.2019 в 21:02 ----------

Да, но с другой стороны, если хостеру наплевать на скорость загрузки собственного сайта, то как можно рассчитывать, что на клиентских серверах у них все будет быстро работать..

т.е. то что вы 3005 в очереди вас не смущает ?

за то если вы 100500 в очереди то частота даже в 5.5 гигагерц вас гарантированно не спасет.

Вы видимо намеренно или по глубокому не пониманию игнорируете тот факт что веб проекты рассчитываются на массовое посещение.

для веб проекта намного важнее если

1 посетитель увидит сайт через 0.2 секунды

10 посетителей увидят сайт через 0.2 секунды

100 посетителей увидят сайт через 0.2 секунды

1000 посетителей увидят сайт через 0.4 секунды

чем вариант:

1 посетитель увидит сайт через 0.05 секунд

10 посетителей увидят сайт через 0.1 секунды

100 посетителей увидят сайт через 0.9 секунд

а 1000 посетителей увидят сайт через 5 секунд потому что у сервера LA взлетел под 1000 и он умер в прерываниях

не надо перекручивать.

если кто-то 3005й в очереди, то и LA там соответствующий. а значит нужно наращивать количество ядер. это и так понятно.

но когда речь идет за vps с 1-2 ядрами обычно, когда процессор не загружен, понятно что нет никаких 100500 запросов в секунду. а значит в чем проблема использовать 1-2-4 быстрых ядра вместо медленных?

вот когда посетителей на столько много, что количества быстрых ядер уже не хватает, тогда только можно идти на компромис, жертвовать скоростью ради "мощности". ухудшить время, но чтоб 1000 вместо 100 смогли увидеть сайт.

а когда траффика нет, когда ядер много не надо, о чем спор может быть? не вижу причин использовать медленные ядра. не надо тут цифрами с кучей нулей пугать никого.

кто видел цифры в 1000 запросов в секунду, тот и vps в принципе не рассматривает.

в основном в одно и то же время 1-10 посетителей и есть. а то и меньше.

так лучше же чтоб у них сайт открылся за 0.05-0.1, чем за 0.2?

короче "кассы" должны быть по возможности максимально быстрые, это же очевидно.

а вот их количество уже надо смотреть в зависимости от числа посетителей. не только суммарное, а и в часы пик.

LA для того и придумали. чтоб по нему количественно оценивать "ожидающих". если будет подъем заметный, значит ядер мало.

а просто так, без траффика ставить 4шт 2ггц ядра... смысл? чтоб суметь отбить какой-то теоретический всплеск, жертвуя при этом скоростью во все остальное время? лучше уж 2шт, но более быстрых.

будет мало, добавите. а вот когда реально нужно будет 8+ ядер, тогда это уже совсем другая история.

EvGenius, изанчально ТС спрашивал про хостинг, я так понимаю, не про vds/vps, где особо параметры не выберешь.

А если вернуться в нашу полемику, то процессор 3.4 дороже, чем 2.2 и поэтому при выборе vps нужно понимать, что за проект, какой бюджет у тебя и на что обратить внимание:

ОЗУ, количество ядер и частота, объем и тип накопителя, скорость канала, защита

Если это не загруженный проект, что лучше

Больше оперативной памяти, но проц 2.2 (3 или 4 ядра) или минимум памяти, но проц 2x3.4 ? (не, тут я уже серьезно спрашиваю, для себя)

Ведь может так случиться, что запрос в mysql не оптимизирован и выборка "пожирает" ресурсы.

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

EvGenius, вы немного ошибаетесь в сущности вэб проектов, я видел цифры в 1000 запросов в секунду, и все это крутилось на пачке виртуалок с лоад балансером.

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

А так никто вам конечно не запрещает при запросе пользователя к сайту начинать конвертировать видео например, но это уже не про адекватность. Когда расчетов нет 2.2ГГц или 5Ггц разница не особо то и видна, так как она составляет сотые, а то и тысячные секунды.

скажем так какая задержка будет считаться нормой ? 7-10 мс ?

Задержка чего ? (dns, ssl, первый байт, полная отрисовка)

Задержка откуда до куда ? (из домашней локалки в Москве до дата-про в Москве или из хостела в Сингапуре до Хетцнера)

Вот команда чтобы измерить:

 curl -4 -s -w '\nLookup time:\t%{time_namelookup}\nConnect time:\t%{time_connect}\nAppCon time:\t%{time_appconnect}\nRedirect time:\t%{time_redirect}\nPreXfer time:\t%{time_pretransfer}\nStartXfer time:\t%{time_starttransfer}\n\nTotal time:\t%{time_total}\n' -o /dev/null https://www.babai.ru

Lookup time:0.028627

Connect time:0.043560

AppCon time:0.082904

Redirect time:0.000000

PreXfer time:0.083094

StartXfer time:0.114501

Total time:0.129424

Это от фаствпс в Прибалтике (раз про них автор темы спрашивал) до дц Фиорд в Москве.

И обратно из дц Фиорд в Москве до фаствпс в Прибалтике:

 curl -4 -s -w '\nLookup time:\t%{time_namelookup}\nConnect time:\t%{time_connect}\nAppCon time:\t%{time_appconnect}\nRedirect time:\t%{time_redirect}\nPreXfer time:\t%{time_pretransfer}\nStartXfer time:\t%{time_starttransfer}\n\nTotal time:\t%{time_total}\n' -o /dev/null https://suffix.cloud

Lookup time:0,029

Connect time:0,044

AppCon time:0,129

Redirect time:0,000

PreXfer time:0,129

StartXfer time:0,227

Total time:0,227

Попросите администратора оценить состояние сервера в проблемные моменты. Тогда вы узнаете в чем конкретно у вас проблема и будете знать как решать. Прыгать туда-сюда не вариант. Возможно там 1 параметр в конфиге сменить нужно и все полетит.