предисловие
В последнее время внешний интерфейс время от времени сталкивался с проблемой тайм-аута 504. Причина в том, что время выполнения кода слишком велико, превышает настроенные nginx 15 секунд, а затем оптимизация производительности интерфейса проводилась с помощью реальных пушек. В сочетании с процессом оптимизации здесь собраны восемь пунктов оптимизации интерфейса, и я надеюсь, что это будет полезно для всех~
- Объем данных относительно велик, и данные хранятся в пакетах.
- Операции, занимающие много времени, учитывают асинхронную обработку
- Правильное использование кэширования
- Оптимизировать логику программы, код
- SQL-оптимизация
- Сжатый контент передачи
- Рассмотрите возможность использования других методов, таких как файл/MQ для временного хранения, а затем асинхронную посадку в БД.
- Обсудите с продуктом наиболее подходящий и удобный способ реализации требований
Хи-хи, давайте посмотрим на общий процесс нашего внешнего интерфейса передачи.
1. Объем данных относительно велик, и данные хранятся партиями.
До оптимизации:
//for循环单笔入库
for(TransDetail detail:list){
insert(detail);
}
Оптимизировано:
// 批量入库,mybatis demo实现
<insert id="insertBatch" parameterType="java.util.List">
insert into trans_detail( id,amount,payer,payee) values
<foreach collection="list" item="item" index="index" separator=",">(
#{item.id}, #{item.amount},
#{item.payer},#{item.payee}
)
</foreach>
</insert>
Сравнение производительности:
| Единица измерения (мс) | для циклического одиночного хранения | пакетное хранение |
|---|---|---|
| 500 | 1432 | 1153 |
| 1000 штук | 1876 | 1425 |
Разобрать
- Массовые вставки работают лучше и экономят время, почему?
打个比喻:假如你需要搬一万块砖到楼顶,你有一个电梯,电梯一次可以放适量的砖（最多放500）,
你可以选择一次运送一块砖,也可以一次运送500,你觉得哪种方式更方便，时间消耗更少?
2. Рассмотрите возможность асинхронной обработки для трудоемких операций
Для трудоемких операций рассмотрите возможность асинхронной обработки, которая может сократить время, затрачиваемое на интерфейс. На этот раз интерфейс передачи оптимизирован, и операция сопоставления номера связанной строки занимает немного времени, поэтому процесс оптимизации переводит ее в асинхронную обработку следующим образом:
До оптимизации:
Оптимизировано
Асинхронная обработка операций, соответствующих номерам строк
Сравнение производительности:
Предположим, что номер строки соответствует 6 мс
| Синхронизировать | асинхронный | |
|---|---|---|
| 500 | 3000ms | ~ |
| 1000 штук | 6000ms | ~ |
Разобрать:
- Поскольку сопоставление номеров строк требует много времени, если оно обрабатывается асинхронно, синхронный онлайн-возврат может сэкономить эту часть времени, значительно улучшить производительность интерфейса и не повлияет на функцию основного процесса передачи.
- В дополнение к этому примеру у нас обычно есть аналогичные функции, такие как SMS и уведомления по электронной почте после успешной регистрации пользователя, которые также могут обрабатываться асинхронно.Эта оптимизация рекомендуется.
- Поэтому для операций, которые занимают слишком много времени, вы можете рассмотреть возможность открытия подпотоков для асинхронной обработки, не влияя на функцию основного процесса.
3. Правильно используйте кеш
В соответствующих бизнес-сценариях правильное использование кэширования может значительно повысить производительность интерфейса. Кэши здесь включают: Redis, локальный кеш JVM, memcached или Map и т. д.
На этот раз интерфейс передачи использует кеш, давайте рассмотрим простой пример~
До оптимизации
Ниже приведена блок-схема ввода учетной записи пользователя и сопоставления номера строки.
Оптимизировано:
Надлежащее использование кеша, вместо запроса таблицы БД, блок-схема выглядит следующим образом:
Разобрать:
- Поместите горячие данные в кеш, вам не нужно обращаться к БД, чтобы извлекать их каждый раз, когда вы запрашиваете, что экономит время SQL-запроса в этой части, и это здорово~
- Конечно, не все данные подходят для кеширования, кешировать надо только самые горячие данные, к которым обращаются чаще~
4. Оптимизируйте логику и код программы
Оптимизация программной логики и программного кода может сэкономить время.
Вот на этот раз я оптимизирую интерфейс передачи, например~
До оптимизации:
Перед оптимизацией дважды запрашивался номер строки (один раз для проверки параметров и один раз перед вставкой БД), следующий псевдокод:
punlic void process(Req req){
//检验参数,包括联行号（前端传来的payeeBankNo可以为空,但是如果后端没匹配到，会抛异常）
checkTransParams(Req req);
//Save DB
saveTransDetail(req);
}
void checkTransParams（Req req）{
//check Amount,and so on.
checkAmount(req.getamount)；
//check payeebankNo
if（Utils.isEmpty(req.getPayeeBankNo())）{
String payeebankNo = getPayeebankNo(req.getPayeeAccountNo);
if(Utils.isEmpty(payeebankNo){
throws Exception();
}
}
}
int saveTransDetail(req){
String payeebankNo = getPayeebankNo(req.getPayeeAccountNo);
req.setPayeeBankNo(payeebankNo);
insert(req);
...
}
Оптимизировано:
После оптимизации он вставляется только один раз при проверке параметров, а затем устанавливается в объект ~ Нет необходимости проверять его перед сохранением, псевдокод выглядит следующим образом:
void checkTransParams（Req req）{
//check Amount,and so on.
checkAmount(req.getamount)；
//check payeebankNo
if（Utils.isEmpty(req.getPayeeBankNo())）{
String payeebankNo = getPayeebankNo(req.getPayeeAccountNo);
if(Utils.isEmpty(payeebankNo){
throws Exception();
}
}
//查询到有联行号，直接设置进去啦，这样等下入库不用再插入多一次
req.setPayeeBankNo(payeebankNo);
}
int saveTransDetail(req){
insert(req);
...
}
Разобрать:
- Для оптимизации программной логики и кода можно сократить время, затрачиваемое на интерфейс. Приведенная выше демонстрация является лишь очень простым примером, то есть payeeBankNo запрашивается дважды перед оптимизацией, но на самом деле достаточно только одного запроса. Много раз мы все знали об этом, но когда дело доходит до написания кода, мы забываем об этом~ Итак, при написании кода позаботьтесь об оптимизации логики и кода вашей программы.
- В дополнение к приведенной выше демонстрации есть и другие моменты, такие как оптимизация сложных логических условий, рассмотрение возможности корректировки порядка или циклов, многократное создание экземпляров объектов и т. д. Эти соответствующие оптимизации могут ускорить работу вашего кода.
В предыдущей статье я также упомянул несколько моментов оптимизации, кому интересно, можете посмотреть~
Пишите код с этими идеями, коллеги не подумают, что вы копипастный программист
5. Оптимизируйте свой SQL
Во многих случаях узким местом производительности вашего интерфейса является SQL, и мы должны сосредоточиться на медленных запросах.
Мы можем оптимизировать наш SQL следующими способами:
- показатель
- Избегайте возврата ненужных данных
- Оптимизировать структуру sql
- Подбиблиотека и подтаблица
- разделение чтения-записи
Заинтересованные друзья могут взглянуть на мою статью, очень подробные моменты оптимизации SQL:
Необходимые вещи для бэкенд-программиста: 30 советов по написанию высококачественного SQL
6. Сжать содержимое передачи
При сжатии передаваемого содержимого файл становится меньше, поэтому передача будет происходить быстрее. Пропускная способность 10M, передача пакетов 10k, как правило, быстрее, чем передача пакетов 1M. Чтобы использовать аналогию, тысячемильная лошадь может работать быстрее с нагрузкой 100 jin, или она может работать быстрее с нагрузкой 10 jin?
Разобрать:
- Если производительность вашего интерфейса не очень высока, а пакеты передачи относительно велики, вы можете подумать о сжатии содержимого файла для передачи в это время, и окончательный эффект оптимизации может быть очень хорошим~
7. Рассмотрите возможность использования других методов, таких как файл/MQ, для временного хранения данных и асинхронной посадки в БД.
Если данные слишком велики, а целевая база данных работает очень медленно, вы можете сначала сохранить ее в виде файла или использовать MQ, сначала посадив, а затем асинхронно сохранив ее в базе данных~
Если интерфейс передачи открыт одновременно, с 10 уровнями параллелизма и 1000 данных в каждом пакете, вставка в базу данных займет очень много времени, около 10 секунд.Это связано с механизмом синхронизации базы данных нашей компании.В случае параллелизма, т.к. Приоритет отдается обеспечению синхронизации, поэтому параллельная вставка становится последовательной, что занимает очень много времени.
До оптимизации:
Перед оптимизацией 1000 транзакций сначала помещались в базу данных БД, а затем переносились асинхронно следующим образом:
Оптимизировано:
Сначала сохраните данные в файл, затем асинхронно загрузите его и вставьте в базу данных следующим образом:
- Если ваше узкое место, отнимающее много времени, связано с операцией вставки в базу данных, рассмотрите возможность сохранения файла или MQ или другого временного хранилища.Файл сохраняет данные и сравнивает трудоемкость, иногда могут быть неожиданные эффекты.
8. Обсудите с продуктом наиболее подходящий и удобный способ реализации требований
Я лично считаю, что это по-прежнему очень важно, и некоторые потребности необходимо хорошо донести до продукта.
Например, есть запрос пользователя на отображение списка подключенных микрофонов.Продукт говорит отображать всю информацию о подключенных микрофонах.Если информация в списке подключенных микрофонов пользователя очень велика, вы возвращаете все данные о подключенных микрофонах, и производительность интерфейса снизится. Если продукт будет проанализирован путем нагромождения, будет обнаружено, что средний пользователь просматривает только первые несколько страниц при просмотре списка Lianmai ~ Поэтому ухмыляйтесь, ха-ха ~ На самом деле проблема загрузки больших страниц похожа. То есть лимит + очень большое число, что вообще очень медленно~~
Суммировать
Эта статья, основанная на трудоемкой оптимизации внешних интерфейсов, суммирует восемь пунктов по оптимизации производительности интерфейса. Надеюсь, она будет полезна для ежедневной разработки каждого~ Хи-хи, если вам интересно, вы можете посетить мой github, эта статья будет сохраниться на github Ridha
публика
- Добро пожаловать, чтобы обратить внимание на мой личный публичный аккаунт, подружиться и учиться вместе~