- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
So1, Хотя, применительно к cron, запускаемому каждую минуту такое почти невозможно.
Крон может хоть каждую секунду дергать файл, это не важно если стоит проверка
которая не даст скрипту выполнить задачу которая уже выполняется, крон будет просто дергать скрипт в холостую.
seosniks, зависит от того, какую именно проверку вы реализовали.
вы читайте другие сообщения, моделируйте в уме ситуации..
So1, а вот как раз такую наивность я и имел ввиду.
опытный разработчик знает, что между проверкой отсутствия файла и созданием этого файла может пройти какое-то время и два одновременно запущенных скрипта не заметят друг друга.
Блокировка эту проблему исключает. Хотя, применительно к cron, запускаемому каждую минуту такое почти невозможно.
Вы пробовали реализовать так, как я написал?
Если даже этот вариант не устраивает, берете под эту задачу компилите отдельный PHP, запускаете задачу по крону парсите выдачу ps auxw | grep <путь до php ропера>
Дальше понтяно. Это бОльшее извращение.
Да. Может пройти. Примерно 0.0002 миллисекунды в зависимости от HW. Проверка ключа мемкеша быстрее - используйте этот способ.
Опытный разработчик знает, а я так - вчера книжку про PHP прочитал ))
Да. Может пройти. Примерно 0.0002 миллисекунды в зависимости от HW. Проверка ключа мемкеша быстрее - используйте этот способ.
Если сервер засвопился - могут пройти минуты.
Если сервер засвопился - могут пройти минуты.
Я сматываю удочки. Вы много теоретизируете и не хотите реализовывать ни одним из предложенных способов. Проверка опытным путем лучше любой другой. Сделайте что-нибудь. Если вы ищите опытного ответа, то я вам его дал уже. Я не с горы взял все эти способы - каждый из них у меня реализован на разных больших проектах (и с использованием мемкеша и с использованием файлов). С ипользованием файлов мне удобно тем, что я могу посмотреть дату создания и понять когда начал выполняться процесс. Мемкеш - быстро и удобно. Никаких проблем не было за вот уже несколько лет ни с файлами, ни с мемкешем.
Удачи.
So1, 4 людям, которые умерли из-за этой ошибки, проблема показалась вполне реальной - http://ru.wikipedia.org/wiki/Race_condition
И конечно они писали подобные системы на PHP, который нельзя нормально распараллелить. Race condition в первую очередь связан с неправильным использованием общих ресурсов параллельно выполняющимися процессами, а вы их пока что отказываетесь использовать вовсе.
К стати, что у вас за задача? )
php прекрасно паралеллится - можно запустить два скрипта одновременно, что может привести к
race condition - общему названию всех ошибочных программистких допущений о том, что какие-то части важной программы выполняются "наверняка очень быстро" без специальной блокировки.