mysql — вызывает тяжелую функцию PHP через цикл AJAX или на стороне сервера.
Какой из них лучше всего выбрать на стороне сервера или на стороне клиента?
У меня есть функция PHP что-то вроде:
function insert(argument)
{
//do some heavy MySQL work such as sp_call
// that takes near about 1.5 seconds
}
Я должен вызывать эту функцию около 500 раз.
for(i=1;i<=500;i++)
{
insert(argument);
}
У меня есть два варианта:
a) call through loop in PHP(server-side)-->server may timed out
b) call through loop in JavaScript(AJAX)-->takes a long time.
Пожалуйста, предложите лучший, если есть третий.
Решение
Если я правильно понимаю, что ваш сервер все еще должен выполнять всю работу, поэтому вы не можете использовать клиентский компьютер для уменьшения мощности, необходимой вашему серверу, поэтому вы можете выбрать следующее:
-
Пусть клиент спросит сервер 500 раз. Это легко позволит вам показать процесс для клиента, давая ему удовлетворительное знание о том, что что-то происходит, или
-
Пусть сервер сделает все, чтобы пропустить 500 дополнительных циклов, а также дополнительные издержки, необходимые для обработки 500 запросов.
Я бы, вероятно, пошел с 1, если не важно, чтобы клиент не сдавался рано, или с 2, если важно, чтобы работа была выполнена полностью, хотя клиент может остановить запросы после 300.
РЕДАКТИРОВАТЬ: Что касается вашего комментария, я бы тогда предложил кнопку «начать работу» на клиенте, который говорит серверу, чтобы начать работу. Затем ваш сервер сообщает фоновой службе (которую можно создать в php) для выполнения работы. И он может обновить свой процесс в файл или в базе данных или что-то. Тогда клиент и php-сервер свободны для тайм-аута и выхода из системы без проблем. И затем вы можете обновить страницу, чтобы увидеть, если работа завершена в фоновом режиме, который может быть собран из базы данных или файла или что-то еще. Тогда вы минимизируете как время, так и зависимости.
Другие решения
Вы не предоставили никакого контекста для того, что вы пытаетесь достичь — здесь ключевым моментом является производительность и то, следует ли рассматривать набор значений как одну транзакцию.
Чем дальше цикл от физической памяти (не только от СУБД), тем больше влияние на производительность. Для большинства веб-приложений наибольшим узким местом в производительности является задержка в сети между клиентом и веб-сервером — даже если вы находитесь относительно близко … скажем, в 50 миллисекундах … и если работа Keeaplive работает должным образом, это займет не менее 25 секунд. выполнить эту операцию для 500 элементов данных.
Для оптимальной производительности вы должны отправлять данные СУБД в наименьшем количестве операторов DML — вы упомянули MySQL, который поддерживает многорядные вставки и если вы используете MySQLi, вы также можете отправить несколько операторов DML в том же вызове базы данных (хотя последний просто устраняет разболтанность между PHP и СУБД, в то время как один DML, вставляющий несколько строк, также уменьшает разболтанность между СУБД и хранилищем). В зависимости от структуры данных и оптимизации, для вставки сотен строк требуется около 10 миллисекунд — оба метода будут намного, НАМНОГО быстрее, чем цикл, выполняемый на клиенте, даже если задержка была 0.
Время, в течение которого выполняемая транзакция будет определять вероятность сбоя транзакции — поэтому более быстрый метод будет в тысячи раз надежнее, чем метод Ajax.
Как предполагает Крике, использование клиента для выполнения некоторой работы не приведет к экономии ресурсов в вашей системе — существует дополнительная нагрузка на веб-сервер, экземпляры PHP и подключение к СУБД. Хотя они относительно небольшие, они быстро складываются. Если вы протестируете оба подхода, вы обнаружите, что наличие цикла в PHP или в базе данных приведет к значительно меньшим усилиям и, следовательно, к большей емкости вашего сервера.
Однажды у меня был сценарий, который работал десятки минут. Мои решения делали длинный запрос через AJAX с таймаутом в 1 секунду и проверяли результат в других потоках AJAX. Опыт для пользователя лучше, чем слишком долго ждать ответа от php без ajax.
$.ajax({
...
timeout: 1000
})Итак, наконец я получил это.
а) Используйте AJAX, если хотите быть уверенным, что он завершится. это также удобно для пользователя, поскольку он получает регулярные ответы между вызовами AJAX.
б) Используйте серверный сценарий, если вы почти уверены, что сервер не остановится, и хотите меньше нагрузки на клиента.
Теперь я использую сценарий на стороне сервера с окном ожидающего сообщения для пользователя, и пользователь ожидает успешной отправки сообщения, иначе ему придется повторить попытку.
вероятность того, что это удастся с первой попытки, составляет 90-95%.
detector