:-) Не могу претендовать на "истину в последней инстанции", но на личном примере "выглядит" так... Цена одной и той же поездки по одному и тому же тарифу с Macbook и Android при попытке заказа в одно и то же время. Разница более 20%....
:-) Почему-то вспомнился анекдот : Пришли мыши к Сове:
«Сова ты старая и мудрая. Скажи, что нам сделать, чтобы коты перетали нас ловить и есть?» Сова говорит им: «Мышки, станьте ежиками. Если вы будете колючими, вас никто не съест!» Обалдевшие от восторга мыши побежали домой, там опомнились и снова вернулись к сове. «Сова, расскажи — а как нам стать ежиками?» А Сова им в ответ: «Я решаю важные стратегические вопросы! С тактикой разбирайтесь сами!»
:-) Узкие места производительности для БД - это не только ваше "открытие", но... Это на памяти определенной частоты и дисках с определенным IOPS (где они "узкое место повышения производительности")... Технологии "не стоят на месте" (появляется "более быстрая память и диски") и если ресурсов CPU "с избытком", ничего вам не мешает "уменьшить количество доступных ядер" или "отключить HT" для БД (что снизит inter-core latency и/или исключит межсокетное), и "картина эффективности" уже "выглядит" по другому.... Если конечно же не будет "простаивать в холостую" исключенные из БД ядра... Которые обычно можно загрузить и "не БД" нагрузкой (которой в серверах так же хватает)...
:-) Вы еще сравните предлагаемую Яндексом цену одной и той же поездки на такси, по "одинаковому" тарифу, получаемую в один момент времени на разных "устройствах".... :-) Вот где разница может быть и на 25%....
:-) Не соглашусь, т.к. "кому интересно идти в IT не за деньгами, а по внутреннему призванию/желанию" (естественно если есть способность к этому виду труда) - в ближайшей перспективе быстро "обойдут" тех "кто пришел в IT за деньгами".
:-) Железо - на ваш выбор (как вариант энергоэффективного и производительного Intel N100) + + Xpenology. И обойдется это (в зависимости от желаемого "набора" железа) от 20 до 30 тыс. без дисков.
:-) Логика простая... Требования к разработчику - "сделай в программном продукте вот этот функционал и побыстрее". Разработчик же заинтересован в постоянной "разработке программного продукта" - именно этим он "зарабатывает". По этой причине (кроме отдельных перфекционистов "по природе") софт "исходящий" от разработчков сырой, не оптимизирован и полон багов. "Бац-бац и готово!" Требования к тестировщику - "клиент не должен сообщать об ошибках в программном продукте и его функциях".
:-) Вот тесты на реальных приложениях и показывают "что заявлено" и "как по факту".... А выбор (неважно чего) - это всегда "компромис"... Быстро, качественно, недорого - выбирайте любые два пункта.
Если ты превосходно разбираешься в соей узкой области и не хочешь/можешь даже в общем приближении понимать "как все под капотом работает" - это не ужасно, но недостаток. И получаем ответы от всех "узких специалистов" - "С моей стороны пули вылетели, проблемы на вашей стороне..."
К слову "другие люди" и среди нового поколения есть... :-) Не много, но есть. Любознательность, альтруизм и реальное трудолюбие (получение удовольствия от результатов своего труда) еще не изжиты современным обществом и государством...
По сути написано верно, но... Касаемо фразы "ЭТОГО НЕТ В МОЕЙ ДОЛЖНОСТНОЙ ИНСТРУКЦИИ!". Если на все ваши другие аргументы 1,2,3 (они перечислены в статье) вы получаете ответы в стиле "Я начальник - ты дурак. Клиент за это платит." - значит пора уходить. Правда в ситуации если вы реально специалист, а не просто "думаете что вы специалист"...
:-) Ну да. "Школьники пишут программы" сейчас, вот только "когда все идет не так" - зовут "других людей". Так что реальным IT специалистам работы хватает.... :-)
DB2 - "жестко" связывает с одним вендором, и инфраструктурой. А компании разработчику софта "хочется" широкого рынка сбыта под требования разных клиентов. Вот по этой причине - Oracle (до определенного этапа), а сейчас еще и PG. Ситуация с тестами простая. Есть клиенты нашего прикладного ПО (или потенциальные клиенты). Есть поставщики/вендоры оборудования (или комплекса услуг типа IBM/Oracle). Все вендоры заинтересованы в "больших и надежных" клиентах. Клиентам всегда нужно производительность-надежность-масштабируемость-безопасность и по "минимальной цене поддержки/эксплуатации". На это еще "сверху ложатся" скажем так "интересы конкретных людей в компаниях у клиентов". :-) Вот и получается ситуация когда клиент "говорит" вендору - "Хотите чтоб наша компания стала вашим клиентом? Ну продемонстрируйте на прикладных тестах что вы можете. Синтетика и теория - это одно, а реальные показатели - может быть другое." Периодически и сама наша компания "ища рынки сбыта" самостоятельно пробует работу нашего прикладного софта под разными платформами, вендорами, OS (предваряя запросы наших клиентов). С разными вычислительными мощностями в различных конфигурациях и т.п. Иногда приходится "проверять громкие заявления вендоров о прорыве в технологиях" и т.п. Все вроде бы просто. "Есть требования бизнеса клиента"(это enterprise) - "Есть прикладное решение"(или несколько) - "Есть ресурсы/решения конкретного вендора"(или разных). До приобретения комплекса бизнес клиента хочет - "А покажите на деле что можете! А что будет если "уронить"? А время восстановления и % потерь? А если у нас завтра бизнес вдвое вырастет? А где логи всех действий в системе (изменений в прикладной базе)? А соответствие PCI/DSS? А интеграция с .....?" Вот на такие вопросы дают ответы тесты (конкретные цели ставит заказчик конечно же)... :-) Зачастую познавательно слушать "перепалку" спецов вендора по платформе/OS с их же спецами по работе Oracle DB (на платформе/OS) кто из них "накосячил" с конфигурацией системы/комплекса.
:-) Ну российские спецы IBM по DB2 сразу сказали что пробовать и не будут... Тупо исходники в европейское отделение отправили. А уж кто там занимался - не интересовался. IBM тогда (на фоне спада интереса к DB2) активно продвигал софт типа "автоматической адаптации написанного на PL/SQL под DB2", со словами "наш софт портирует 90% исходников - вам руками останется поправить 10%".... А вот насчет тестов - вы не очень правы. Я там конечно с "прикладной стороны смотрел", но вендорам всем "вводные давали одинаковые". Не думаю что в Монпелье спецы по системам совсем слабые (что по z что по p-System) и те и другие тюнили системы после начала тестов не слабо. Но... Они же и объясняли сами "почему такой результат". Сам я в Монпелье с ними и общался за пару командировок недели по 3 каждую. На результаты прикладной производительности нашего софта они "смотрели с уважением" когда я им объяснял что делает система, т.к. их же системы работали с другим (но аналогичным) прикладным софтом по всему миру и знали сколько ресурсов "жрет" подобный софт при примерно такой же прикладной производительности.
:-) Не могу претендовать на "истину в последней инстанции", но на личном примере "выглядит" так...
Цена одной и той же поездки по одному и тому же тарифу с Macbook и Android при попытке заказа в одно и то же время. Разница более 20%....
:-) Почему-то вспомнился анекдот : Пришли мыши к Сове:
«Сова ты старая и мудрая. Скажи, что нам сделать, чтобы коты перетали нас ловить и есть?» Сова говорит им: «Мышки, станьте ежиками. Если вы будете колючими, вас никто не съест!» Обалдевшие от восторга мыши побежали домой, там опомнились и снова вернулись к сове. «Сова, расскажи — а как нам стать ежиками?» А Сова им в ответ: «Я решаю важные стратегические вопросы! С тактикой разбирайтесь сами!»
:-) Узкие места производительности для БД - это не только ваше "открытие", но...
Это на памяти определенной частоты и дисках с определенным IOPS (где они "узкое место повышения производительности")...
Технологии "не стоят на месте" (появляется "более быстрая память и диски") и если ресурсов CPU "с избытком", ничего вам не мешает "уменьшить количество доступных ядер" или "отключить HT" для БД (что снизит inter-core latency и/или исключит межсокетное), и "картина эффективности" уже "выглядит" по другому....
Если конечно же не будет "простаивать в холостую" исключенные из БД ядра... Которые обычно можно загрузить и "не БД" нагрузкой (которой в серверах так же хватает)...
:-) Вы еще сравните предлагаемую Яндексом цену одной и той же поездки на такси, по "одинаковому" тарифу, получаемую в один момент времени на разных "устройствах"....
:-) Вот где разница может быть и на 25%....
:-) Ну как бы искусственный интеллект нужен тому у кого проблемы с естественным... :-)
:-) Искусственный интеллект больше всего нужен тем у кого нет естественного....
:-) История учит, если государство говорит "Колхоз дело добровольное!", значит скоро начнут "раскулачивать" и "ссылать за Урал"....
:-) Не соглашусь, т.к. "кому интересно идти в IT не за деньгами, а по внутреннему призванию/желанию" (естественно если есть способность к этому виду труда) - в ближайшей перспективе быстро "обойдут" тех "кто пришел в IT за деньгами".
:-) В IT я 30+ лет. С автором статьи во многом согласен...
:-) Железо - на ваш выбор (как вариант энергоэффективного и производительного Intel N100) + + Xpenology. И обойдется это (в зависимости от желаемого "набора" железа) от 20 до 30 тыс. без дисков.
:-) Логика простая...
Требования к разработчику - "сделай в программном продукте вот этот функционал и побыстрее". Разработчик же заинтересован в постоянной "разработке программного продукта" - именно этим он "зарабатывает". По этой причине (кроме отдельных перфекционистов "по природе") софт "исходящий" от разработчков сырой, не оптимизирован и полон багов. "Бац-бац и готово!"
Требования к тестировщику - "клиент не должен сообщать об ошибках в программном продукте и его функциях".
:-) Ну как бы - https://github.com/cybernoid/archivemount "стирает проблему" -Fd ...
:-) Вот тесты на реальных приложениях и показывают "что заявлено" и "как по факту".... А выбор (неважно чего) - это всегда "компромис"...
Быстро, качественно, недорого - выбирайте любые два пункта.
Если ты превосходно разбираешься в соей узкой области и не хочешь/можешь даже в общем приближении понимать "как все под капотом работает" - это не ужасно, но недостаток. И получаем ответы от всех "узких специалистов" - "С моей стороны пули вылетели, проблемы на вашей стороне..."
К слову "другие люди" и среди нового поколения есть... :-) Не много, но есть. Любознательность, альтруизм и реальное трудолюбие (получение удовольствия от результатов своего труда) еще не изжиты современным обществом и государством...
По сути написано верно, но...
Касаемо фразы "ЭТОГО НЕТ В МОЕЙ ДОЛЖНОСТНОЙ ИНСТРУКЦИИ!". Если на все ваши другие аргументы 1,2,3 (они перечислены в статье) вы получаете ответы в стиле "Я начальник - ты дурак. Клиент за это платит." - значит пора уходить. Правда в ситуации если вы реально специалист, а не просто "думаете что вы специалист"...
:-) Ну да. "Школьники пишут программы" сейчас, вот только "когда все идет не так" - зовут "других людей". Так что реальным IT специалистам работы хватает.... :-)
DB2 - "жестко" связывает с одним вендором, и инфраструктурой. А компании разработчику софта "хочется" широкого рынка сбыта под требования разных клиентов. Вот по этой причине - Oracle (до определенного этапа), а сейчас еще и PG.
Ситуация с тестами простая. Есть клиенты нашего прикладного ПО (или потенциальные клиенты). Есть поставщики/вендоры оборудования (или комплекса услуг типа IBM/Oracle). Все вендоры заинтересованы в "больших и надежных" клиентах. Клиентам всегда нужно производительность-надежность-масштабируемость-безопасность и по "минимальной цене поддержки/эксплуатации". На это еще "сверху ложатся" скажем так "интересы конкретных людей в компаниях у клиентов". :-)
Вот и получается ситуация когда клиент "говорит" вендору - "Хотите чтоб наша компания стала вашим клиентом? Ну продемонстрируйте на прикладных тестах что вы можете. Синтетика и теория - это одно, а реальные показатели - может быть другое."
Периодически и сама наша компания "ища рынки сбыта" самостоятельно пробует работу нашего прикладного софта под разными платформами, вендорами, OS (предваряя запросы наших клиентов). С разными вычислительными мощностями в различных конфигурациях и т.п.
Иногда приходится "проверять громкие заявления вендоров о прорыве в технологиях" и т.п.
Все вроде бы просто. "Есть требования бизнеса клиента"(это enterprise) - "Есть прикладное решение"(или несколько) - "Есть ресурсы/решения конкретного вендора"(или разных).
До приобретения комплекса бизнес клиента хочет - "А покажите на деле что можете! А что будет если "уронить"? А время восстановления и % потерь? А если у нас завтра бизнес вдвое вырастет? А где логи всех действий в системе (изменений в прикладной базе)? А соответствие PCI/DSS? А интеграция с .....?" Вот на такие вопросы дают ответы тесты (конкретные цели ставит заказчик конечно же)... :-)
Зачастую познавательно слушать "перепалку" спецов вендора по платформе/OS с их же спецами по работе Oracle DB (на платформе/OS) кто из них "накосячил" с конфигурацией системы/комплекса.
Интересно что несколько клиентов у нас на p-System еще "сидят", но поддержку 12 Oracle в этом году мы "заканчиваем"....
:-) Ну российские спецы IBM по DB2 сразу сказали что пробовать и не будут... Тупо исходники в европейское отделение отправили. А уж кто там занимался - не интересовался. IBM тогда (на фоне спада интереса к DB2) активно продвигал софт типа "автоматической адаптации написанного на PL/SQL под DB2", со словами "наш софт портирует 90% исходников - вам руками останется поправить 10%"....
А вот насчет тестов - вы не очень правы. Я там конечно с "прикладной стороны смотрел", но вендорам всем "вводные давали одинаковые". Не думаю что в Монпелье спецы по системам совсем слабые (что по z что по p-System) и те и другие тюнили системы после начала тестов не слабо. Но... Они же и объясняли сами "почему такой результат". Сам я в Монпелье с ними и общался за пару командировок недели по 3 каждую. На результаты прикладной производительности нашего софта они "смотрели с уважением" когда я им объяснял что делает система, т.к. их же системы работали с другим (но аналогичным) прикладным софтом по всему миру и знали сколько ресурсов "жрет" подобный софт при примерно такой же прикладной производительности.