Способ баян, но все равно спасибо.
Как пример аналогов - без комиссии текущий -> карточный через Ощадний на Unicredit и др. подобные примеры.
Да, и нал не дают. В Украине выдача налички идет в нацвалюте с конвертацией.
Ну борьба с мышами, поедающими твои запасы зерна была актуальна с доисторических времен. Официальный вывод на текущий счет в отличие от вывода на карту, дает кажется на 1% меньше комиссии. Раньше еще были банки, позволяющие снимать нал без комиссии в банках-партнерах за рубежом - так решался вопрос с обменом при отсутствии валюты в Украине, но потом лавочка закрылась.
WMU - не валюта же? код операции надо бы смотреть но скорее всего покупка цифровых товаров.
А в чем прикол? В понедельник намечаются очередные массовые закрытия наших банков?
Профита в таких схемах, если я не ошибаюсь, нет со времен ликвидации E-Gold.
Что значит нет sqlite3_open когда она есть, точнее была.
Есть такой класс разработчиков, не заботящихся об обратной совместимости. Не знаю точно, когда эта эпидемия началась, но хорошо помню что в Windows XP были тупо вырезаны функции из системных библиотек, в результате куча софта, разработанного раньше выхода XP ругались на то что точка входа не найдена, а для совместимости с разными версиями позже приходилось писать кучу лишнего кода для динамического импорта...
Пришлось еще кучу кода переписывать до того как понял что есть параметр SQLITE3_ASSOC...
P.S. нет уж, на PDO переписывать не буду.
P.S.2. на сервере 4 ядра, процесс до сих пор идет хотя на рабочем ноуте время "обработки" 16Мб-базы было в пределах 10 минут... Надо будет еще вывод прогресса и замер времени писать...
Неужели это невозможно?
Может быть, Yandex XML + фильтр доменов по блек листу + кеш результатов на неделю? ИМХО самый наименее затратный вариант.
Если парсить выдачу Яндекса или Гугла в лоб будет подводных камней немеряно, начиная от занадоевшей капчи каждые 50 страниц и заканчивая их привычкой менять HTML разметку в выдаче.
Вместо SELECT * не думаю что будет толк, т.к. используются почти все поля кроме пары числовых. Все остальное давно вынесено в отдельную таблицу.
Спасибо, буду проверять. Не спешу чтобы на стате разницу посмотреть.
С "читайте также" разобрался, через пару дней сравню среднюю нагрузку с прошлым периодом.
Грубо говоря 5000 страниц по 20 постов на страницу дают то самое значение индекса из запроса. У меня свой лог медленных запросов, включающий время запроса, адрес запрошенной страницы, сам запрос и еще много чего. В нем полно подобных запросов для больших номеров страниц т.е. больших значений индекса.
Практика показывает что это не так. Возможно из-за прохода по большому файлу с записями переменной толщины.
индекс id и категория - все по чему делается WHERE.
А в чем прикол? Все равно идет чтение индексов из таблицы с динамическим размером записи, а потом по этим индексам подтягиваются остальные поля.
Из базуки по воробьям... Обычный поиск по сайту, зачем там сложные поисковые движки.
Это не главное, я изначально говорил о подборе похожих новостей по теме.---------- Добавлено 03.10.2015 в 15:50 ----------Еще один вопрос, позволю себе задать тут же, хотя тема другая.
В каждой категории идет постраничный вывод новостей от новых к старым. Как уменьшить время запросов вида
для очень больших номеров страниц?
Ну сейчас AUTO_INCREMENT=423210, раньше помню когда было 200к записей. Не помню когда именно менял алгоритм, возможно как раз когда было 200к.
Хостинг врядли. Двиг писался больше 6 лет назад, опыта было мало, хостил на хостинге за $1 в месяц. Когда меня оттуда турнули за нагрузку пару лет назад я перебрался сразу на VPS - база загнулась за пол часа после переезда, после чего я все максимально оптимизировал что мог. На серваке еще ресурсы есть, кроме этого сайта там еще несколько, при этом нагрузка CPU не 100%. Не думаю что нужно менять хостинг.
Единственное что я пока не понимаю - раньше было 10к в сутки посетителей, но с начала года Яндекс что-то мутит и с февраля у меня 1-2к, а тормоза жестче стали.
ОК, так и думал что нужно результаты поиска кешировать на скажем пару суток, чтобы новые статьи в "похожие" добавлялись, но поиск шел по индексам и нагрузка была меньше. Для самой статьи нет, только в отдельную таблицу. Просто очень не хочу делать теги как в DLE - мне такая реализация не нравится.
Поиск от Яндекса ерунда, чтобы он был актуален нужно быстрое попадание в индекс чего сейчас нет.
Указанную статью когда-то читал, половина из этого уже применяется.
