Часто встречается требование опыта программирования высоконагруженных систем

Чем от простого программиста отличается программист высоконагруженных систем?

Какие он знает секретные алгоритмы и функции?

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

Это сообщение отредактировал(а) Zloxa - 9.11.2013, 14:11

Очевидно что всем известные методы значительно хуже работают при высокой нагрузке чем при низкой нагрузке. 
Как их заставить лучше работать чисто програмистскими методами (без наращивания железа)?

тот же программист..только очень нагруженный, отличие от других?!== никогда не улыбается

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

Это сообщение отредактировал(а) Zloxa - 11.11.2013, 13:32

Это почему "без наращивания железа"?

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

Это сообщение отредактировал(а) procoder76 - 11.11.2013, 14:37

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

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

Это сообщение отредактировал(а) Zloxa - 11.11.2013, 15:25

Опять ты!

Программист может все!... если захочет, конечно....... 

Добавлено через 1 минуту и 51 секунду
P.S. кластер

Берём, например, сортировку. При низкой нагрузке все алоритмы одинаково хороши, при высокой все хуже, но есть дно но. Есть квадратичные алгоритмы, например, пузырьковый, а есть с более пологий функцией. При росте нагрузки в 1 000 раз пузырьковый ведёт себя в 1 000 000 раз хуже, а если зависимость, например, nlnn, то такой алгорим ведёт себя хуже всего в 6 907 раз. Если при низкой нагрузке он был хуже пузырька, то программист без опыта разработки высоконагруженных систем выберет пузырька, но вряд ли он лучше конкурента в 144 раза, так что при высокой нагрузке он будет хуже. Или поиск. Полный перебор имеет линейную зависимость времени, бинарный поиск логарифмическую, причём, по основанию два. При росте нагрузки в 1 024 раза перебор начинает вести себя в 1 024 раз хуже, бинарный поиск  только в десять раз, но требует, чтоб массив всегда был отсортирован. Программист без опыта разработки высоконагруженных систем выберет перебор только из-за того, что не уверен в своих силах в плане поддержки постоянной отсортированности не константного массива, при росте нагрузки в миллион раз его проигрыш будет критичен, при сложном сравнении, высоких требованиях к реактивности, или слабом сервере это возможно и при меньших нагрузках. Или в ресурсах, оставшихся от других задач, в высоконагруженной системе их может оказаться меньше из-за того, что хуже себя повело сразу несколько алгоритмов. Программист с опытом разработки высоконагруженных систем 
учтёт это, неопытный коллега может вообще забыть.

Добавлено через 7 минут и 7 секунд
И кто же должен об этом сказать? Специалист по сборке компьютеров? Он вообще врядли способен оценить требования. Заказчик должен сообразить сам? Только по опыту эксплуатации, а он тоже может его не иметь. Программист же лучше всех знает, чем и в каком количестве его код питается и может аргументировать покупку более мощного компьютера. И если нет единой команды, проектирующей систему целиком, а есть только поставщик готовых конфигов и программисты, то программисты остаются единственными, кто способен выбрать железо.

 Как называется металический штифт?
Сорри что не по теме

Переходник, преобразователь!   

Такого адского некропостинга не по теме я давненько не встречал!
Сорри что не по теме