Советы по оптимизации производительности базы данных и POST-запросов

Question

Я занимаюсь разработкой приложения, которое предполагает интерактивность нескольких пользователей в режиме реального времени. В основном он включает в себя множество запросов AJAX POST / GET от каждого пользователя к серверу, что, в свою очередь, приводит к чтению и записи в базу данных. Результат в реальном времени, возвращаемый сервером, используется для обновления клиентской части.

Я знаю, что оптимизация - довольно сложная, специализированная область, но какой совет вы бы мне дали, чтобы получить максимальную скорость работы - скорость имеет первостепенное значение, но в настоящее время некоторые из этих запросов POST возвращаются через 20-30 секунд.

Один из способов, который я задумал оптимизировать, - это объединять POST-запросы и отправлять их на сервер в виде группы 8-10 вместо того, чтобы запускать отдельные запросы. В настоящее время я не использую кеширование на стороне базы данных, и на самом деле не знаю, что это такое, и будет ли это полезно в этом случае.

Кроме того, запросы AJAX POST и GET имеют одинаковые издержки с точки зрения скорости?

Answer 1

Вместо постоянного попадания в базу данных, кэшируйте часто используемые элементы данных (со сроком действия в зависимости от того, как редко данные изменяются).

Можете ли вы сократить объем связи с сервером, кэшируя часть данных клиента?

Целью GET является его название подразумевает - ПОЛУЧИТЬ информацию. это предназначен для использования, когда вы чтение информации для отображения на стр. Браузеры будут кешировать результат из запроса GET и если тот же GET запрос сделан снова, тогда они будут отображать кешированный результат, а не перезапуск всего запроса. Это не недостаток в обработке браузера но намеренно предназначен для работы таким образом, чтобы сделать вызовы GET более эффективен, когда звонки используются для их предназначение. GET вызов извлечение данных для отображения на странице и данные не должны быть изменены на сервере при таком звонке и тд повторный запрос тех же данных должен быть ожидается получение того же результата.

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

1012 * Ref *.

Answer 2

Вы пробовали профилировать ваше приложение?

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

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

То, что я бы порекомендовал вам сделать, это время на каждом шагу. Скорее всего, вы обнаружите, что либо

1. у вас есть один или два действительно длинных работающих бита или
2. вы выполняете множество запросов из-за ошибки n + 1 или тому подобного

Когда вы обнаружите, что идет не так, исправьте это. Если вы не знаете как, напишите снова. ; -)

Answer 3

Обычные настройки: - использовать больше индексации - используйте меньше индексации - использовать более или менее кэширование в файловой системе, базе данных, приложении или содержимом - обеспечить большую пропускную способность или большую мощность процессора или больше памяти на любом из ваших компонентов - минимизировать накладные расходы при любом виде связи

Конечно, альтернативой будет: 0 разработать набор тестов, предпочтительно автоматический, который может определить, правильно ли работает ваше приложение.
1 измерьте «скорость» вашего приложения.
2 определить, как быстро он должен стать
3 определить источник проблем с исполнением:
Типичные проблемы: пропускная способность сети, файловый ввод / вывод, задержка, проблемы с блокировкой, нехватка памяти, процессор 4 исправить проблему
5 убедитесь, что это на самом деле быстрее
6 убедитесь, что он все еще работает правильно (следовательно, тесты выше)
7 возврат к 1

Answer 4

Используемые вами приемы оптимизации - это те же приемы, что и для обычного веб-сайта, только с более быстрым поворотом во времени. Вот некоторые вещи, которые вы можете посмотреть:

• Предварительная выборка GET-запросов с высокой вероятностью загрузки пользователем
• Используйте промежуточный слой, как предполагает Митч Уит. В зависимости от вашей технологической платформы, вы можете посмотреть на memcache, это довольно часто, и есть библиотеки почти для всего
• Посмотрите на денормализуемые данные, которые будут запрашиваться с очень высокой частотой. Предполагая, что чтение является более распространенным, чем запись, вы должны получить приличное повышение производительности, если переместите рабочую нагрузку на часть записи доступа к данным (в отличие от добавления загрузки базы данных с помощью объединений)
• Используйте отложенные вставки, чтобы дать приоритет записи и позволить серверу базы данных оптимизировать пакетирование
• Убедитесь, что у вас есть интеллектуальные индексы в таблице, и выясните, какую выгоду они предоставляют. Если вы очень часто перестраиваете индексы из-за высокого отношения записи: чтения, вы можете захотеть уменьшить количество запросов
• Посмотрите на получение данных в более общих запросах и фильтрацию данных, когда они поступают на бизнес-уровень приложения. MySQL (например) использует очень специфический кеш запросов, который совпадает с конкретным запросом. Возможно, имеет смысл получить все результаты для данного набора, даже если вы собираетесь отображать только x%.
• Для записи, посмотрите на выполнение асинхронных запросов к базе данных, если это возможно в вашей системе. Синхронизация данных не не должна быть мгновенной, она просто должна выглядеть так (большую часть времени)
• Кэширование общих страниц на диске / в памяти в полностью отформатированном состоянии, чтобы сервер не выполнял большую их обработку

В общем, есть лотов вещей, которые вы можете сделать (и они обычно сводятся к общим методам разработки в более мелком масштабе).