Удивительно: Может быть это и не настоящая многопоточность, но я её успешно юзаю и всё работает. При работе в 10-50 потоков скрипты ни разу не подвисли и ни разу дошли до потолка в 256 мб (я им столько выделяю на VDS). Работа идет практически круглые сутки, так что.....
Это таки не настоящая многопоточность :)
И мультикурл выполняется столько, сколько выполняется самый долгий из handles (или пока timeout не прийдет). Работает шустрее, чем если последовательно дергать - это да. Но...
Рефспамилка на мультикрле делала около 40 хитов в секунду, переписал на .нет - чуть за 200 (канал один и тот же, не шустрый).
Visuall: Проблема не в движке, если только он в 95% случаев не используется под ГС (был такой пример, не помню как назвался двиг), таких движков среди перечисленных нет.
О, вы наверняка про CMSimple 😆
У меня из рекордсменов такой на сапе около 300 у.е. уже принес, ПР 2 у него сейчас, ТИЦ 20...
И вылетать из индекса не спешит. Как и еще несколько на этом же движке. Ы? ;)
wdsg: Давайте выполним небольшой тест, ведь лучше один раз получить практическое подтверждение, чем месяцами спорить о эффективности того или иного метода.
// Готовим тестовый массив. Пусть в нём будет 100000 элементов.
$Arr = array();
for ($i = 0; $i < 100000; $i++) {
$Arr[] = 'value'.$i;
}
// Будем искать в массиве значение $Word
$Word = 'value99999';
// А теперь попросим сделать тоже самое встроенную функцию. Как Вы выразились, "просто возложим поиск на интерпретатор"
$Start2 = microtime(true);
$Keys = array_keys($Arr, $Word);
print_r($Keys);
$Time2 = microtime(true) - $Start2;
echo 'Вариант 1: '.$Time1.' Вариант 2:'.$Time2;
У меня первый вариант занимает ~0.04 c., а второй ~0.008 c. Полагаю, это стимулирует к определённым выводам.
Угу. Особенно если время, затраченное на второй вариант считать без print_r ;)
Насчет SQL - юзать стоит. Особенно если сделать индекс.
for ($i = 0; $i < count ($words); $i++){Код
}
Вот так никогда не делайте.
Почему "никогда"? А вдруг мы в цикле меняем количество элементов в $words? ;)
Может быть это и не настоящая многопоточность, но я её успешно юзаю и всё работает. При работе в 10-50 потоков скрипты ни разу не подвисли и ни разу дошли до потолка в 256 мб (я им столько выделяю на VDS). Работа идет практически круглые сутки, так что.....
Это таки не настоящая многопоточность :)
И мультикурл выполняется столько, сколько выполняется самый долгий из handles (или пока timeout не прийдет). Работает шустрее, чем если последовательно дергать - это да. Но...
Рефспамилка на мультикрле делала около 40 хитов в секунду, переписал на .нет - чуть за 200 (канал один и тот же, не шустрый).
🍻
уже 22 на кону :)
Проблема не в движке, если только он в 95% случаев не используется под ГС (был такой пример, не помню как назвался двиг), таких движков среди перечисленных нет.
О, вы наверняка про CMSimple 😆
У меня из рекордсменов такой на сапе около 300 у.е. уже принес, ПР 2 у него сейчас, ТИЦ 20...
И вылетать из индекса не спешит. Как и еще несколько на этом же движке. Ы? ;)
Надолго - это минимум на месяц? ;)
А если ап ближайший дня через 2-3 будет - ваши сроки от этого не сдвигаются?
Ну, и "классика" - готовы по факту работать? Могу перевод с протекцией сразу организовать...
Есть к сайтам какие-то требования?
И это действительно индекс, а не быстробот?
Сегодня захожу - а у меня аккаунт FREE
Аналогично :)
Верните про или дайте уже возможность оплатить :)
14 давайте попробуем
Давайте выполним небольшой тест, ведь лучше один раз получить практическое подтверждение, чем месяцами спорить о эффективности того или иного метода.
У меня первый вариант занимает ~0.04 c., а второй ~0.008 c. Полагаю, это стимулирует к определённым выводам.
Угу. Особенно если время, затраченное на второй вариант считать без print_r ;)
Насчет SQL - юзать стоит. Особенно если сделать индекс.
контрольная сумма?
Хеш ;)
10 хешей