@UserTrue said in Помогите оптимизировать код (запросы к БД):
Да тогда уж проще реализовать longpolling к источнику данный которые присылает данные в БД, то есть делается запроса без таймаута и висит пока сервер не ответит
А что будет, если данные так и не появятся?
@sergerdn said in Помогите оптимизировать код (запросы к БД):
@UserTrue said in Помогите оптимизировать код (запросы к БД):
Да тогда уж проще реализовать longpolling к источнику данный которые присылает данные в БД, то есть делается запроса без таймаута и висит пока сервер не ответит
А что будет, если данные так и не появятся?
Можно сделать очень большой таймаут, я как понял без этих данных его скрипт все равно не может работать
@UserTrue said in Помогите оптимизировать код (запросы к БД):
Можно сделать очень большой таймаут, я как понял без этих данных его скрипт все равно не может работать
У меня есть смутное ощущение, что так как топикастер сказал что он хочет сделать и даже в чем то как, но не написал зачем, то может быть ему нужно совсем не это.
@doupiu поделишься, что делаешь то?
@sergerdn said in Помогите оптимизировать код (запросы к БД):
@doupiu поделишься, что делаешь то?
В принципе, в исходном сообщении все описано подробно для решения задачи, на мой взгляд, но вот еще чуть подробностей)
Скрипт проверяет наличие товара в интернет-магазине в 50 потоков. Задержка между каждыми проверками внутри потока - 10 сек. При этом, если какой-то поток увидел, что товар есть в наличии, он записывает это в БД. С этого момента все потоки из режима "проверяем наличие" переходят в режим "покупаем товар". Именно для этого сделан цикл, который представлен в исходном сообщении. То есть каждый поток либо ждет 10 сек, чтобы сделать следующую проверку наличия, либо моментально покупает товар, так как наличие уже нашел другой поток.
P.S. Очевидное решение - вообще исключить отсюда БД и сделать глобалку наличия, которую постоянно проверять в цикле. Но там все несколько сложнее и БД все равно нужна.
@doupiu said in Помогите оптимизировать код (запросы к БД):
С этого момента все потоки из режима "проверяем наличие" переходят в режим "покупаем товар".
Не проще использовать ресурс или глобальную переменную
@UserTrue said in Помогите оптимизировать код (запросы к БД):
Не проще использовать ресурс или глобальную переменную
Как и написал, решение очевидное, но не подходящее, к сожалению. Товаров не 1, а сотня. У каждого товара есть еще десяток параметров, влияющих на дальнейшую работу скрипта. Поэтому все хранится в БД.
@doupiu said in Помогите оптимизировать код (запросы к БД):
@UserTrue said in Помогите оптимизировать код (запросы к БД):
Не проще использовать ресурс или глобальную переменную
Как и написал, решение очевидное, но не подходящее, к сожалению. Товаров не 1, а сотня. У каждого товара есть еще десяток параметров, влияющих на дальнейшую работу скрипта. Поэтому все хранится в БД.
Если все скрипты работают на одном сервере:
Вероятно, изначально был написан скрипт с поиском товара, потом с его покупкой. И это все отдельные сущности.
Потом между ними поставили БД для обмена информацией. Но возникли нюансы.
Я всегда перед тем, как писать скрипты, пишу документацию, что я делаю, зачем я это делаю и как я буду это делать.
В какой-то степени это помогает мне уложить в голову задачу и избежать части архитектурных ошибок.
Перед тем, как писать какой-то код, я уже знаю почти все о будущем скрипте.
Чтобы приобрести такой навык, нужен опыт. Иначе придется постоянно переделывать что-то, что бывает мучительно.
@doupiu said in Помогите оптимизировать код (запросы к БД):
@UserTrue said in Помогите оптимизировать код (запросы к БД):
Не проще использовать ресурс или глобальную переменную
Как и написал, решение очевидное, но не подходящее, к сожалению. Товаров не 1, а сотня. У каждого товара есть еще десяток параметров, влияющих на дальнейшую работу скрипта. Поэтому все хранится в БД.
Если товаров сотня, то использовать глобальную переменную возможно, а вот если объёмов товара больше, то только бд. Создайте массив с объектами со свойствами, как столбцы в базе данных. При добавлении данных в базу дублируйте данные в глобальную переменную.
Ограничивайте количество элементов в массиве, например держите не более 100 элементов. Также можете сохранить хеш объекта в отдельное место, например во вторую глобальную переменную. Это нужно, что бы потоки ждали изменения хеша при добавлении новых данных, а не выполняли проверку по кругу со старыми данными.
@sergerdn said in Помогите оптимизировать код (запросы к БД):
@Fox said in Помогите оптимизировать код (запросы к БД):
Если товаров сотня, то использовать глобальную переменную возможно,
Можно хранить в глобальной переменной только id товара в базе. Тогда будет существенная экономия памяти.
Если необходим поиск по каким то параметрам, то их лучше добавить в объекты
@Fox said in Помогите оптимизировать код (запросы к БД):
@sergerdn said in Помогите оптимизировать код (запросы к БД):
@Fox said in Помогите оптимизировать код (запросы к БД):
Если товаров сотня, то использовать глобальную переменную возможно,
Можно хранить в глобальной переменной только id товара в базе. Тогда будет существенная экономия памяти.
Если необходим поиск по каким то параметрам, то их лучше добавить в объекты
Я бы все равно добавлял только id товара, а в скрипте покупки уже дергал бы из базы и делал нужные проверки. Так как, вероятно, там уже это все есть.
Но это на усмотрение конкретного девелопера.
@Fox said in Помогите оптимизировать код (запросы к БД):
@doupiu said in Помогите оптимизировать код (запросы к БД):
@UserTrue said in Помогите оптимизировать код (запросы к БД):
Не проще использовать ресурс или глобальную переменную
Как и написал, решение очевидное, но не подходящее, к сожалению. Товаров не 1, а сотня. У каждого товара есть еще десяток параметров, влияющих на дальнейшую работу скрипта. Поэтому все хранится в БД.
Если товаров сотня, то использовать глобальную переменную возможно, а вот если объёмов товара больше, то только бд. Создайте массив с объектами со свойствами, как столбцы в базе данных. При добавлении данных в базу дублируйте данные в глобальную переменную.
Какая разница сколько их, можно все так же использовать ресурс в котором каждый товар это будет json строка и тп, вариантов масса. Это лучше чем 50 потоков долбят бедную БД. А еще обращение к встроенной БД синхронное!! тоесть все 50 потоков не могут одновременно к ней обратиться. Я думаю это было сделано для упрощения взаимодействия не особо продвинутых юзеров. Фактически при очень частых обращениях как у вас это приведет к сильному снижение скорости работы скрипта и подвисаниям интерфейса
@Fox @sergerdn @UserTrue спасибо за пищу для размышлений
Пока придумал такую архитектуру: при появлении товара в наличии вместе с изменением БД изменяем глобальную переменную IS_EXISTS_STOCK c false на true, что фактически сообщает нам, что "что-то в БД поменялось". Цикл соответственно постоянно проверяет только IS_EXISTS_STOCK, и только когда IS_EXISTS_STOCK=true - уже лезет в БД выяснять, что там изменилось.
Посмотрим :)
