> В мою бытность работы в СМИ прилетел "иск", от одного из самых крупных фотостоков, на 25 000 долларов.
В мою бытность владения СМИ прилетало письмо счастья от РКН мол на сайте пропаганда суицида и описания способа его совершения. На самом деле на странице была новость о том что в каком-то задрыпинске кто-то совершил суицид, выбросившись из окна высотки. Поскольку я об этом написал здесь - теперь и на эту страницу роботы РКН будут смотреть с особым пристрастием.
Уникализруйте взятые фото. Яркость, контраст, изменение размеров, шум в виде точек или штрихов мало отличающимся от исходного цветом и так далее, чтобы автоматические алгоритмы (в первую очередь - ПС) считали изображение уникальным.
Окупаемость у них и так была. Они своими туповатыми схемами работы потихоньку заставляли клиентов переходить на более дорогие тарифы. Например, по окончании 2Тб трафа в месяц скорость и пинг становятся такие как на мобильном интернете. Докупить траф нельзя - терпи лаги до конца месяца. Это не "наши" честные 10 мегабит безлимита после исчерпания какого-то объема. Дальше CPU. Не буду говорить что там происходит если ваши сайты (или что там запущено) потребляют хотя бы немного прилично процессорное время. То есть сразу минус нагруженные проекты, минус трафиковые проекты, минус все сколько-нибудь серьезное. Но был круг задач, для которых сервер за евро отлично подходил. А что они предлагают сейчас? В диапазоне до 230 рублей диск HDD 20GB, RAM 1GB - предложения минимум 5 хостингов, их которых услугами 2 я пользовался в разное время и знаю что им можно доверять (это не значит что остальным доверять нельзя). Ну это уже не говоря о том что часто вместо одного сервера на 20Г винта за те же деньги можно взять 2 по 10 и бонусом получить отдельный IP, что для сайтов сходной тематики только плюс.Они анализировали конкуренцию? Конечно. Зачем подняли цены? А очень просто. Мощностей не хватает, они решили не наращивать их, а по быстрому избавиться от основной массы клиентов, арендующих бюджетные сервера, чтобы распродать больше дорогих серверов. Конечно они имеют на это право юридически. И наплевать на общепринятую практику что клиент пользуется тарифом который действовал при заказе, а новые клиенты покупают по новой цене. Часто новая тарифная линейка дает за те же деньги больше ресурсов и клиенты сами должны следить за этим и переходить вовремя. А тут ситуация напоминает не буду упоминать название одного хостинга, который сначала насобирал клиентов, а потом под любым предлогом пытался от них избавиться (включая блокирование серверов по надуманным причинам). Чем еще объяснить то что при постоянной нагрузке на протяжении 2 месяцев я словил блокировку за флуд именно сейчас?
Все как всегда, был хороший хостинг - и перестал быть хорошим.
Кто еще пользуется данным хостингом Aruba Cloud - валите оттуда пока не поздно.
В прошлом месяце эти сволочи сделали рассылку о поднятии цен почти в 3 раза (2.79 если точнее), без увеличения ресурсов на тарифах. Техподдержка считает что это нормально. При этом началась лажа с блокировкой серверов. У меня крон задача выбирает из базы пачку доменов и определяет их IP адреса (вызов gethostbynamel()). 2 месяца назад я поднял число доменов, проверяемых за раз. Сегодня моему серверу прилетела блокировка за нелегальную активность. Через техподдержку вопрос решили, но осадочек остался.
Поднял цены хоть раз - ... (дорифмуйте сами)
Типичная последовательность действий
1. Настроить MySQL слушать 0.0.0.0
2. Убедиться (netstat -lpn | grep 3306) что он слушает то что сказано
3. Подключиться снаружи телнетом на этот порт и убедиться что подключение устанавливается (если нет - добавить разрешение в файрвол)
4. Добавить юзера user@'%' либо с заданным чужим IP и сделать ему GRANT. Подключиться снаружи с этим юзером и убедиться что все работает.
Как-то так. Еще надо учесть что на серваке может быть iptables, а у облачного провайдера - еще один свой файрвол.
> Но не скажется ли это на работе в других местах...
Если скажется - Вы это сразу заметите когда что-то перестанет работать. Если есть прямой доступ к серверу по SSH / SFTP, то зачем держать FTP сервер, занимающий память, и собирающий сканеры портов словно мух?
EXPLAIN EXTENDED SELECT * FROM table1 WHERE key1=value1 AND key2=value2 AND id>97262353; EXPLAIN EXTENDED SELECT * FROM table1 WHERE key1=value1 AND key2=value2 AND date>1590969600;
При условии по primary key (id) type=range, по дате ref.
possible_keys в 1 случае PRIMARY, key2, key1; во втором - date, key2, key1 (видимо, обратный порядок это норма).
Длина ключа 8 ref=NULL, если по дате длина 4 ref = const. Сильно сокращает время "Using index condition".
Что с длиной ключа я не понимаю, key1 - tinyint (1 байт), key2, id и date - int (4 байта). Как из этого получаются цифры 4 и 8 не ясно, используются только 2 индекса, на остальные база кладёт? Чуть раньше пробовал принудительно USE INDEX на key1, key2, date либо просто key1, key2 - разницы по времени не заметил.
Mobiaaa, UNIX_TIMESTAMP()-864000 и php time()-864000, подставленное в запрос, не дает существенной разницы по времени выполнения запроса (засекаю время только mysqli_query, fetch не произвожу). Не заметил. Предполагаю что MySQL считает цифру один раз до прохода по таблице.
LEOnidUKG, это тест! Оптимизация базы и подбор носителя для ее хранения. Реальные запросы, даже самые тяжелые, на старом железе занимают до 5 секунд, а я хочу доли секунды. Я сейчас намеренно гоняю базу по всей таблице, в результате чего у меня по 44 секунды на запрос идет. Если при каком-то действии 44 секунды вдруг уменьшатся до 30 это эффективная оптимизация, если бы это было 4.4 против 3.0 я бы разницу не заметил и списал разницу на любой другой фактор (крон задача в этот момент обращалась к памяти или что-то еще). В одном из реальных запросов используется COUNT после выбора по критериям, и подсчитываются только несколько тысяч записей. Пусть подсчитываются, без этого нельзя и это не занимает много ресурсов если все остальное работает быстро.
Осилил приближенное вычисление значения id (primary key) по date (timestamp) с точностью достаточной для выполнения необходимой задачи. Выигрыш WHERE id>xxx (id unsigned int(4) - primary) перед WHERE date>yyy (date unsigned int(4), индекс ) на MyISAM в 3.5 раза, Ariadb 3.25 раз, InnoDB в 7.4 раза. Это уже успех, но останавливаваться на этом пока еще не готов. Всё равно пока еще не понял, почему primary работает быстрее обычного индекса.
> это не полноценный поиск
Пардон, фигню сморозил. Да, полнотекстовый использовал в какой-то задаче но не здесь.
> Вообще никакой и никогда
А об этом можно подробнее? При сравнении 2 запросов
SELECT * FROM table1 WHERE [key1]=[value1] AND [key2]=[value2] AND date>[xxx]SELECT * FROM table1 WHERE [key1]=[value1] AND [key2]=[value2] AND date>[xxx] AND myvarchar LIKE '%blablabla%'
получаю во втором существенно меньшее число строк, удовлетворяющих условиям, но время, затраченное на сам запрос, одинаково для всех механизмов хранения. Например, MyIsam 22.22 и 21.46 сек, InnoDB 82.41 и 79.16 сек.
