Второй раз рбращался к IQPartner. Все на высшем уровне. Четкие условия, ясные ответы, скриншоты.
Спасибо!
Обращался IQPartner для вывода PayPal с партнерки на WebMoney.
Все прошло отлично. Человек толковый, порядочный. Рекомендую!
kuprum, ну вы же никаких конкретных партнерок не посоветовали в прошлый раз...
Да, список нелогичный, и в основном датинг... Это потому что добавил то, что у меня было. Ведь чтобы настроить парсинг, недостаточно просто завести аккаунт, надо еще хотя бы минимальные цифры по доходам.
Anonim Team, там есть разделение по категориям. Но пока что некоторые категории содержат только по одной партнерке :)
Вполне разумный вопрос. Поскольку расширения сейчас пишут даже школьники, тычут в них тонны рекламы, доверие к расширениям низкое.
Мое расширение никуда логины и пароли не шлет. Даже статистику не собирает. А для доступа к партнерским сайтам использует https (если возможно). Как гарантия всего вышесказанного - код расширения доступен на GitHub, код максимально понятен и прокомментирован.
В будущем планирую сделать шифрование хранящихся данных и доступ к расширению по мастер-паролю (опционально).
Я бы и сам 7 раз подумал прежде чем вписать пароль в чужое расшиерние.
Что ж, значит буду работать над трастом, сделаю шифрование сохраненных данных, мастер-пароль и хорошо прокомментирую исходный код. Глядишь, со временем само обрастет хорошими отзывами )
kuprum, вы используете lastPass? Вы в равной степени не доверяете браузерным расширениям и сторонним авторским скриптам на PHP и node.js?
Прошу прощения, я вас и себя только запутал этим RAND().
Мне не нужны рандомные ID. Все они получены в предыдущем запросе по другой таблицу, обработаны PHP и оставлены 20 самых "подходящих" для этого запроса о котором я спрашивал. А RAND() тут ввел исключительно чтобы можно было тестировать запрос (ведь если я забью 111, 222, 333 запрос закешируется - я имею ввиду подтянутся в память блоки с ключами). В коде у меня "SELECT * FROM tab WHERE id IN (111, 32, 545 ...)" формируется.
Запрос в "естественной среде" работает нормально - 20 записей 0,02 сек.
По ходу проблема была в инструменте.
Тестировал скорость запросом, который, как мне казалось, тождественен запросу из скрипта. Этот занимает 3,5 сек.
SELECT *FROM `compkey3_phase3` WHERE `id` IN ( ROUND( RAND( ) *2596943 ) , ... 20 раз ... , ROUND( RAND( ) *2596943 ))
Но теперь вижу что если написать вручную набор случайных ID, то запрос выполняется быстро (0,015 сек)
SELECT *FROM `compkey3_phase3` WHERE `id` IN ( 344, 5454545, 5455, 8798, 453, 65467, 65767, 867878, 45345, 7567, 878, 5624, 12333, 234222, 4545, 656, 6456, 4543587, 87687, 4324, 543545, 76767, 8787, 9898, 67860, 78678, 469, 757564, 67767 )
Не забыл. Связанный из 2 столбцов.
Но ведь даже "список" с 1 id выполняется медленно - 0,2 сек.
Ещё раз - вы ищите по большому, неупорядоченному списку. Естественно, это тормозит. Достаточно здравое решение - предварительно записать этот список в таблицу с индексами и сделать выборку через INNER JOIN.
Тормозит даже на небольшом списке. 50 записей по их id берутся за секунду.
Сделал я эту таблицу со временной связкой... И ничего. Ровно то же самое время.
Проверить - легко, поменяйте условие в запросе
Проверил. Время выборки такое же как и раньше.
Огромное спасибо за помощь всем!
dlyanachalas
Признаться, но могу врубится в этот алгоритм (или же он мне не подходит).
Наборы ID, входящие в IN (....) моего SELECT-запроса никогда не повторяются! Зачем мне хранить эти наборы?
Если я не прав, объясните в двух словах как это работает? Или такую таблицу нужно налету создавать, чтобы избавится от IN в запросе, а потом ее очищать?
Если что, я не привязан к MySQL. Может тут лучше подойдет какая-то другая технология?
