Денис Сапоненко
@VaiMR
Системный архитектор подрабатывающий лидом
Информация
- В рейтинге
- Не участвует
- Откуда
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Backend Developer, Software Architect
Senior
Java
Безопасники нарасхват нынче. Книга по хакингу устройств позволит вспомнить специальность по диплому.
И денег за помочь семья не попросит
Спасибо
Возможность показать свою статью сразу 20к пользователям за утро раньше очень мотивировала. При публикации всегда был лёгкий мандраж
Да, есть такое :)
Спасибо за развернутый коментарий!
Есть и такое, тут тренироваться можно на коллегах, наполняя базу знаний. Правда, иногда такое понапишут...
Поддерживаю!
@tinkoff_bank, думаю, может дать комментарий без проблем
— Да, айтишник
— Да, на есть Хабре.
— Да, пишу посты
— Нет, инвайт не дам
Работает этот подход, правда, только когда сборка корректна. А то бывает такое, что некоторые разработчики начинают использовать транковые версии модулей в ветках сопровождения, но с этим мы боремся и сделали защиту выпусков в плагине.
Обычно так делают в самом начале проекта. Идеальный ORM — универсальный ORM. Когда же начинаются реально высокие нагрузки, то алгоритмы специализируются на данных. Вплоть до того, что вот из этой таблицы мы всегда извлекаем быстро N-записей, это и будет верный результат. Извлекать вот так-то очень быстро. Естественно без джоинов. Нормальные формы часто тоже становятся препятствием, но не во всей же БД делаются такие «заточки», а только в самых узких местах.
Тюнинг БД из той же оперы.
Одиночные операции вместо пакетных
Конвейер наше все. Как начал Форд их использовать, так мы и продолжаем. Те же видеокарты, имеют кучу конвейеров. Промышленные ЭВМ содержат специфические конвейеры для разных операций. Например, лучше быстро складывать числа, чем иметь универсальный модуль, но жутко медленный.
Еще пример. По сети приходят пакеты. Мы их как-то обрабатываем и пишем в БД. 100 пакетов в минуту. Наша ИС обрабатывает 10 пакетов в минуту, но зато быстро пишет в БД. Обрабатываем первый пакет, потом сразу берем пачку, обрабатываем и быстро пишем в БД. Частый прием оптимизации.
Никаких кэшей
Кеш надо использовать правильно, тогда не будет проблем с актуальностью данных. Если придерживаться совета из статьи, то ни о каких распределенных системах и речи быть не может, это же какие накладные расходы на синхронизацию.
Используйте единственный примитив синхронизации
Какой? Все зависит от задачи. Мой сосед по общежитию как то сказал профессору на экзамене по ассемблеру: «Мой код на ассемблере никогда не будет так эффективен, как ассемблерный код, выданный компирятором». Свои велосипеды надо писать когда другие средства уже не помогают, а это, поверьте мне, бывает очень редко.
Применяйте как можно более простые алгоритмы
Конечно, все используют эффективные алгоритмы. Других просто нет. Все зависит от задачи и проблемы. Где простые алгоритмы дают приемлемую производительность, то сложные (реально сложные) алгоритмы могут дать колоссальную производительность. Обратное тоже верно.
Используйте умолчательные настройки
На старте да, это возможно, но как только начинается продуктивная эксплуатация, то ни о каких стандартных настройках и речи быть не может. Самый простой пример: у меня, как у разработчика, вся ИС размещается в 2-ух гигабайтах оперативной памяти. Вполне приемлемый объем. На сервере же, эта система запросто может занимать от 16-и гигабайт и выше. Хочешь выделить памяти виртуальной машине — задай нужный флаг. А это уже настройка.
Локальное взаимодействие ничем не отличается от удаленного
Да, классный вариант для архитектуры. Есть клиент, есть сервер. Никакой разницы, на одной машине выполняется код или на разных. Но это до поры до времени. 99% ИС это устроит. Но вот если вам надо обмениваться реально большими объемами данных, то тут и shared-memory и собственные блоки памяти, управляемые из аддона к ядру ОС и пр. шалости.
2. Получится лапша, достойная книги рекордов Гиннеса.