Pull to refresh
0
0
Дмитрий @redfs

Программист

Send message
ресурс технический, а у вас получается теплое и мягкое
Существует десятки технических аргументов для переноса инфраструктуры компании в облако. Как и контраргументов. Их я готов обсуждать на техническом языке. Но автор в половине своей аргументации буквально говорит «у вас в компании сисадмин — вор, поэтому переходите к нам в облако». По тексту получается, что это самый сильный его аргумент. И он не технический.
Да пожалуйста…
Необходимость содержать в штате специалиста, который мог бы сервер собрать, настроить и в дальнейшем обслуживать
Враньё.
Постоянные страхи того, что что-то выйдет из строя пока этого специалиста нет на месте
Опять враньё или неправильно выбранный ЦОД
Не всегда возможно оперативно попасть на место размещения оборудования ночью или в выходной день для замены комплектующих
Непрофессиональная организация работы или неправильно выбранный ЦОД
Вам придется на веру принимать обещания системного администратора на тему сохранности данных в случае выхода из строя какого-либо диска
Отвратительно
Если что-то на сервере выходит из строя, потребуется несколько дней на выяснение причин, покупку нового комплектующего и его установку. Или же в лучшем случае 1 день если, разумеется, вы заранее все запасные комплектующие храните в непосредственной близости к самому серверу – это время пока ваш бизнес и все сотрудники не работают!
Или враньё или неправильная организация работы + неправильно выбранный ЦОД
Во время работы уже готового сервера недобросовестные системные администраторы могут симулировать выход из строя той или иной части сервера для ее замены и последующего присвоения списанной
Отвратительно
В момент закупки оборудования рекомендации системного администратора по месту их приобретения могут включать его собственный интерес
Просто мерзко.

Существует множество нормальных аргументов за переход от физики к виртуализации, на Хабре я читал несколько вполне аргументированных статей, в том числе с разбором — когда это стоит делать, а когда нет. Но аргументы в виде «нечистого на руку админа» — это за гранью добра и зла уже…
Коллеги. Я ничего не имею против виртуализации, но ваша аргументация за отказ от физики непрофессиональна и местами отвратительна. Складывается ощущение, что у автора богатый опыт обмана руководства.
Akin, David
UMD, Associate Professor
Director of Space Systems Laboratory
Department of Aerospace Engineering
Это вещь известная и просто шикарная. Бауманка оценит :)
Есть еще версия с пояснениями и примерами

И да… Этот текст имеет больше отношения к управлению разработкой (особенно в РКТ), чем многие модные сейчас методологии. Спасибо за перевод!
Для порядка надо бы добавить фразу о том, что это решение подходит для сайтов с небольшой нагрузкой.
Так это тоже важное примечание к вашей статье (кроме медленного канала).

Т.е. для того, чтобы посетитель сайта видел хоть какой-то эффект от применения данной технологии верстка сайта должна соответствовать следующим требованиям: 1)… 2)… 3)…

Кмк, овчинка выделки точно не стоит.
Нет, ваша технология заточена на другую метрику — First Paint (FP) — первая отрисовка.
Мне кажется, что тенденция все-таки — First Meaningful Paint (FMP) — первая значимая отрисовка. Вы и сами знаете, что пользователь сильно не любит, когда страницу «колбасит» и чаще всего просто ждет полной отрисовки контента. Я говорю о посетителях сайта, а не о всяких там SEO-шных заморочках.
Понятно, если под загрузкой страницы понимать появление её на экране, без ожидания отработки неблокирующих запросов.

Мне все-таки как то понятнее вот так:
window.onload is not the best metric for measuring website speed
(с) Steve Souders
Источник, 5 лет статье
Вообще nazarpc понять гораздо легче, чем вас. На чем вы экономите? На двух запросах (css + js), которые потенциально могут вернуть 304? Тогда вопросы — а сколько изображений на типичной странице вашего сайта? Никаких счетчиков конечно же на странице нет?

Честно говоря, ваши рассуждения выглядят неубедительно, тем более, что они не подкреплены тестами.
Навскидку глядя на схему — что мешает получить куку ct_anti_ddos_key, а потом атаковать сайт, подставляя ее в запросы?
А как часто обновляются данные?
Я проверил blog.jetbrains.com
Сожалеем, ресурс blog.jetbrains.com находится в списке заблокированных ресурсов на территории Российской Федерации!
Он действительно был блокирован несколько дней, но уже почти сутки, как доступен.
то уж будьте готовы и сами соблюдать законы
Вы совершенно правы. Но в равной степени это должно относиться и РКН, который по закону должен блокировать телегамму, но почему то решил работать «по площадям» и накрыл всех «мирных жителей», которые стояли рядом. Статья 330 УК «Самоуправство»?
Ведь люди, которые это все затеяли, они же совершенно не понимают что именно они делают с реальным миром. Просто пришла идиотская команда от какого-то недоумка
На мой взгляд, это довольно оптимистичный вариант (хотя бы потому, что ситуацию в теории можно поправить). Гораздо хуже, если это элемент в какой-то многоходовке и люди прекрасно понимают, что они делают и зачем…
Пишут, что и до Azure РКН добрался.
более оптимальные
Понятие оптимальности не является универсальным. В вашем случае это могут быть оптимальные способы, в моём — они совершенно не подходят.
И гугло-яндекс-боты соответственно понижали вас поисковой выдаче =)
Да с чего бы вдруг? Вообще не вижу никакой связи. У нас был аналогичный и, по моему, единственный случай — набегал бот с User-Agent: WebIndex, создавал большую нагрузку и был заблокирован только из за этого. Остальных ботов это никак не коснулось, пусть сканят на здоровье.
А давайте, вы не будете гадать? Было бы вежливо попросить показать конфиги и на основании их уже строить какие-то умозаключения. Ну, отвечу в таком же стиле — с конфигами все нормально.

Я просто оставлю этот график мониторинга одного из бэкендов за год здесь. Простая замена mod_php на php-fpm на бэкенде и переход с prefork на event в связи с тем, что prefork стал не нужен, в январе без изменения производительности бэкенда. Видно, что добавили немного оперативки, но могли этого не делать.
График
image
А где именно её используется больше?
Естественно на конфигурации apache+mod_php. Вы удивитесь, но на нагруженных тяжелых проектах разница — «разы». Завтра с работы попробую продемонстрировать наглядно — графиками munin (если интересно). Просто за счет отказа от mod_php на бэкенде нам на том же самом железе удавалось увеличивать производительность (количество обслуживаемых запросов в единицу времени) в несколько раз (естественно, с нормализацией) только за счет освобождения оперативной памяти.

Следующим шагом всегда шел отказ от Apache (что логично), если только не использовались специфические или самописные модули для него.

Information

Rating
Does not participate
Location
Россия
Registered
Activity