Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
По вашим же словам следует считать не время, а экономический эффект.
А кому нужен этот экономический эффект, если времени не останется на что-то другое? :) Не. Считать надо именно время. Экономический эффект может быть и не такой уж и большой (вы же имеете в виду подсчёт прибыли в виде денег?), но жизнь при этом может быть вполне счастливой из-за наличия времени, которое можно посвятить интересным делам.
чем больше серверов, тем чаще они выходят из строя
Что за бред? Вероятность сбоя отдельного сервера не зависит от количества серверов, в случае большого количества даже лучше, так как можно оперировать мат. ожиданием, а не вероятностью =)
Ну… Почему бред? Эсли у вас система состоит из одного сервера, ломающегося за год с вероятностью в 50%, то в системе из 40 таких серверов за год-то уж точно что-то да накроется. Тут надо просто условно сложить вероятности, и всё станет очевидно. То есть, компоненты системы ломаются чаще. Это я имел в виду.
у нас в регионах программист пока еще считается чернорабочим с низкой зар. платой. а сервер это вообще что-то заоблочное.
У нас тоже идет как обслуга, чуть выше уборщицы )
В этом ничего хорошего. Т.е. в малой з.п. программистов. Малая з.п. — малая ответственность — малая эффективность. Для профессионального роста программеру помимо работы надо поглощать кучу информации. И не вся она халявно лежит в инете. Что-то приходится покупать в материальном виде — книги например.
Понимаю, что вдалбливать эти истины заказчику глупо, его интересует снижение собственных затрат. Но хотя бы довести мысль, что заказанная программа, которая необходима ему при зарабатывании денег создается человеком, особо не заинтересованным в нормальном результате, поскольку получает он за это гроши.
Понимаю, что вдалбливать эти истины заказчику глупо, его интересует снижение собственных затрат. Но хотя бы довести мысль, что заказанная программа, которая необходима ему при зарабатывании денег создается человеком, особо не заинтересованным в нормальном результате, поскольку получает он за это гроши.
Спасибо, капитан.
Ваше утверждение относится только к одному классу задач — длительные вычисления. Но именно там и стараются писать на компилируемых языках. Да, решить большую задачу за 30 минут лучше, чем решить её за час. Но какая разница, если сайт на похапе отвечает за 100 мс, а сайт на Си за 50мс? Пользователи этого сайта вовсе не сэкономят себе 50% времени, если вы его перепишете на Си.
Пользователи не сэкономят, а служба поддержки, которой надо будет в два раза меньше серверов обслуживать — сэкономит. И разве я написал, что всё надо писать на Си? Речь совсем о другом. О том, что надо думать о времени, а не о баллансе между количеством серверов и программистов — это не особо релевантно.
Хотелось бы услышать начальника транспортного цеха программистов, да и работодателя.
Есть ли гарантия, что на поддержку более оптимизированного кода уйдёт меньше времени, сил и денег чем на поддержку тормозного варианта?
И вообще, откройте уже хабра-сообществу тайный смысл топика?
Есть ли гарантия, что на поддержку более оптимизированного кода уйдёт меньше времени, сил и денег чем на поддержку тормозного варианта?
И вообще, откройте уже хабра-сообществу тайный смысл топика?
А есть ли гарантия, что код для более эффективной среды исполнения будет сложнее, чем код для менее эффективной? А у топика нет тайного смысла, там всё явно: memento tempus — помни о времени, а многие забывают.
Кроме того, да ну вас с вашими абстрактными соображениями. Сходите уже на shootout.alioth.debian.org и посмотрите на объём кода возникающий при решении задач на разных языках. Более быстрые программы не всегда более сложные.
Кроме того, да ну вас с вашими абстрактными соображениями. Сходите уже на shootout.alioth.debian.org и посмотрите на объём кода возникающий при решении задач на разных языках. Более быстрые программы не всегда более сложные.
Клиентам хостинга гораздо проще перейти с тарифного плана «1500 рублей в год» на «4000 рублей в год», чем платить программисту десятки тысяч за переписывание скриптов.
Клиенты бывают разные, хостинги тоже. Вообще, я знаю много программистов, которые неплохо зарабатывают именно на переписывании скриптов, потому что клинеты уже перешли на самый 'производительный' тариф, а какой-то компонент системы тормозит.
Это вы для сферического хостинга в вакууме написали?
Конкурент перепишет скрипты и поднимет цену до 2000 рублей в год. И с лихвой вернет свои затраты, а с учетом перебежавших клиентов еще и прибыль получит.
Конкурент перепишет скрипты и поднимет цену до 2000 рублей в год. И с лихвой вернет свои затраты, а с учетом перебежавших клиентов еще и прибыль получит.
Думаю, тут можно посчитать так: один программист/администратор потратил месяц (160 рабочих часов грубо) на оптимизацию, сэкономил 50 мс на хит, а значит после 11 520 000 (160*60*60/0,05) хитов реальных пользователей в фореграунде свободного времени в мире станет больше, чем было бы без оптимизации :)
Вас почитать, так выходит, что весь софт в мире посвящён обслуживанию хитов. Кстати, а откуда такие данные, что усердная оптимизация может сэкономить лишь 50 мс? Кроме того, даже если 50 мс, это означает, что на один сервер можно посадить больше пользователей. Profit же, разве нет? Но понятно, конечно, что если у системы всего 20 пользователей, смысла в оптимизации нет.
Отвечал на
По-моему для подавляющего большинства сайтов актуальнее проблема где взять пользователей, а не как бы побольше их уместить на одном сервере, с целью экономии на серверах :)
Но какая разница, если сайт на похапе отвечает за 100 мс, а сайт на Си за 50мс? Пользователи этого сайта вовсе не сэкономят себе 50% времени, если вы его перепишете на Си.50 мс оттуда, 160 часов трудоемкости из головы :)
По-моему для подавляющего большинства сайтов актуальнее проблема где взять пользователей, а не как бы побольше их уместить на одном сервере, с целью экономии на серверах :)
В том-то и дело, что нельзя так считать. Любое действие пользователя имеет минимальный предел затрачиваемого времени. И плевать, хоть у вас сайт отвечает за 1мс, хоть за 100мс, если пользователь всегда тратит на открытие 250мс. В таком случае оптимизация не даёт вообще никакой пользы, хотя по мнению автора экономится аж в 100 раз больше времени!
А если считать не 100 и 50, а 300 и 250? В принципе те же 100 и 50, но не в локалке, а с пингом в 200мс :) А вообще я хотел проиллюстрировать, что ТС, как я понял топик, имел в видую
Ну что за чушь? Где я там написал в примерах о экономии времени пользователей сайтов? Я же совсем о другом. Для сайтов время экономится не у пользователя, а у обслуживающего серверы персонала. Но когда пользователей мало — это иррелевантно.
И считать так МОЖНО, потому что именно так Вы сейчас и посчитали: оценили, что ускорение обработки запроса не освободит дополнительное время у пользователя. Где я написал, что надо бороться за микросекунды при обработке HTTP-запросов? Читайте же внимательнее, там совсем другие примеры.
И считать так МОЖНО, потому что именно так Вы сейчас и посчитали: оценили, что ускорение обработки запроса не освободит дополнительное время у пользователя. Где я написал, что надо бороться за микросекунды при обработке HTTP-запросов? Читайте же внимательнее, там совсем другие примеры.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не инженеры и не серверы, а время