Создайте очередь задач ввиде простой таблицы в БД.
Напишите один скрипт который будет брать из таблицы адрес, скачивать, класть скаченное в папку и завершаться.
Напишите другой скрипт который скаченное будет разбирать, выделять ссылки и класть ссылки в таблицу для первого скрипта.
Запускайте каждый скрипт с помощью крона и небольшого bash скрипта N раз в минуту.
Это политика толерантности, чтобы никого не обидеть, поставить можно только плюс, минус нельзя. На том же stackowerflow можно минус поставить и вопросу и ответу. На пока Тостер не имеет достаточной аудитории, чтобы не отпугнуть имеющуюся текущая политика я думаю сохраниться.
Лично я не рекомендую использовать PhoneGap.
PhoneGap неплохо справиться с задачей мобильного приложения небольшого интернет магазина, когда достаточно выбрать категорию и карточку товара.
В остальных случаях вы очень скоро сталкиваетесь с ограниченными возможностями PhoneGap и его тормозами.
Сейчас имея скромный опыт разработки под iOS, я буду всем рекомендовать писать только нативные приложения.
Что то не понятна проблема...
1. Настройте веб сервер так чтобы по ip адресу не отдавал вообще никакой сайт (если речь об этом)
2. Пропишите в robots.txt директиву host чтобы указать ПС какой домент верный (если речь об алиасах)
Но аналогичный запрос UPDATE выполняется недопустимо долго (286.0228 сек.)
UPDATE `test` SET `lock` = 123456 WHERE `lock` = 0 ORDER BY `time` LIMIT 1000
Может быть потому что по lock есть индекс и это время получается из-за его перестроения?
Не ясно какую задачу вы решаете.
Срабатывают все сразу, потому что JS выполняет код асинхронно.
Можно модернизировать ваш код, чтобы он выполнился не параллельно, а друг за другом.
От классических сессий при работе через API отказался.
1. Для авторизации пользователь вводит логинпароль, устройство отправляет их по https на account/auth
2. account/auth выдает token (token_id:token_val) и secret
3. все дальнейшие запросы устройство отправляет по http указывая token и подписывая запросы с помощью secret
Как работает.
Сервер получает запрос, видит что пришел token, разбивает его через двоеточие на input_id и input_val. Выбирает из базы токен с пришедшим input_id, получает из базы значение token_val и secret. Сравнивает input_val и token_val. Если в базе нашелся токен с нужным id и значения val равны, пришло время проверить достоверность запроса.
Клиент помимо токена передал sign (подпись), которую сформировал так (например) secret+api_path+query_param. На стороне сервера вам известно api_path и api_param, а secret выбрали из базы. Хешировать подпись принято через hmac().
Помимо токена и подписи можно передавать time и так же класть его в sign, и на стороне сервера отсекать запросы запросы которым больше 60 сек.
Таким образом.
Если кто то слушает ваш канал, он не сможет подделывать запросы (а значит компроментировать), и из-за проверки времени жизни запроса не сможет вечно получать данные по однажды перехваченного запроса.
А в базе токены можете хранить пока клиент сам не запросит их уничтожения и сохранить время последного обращения через токен, и удалять токены которые не использовались более 60 дн.
Почему бы все данные не хранить в json массиве который сразу будет находится в теле страницы? Даже если у вас 100 квартир и по каждой есть информация о площади и стоимости, такой подход гораздо удобнее, чем каждый раз дергать сервер чтобы запросить пару строк. Ну и во всех своих события просто читайте массив.
Почему просто нельзя хранить в таблице ID текущего персонажа? То есть просто таблица соответствий account_id-current_character_id. По всему проекту использовать $current_character_id. И получается не важно с какого устройства ты зашел, всегда будет грузиться установленный текущим персонаж и только для него буду выполнятся все действия.
1. Использовать вместо PHP расширения Memcache, расширение Memcached. Оно позволяет вместо алгоритма "получить-изменить-сохранить", использовать алгоритм "добавить", что спасает при конкурентном доступе.
2. Перейти с Memcache на Redis, смысл тот же, функциональность шире. В случае Redis вашу задачу можно было бы решить с помощью Списков.
