Проблема скорее теоретического характера...
Я скачиваю через прокси файлы (их очень много).
Самих прокси тоже много, все они публичные - и, как следствие этого, работают не всегда.
То есть при скачивании файла довольно-таки часто ответ не приходит через время, указанное в таймауте.
Для хранения прокси использую табличку с такими полями:
proxy_id => просто номер прокси;
proxy => собственно ip:port;
failed_times => сколько раз подряд прокси не дает скачать файл (если только что скачал, то 0, если  последние n раз через эту прокси скачать не получилось - то n);
success => количество файлов, которые удалось скачать через эту прокси;
fail => количество файлов, которые не получилось скачать через эту прокси;
sum_time => общее время, за которое были выкачаны файлы, указанные в поле success.
При каждом шаге работы скрипта данные в этой таблице обновляются.

Вопрос такой... Как нужно выбирать следующую прокси для того, чтобы общее время на скачивание всех файлов было минимально?
Сейчас выбираю так:

но этот путь, имхо, не оптимальный.


Сам принцип работы сейчас такой...
1. Делатся вышеуказанный запрос в базу.
2. Идет подключение  к полученной прокси.
3. Скачивается/не скачивается файл.
4. В БД происходит UPDATE инфы о прокси согласно результатам п.3.
5. Снова п.1.

Это сообщение отредактировал(а) teroni - 5.10.2007, 14:19

пока сделал так.

Этот вопрос не имеет непосредственного отношения к php или SQL, поскольку вся задача лежит в построении оптимальной оценочной функции, которая бы помогла выбрать лучшую проксю на данный момент.

По выбраной тобой функции возникает вопрос: зачем нужен делитель (`success` + `fail` + 1)? Почему нельзя обойтись просто линейной функцией (`success`-2*`failed_times` - `fail`)?

Ну я согласен, что к php или SQL вопрос имеет слабое отношение... Скорей к математике...
Да выбирал просто пальцем в небо... Видимо, он действительно и не нужен..
Плюс сейчас у меня вообще в этой функции никак не участвует время sum_time, а мне кажется оно тоже должно в ней быть, т.к. некоторые прокси скачивают файл очень быстро, а некоторые почти за время до таймаута.

А в каких величинах выражается sum_time?

Можно попробовать несколько модифицировать функцию, например так

success - 2 * failed_times - fail - sum_time / (success + 1) / norm

где norm - нормирующая составляющая, что бы привести величину sum_time / (success+1) в соотвествие с остальными компонентами.

Можно поступить и еще проще - сделать сортировку по двум полям

Сразу не додумался, но похоже вот этот запрос самый лучший:

(20 - это значение таймаута).

не сочтите за некропост.
рискну предложить. может кому понадобится свой вариант
собственно таблица(я ее видоизменил):

запросы:

в моем варианте релевантность вычисляется в отдельное поле при  UPDATE-ах, чтобы разгрузить базу слегка

релевантность у меня пропорциональна скорости передаваемых данных(средней),отношению количества удачных попыток к неудачным, и отношению "как давно была неудача" к "как давно была удача"
смена прокси предполагается после N неудачных попыток(это контролируется на уровне приложения а не базы)
через час(3600 секунд) после ряда неудач, прокси снова может быть взят для новой попытки(ранее, если не из чего выбирать)
таким образом, если час за часом, при каждой новой попытке получить доступ к прокси, он не работает, его релевантность резко падает(в 24 раза, после суток простоя), но если заработает снова, то его релевентность будет востановлена снова до максимума
полагаю(еще не провериял), стоит обернуть 

в какую-нибудь функцию.потому что релевантность будет зашкаливать, если например 2 часа назад была неудача, а секунду назад была удача.надо над этим еще подумать

Это сообщение отредактировал(а) Alternator - 18.3.2009, 02:54