>> должна быть под это условная вакансия под мидла
ну была бы условная вакансия под мидла, брали бы сразу мидла xD
>> ни рано или поздно уйду на позицию выше
и чем дальше в лес, тем быстрее это происходит (конкуренция растёт не только за нормальных, а просто за «из лужи не пьющих»)
ну окей, вырастил джуна (я вырастил наверное уже с десяток разрабов и админов суммарно, в 3 конторах так что статистика накопилась), вопрос что делать дальше. Получается так:
1. 100+ резюме, 10+ собесов,…, взял джуна и естественно не кого попало
2. вырастил джуна (вероятность 1/2-3/4)
3. получаю уведомление что «рекрутёръ атакують», начинаю превентивный движ
4. затем оказывается, что денег на апгрейд ставки нет(а я же взял нормального, поэтому офферы уже естественно есть )
5. подписал ему заявление
6. «у вас же есть ставка джуна», goto 1.
Притворится ботом и покупать по заниженным ценам — профит
Всё несколько сложнее.
притворится краулером гугла
В доках гугла и яндекса очень подробно написано что делать и как проверять user-agent их ботов. Быстро, просто, а если еще и кеширование результата проверки сделать…
парсить не сам сайт, а кэш с гугл поиска
… и разгадывать рекапчу ради цен N-месячной давности
У меня есть большой релевантный опыт (около 5 лет суммарно в разных местах) с двух сторон этих баррикад и вот что я вам скажу:
0. подтверждаю тезис про «всё можно спарсить», просто вопрос борьбы брони и меча. И чтобы гражданские покупатели не пострадали.
1. Многие (>70%) парсеры берут партнёрские фиды полученные из адмитада(и прочих cpa) или по коммерческому api я.маркета и аналогов и с умным видом выдают за свои.
Проверялось так: завышаем в этих фидах цену на 10-20 товаров на 1-50 рублей и смотрим где всплывёт. Ответ: почти везде
2. В большом % случаев возможно точно определить бота и отдавать конкретно этому боту «немного кривые» цены.
Входные данные: условный конкурент закупается в том же месте, и пытается бороться за трафик маркета ценой, для чего мониторит цену на ресурсе А и автоматически управляет своей ценой.
Вычисляем боты этого конкурента и начинаем им и только им системно занижать. Результат: конкурент торугет в убыток и понимает это не сразу. Один раз меня встретили у промозоны и обещали в случае повторения подобного занижения сломать челюсть так как «это нечестно и нам надо кормить семьи». Даже без обещаний по IP вычислить. Ох уж эти маленькие локальные розничные конторки.
Угрозы на мыло за tarpit/delude в направлении чьей-то инфры парсинга на этом фоне кажутся мелочами.
3. Некоторые вполне отдают свои цены любому заинтересованному лицу. В HTML-коде сайта даже ссылку ставили куда писать чтобы получить фид с актуальными ценами, но таки нет, всё равно парсеры будут парсить, а получать фид официально никто не захочет, проще же по прекрасному упороться.
4. а ещё можно просто перестать конкурировать по цене и я уверен что мы это увидим в ближайшее время (сошлюсь на GFK: миграция массового покупателя от цены к ценности).
5. от ботов есть и польза: они делают искусственный прогрев кешей излишним и греют его для и вместо реальных посетителей. жму им их мужественный сетевой интерфейс за это.
немного аккуратных усилий по «борьбе» с ботами дают 80% результата. не точно так, но близко к истине. Если принято решение бороться, достаточно просто чуть поднять стоимость массового парсинга что в принципе должно полностью устраивать автора этого поста так и владельцев необходимой информации.
Предположим бота зовут Джо. Все помнят почему «неуловимый Джо такой неуловимый»?
Несколько ( >5) лет назад я нашёл уязвимость одного магазина этой же хм… группы компаний. Замечу, что реакция была очень оперативной и очень адекватной.
От этого инцидента у меня остался памятный подарок и письмо-благодарность.
Больше всего в текущей истории мне интересно почему не было реакции на багрепорт и дошёл ли он вообще до ответственных, которые могут его интерпретировать. Бразильская система, конечно, порождает разные казусы, но способна до определенного момента быстро делать изменения(а тут этого не произошло).
я печатаю до 50 стр. в месяц. (исключим пики по 300-500, но это очень редко, раз в несколько лет).
Мой выбор — перезаправляемые картриджи(ПЗК). И я не понимаю почему производители не могут организовать нормальные ПЗК пусть даже с бутылками по кодам.
Почему:
— не нужно вандализма как при установке СНПЧ
— меньше изнашиваемых частей (гибкие трубки) разрыв которых фатaлен
— заправить картридж шприцом из стамиллилитровой банки всяко проще чем искать даже оригинальные картриджи которые нельзя закупить впрок, так как нельзя заранее знать оставшийся срок их годности (у эпсонов в оригинальном картридже батарейка, и если она за время пока картридж лежал на полке разрядилась, то увы).
— оригинальные картриджи кончаются до момента когда в них кончаются чернила (в том же моём эпсоне из картриджа с которым принтер отказывается работать я сливал примерно 3-5 мл чернил остатка)
Набор ПЗК для Epson 525WD я покупал за 10$, + 4 банки чернил по 100-150 р. каждая (одна заправка 6-8мл)
В ПЗК также есть батарейка, которую я также раз в 2-3 года меняю (rentata за 5$/блистер или трофи из фикспрайса за 1$).
Знакомые используют* эту же комбинацию в условиях «100 страниц в день» + резервный сканер + сотрудникам для печати чего угодно для личных целей в нерабочее время и проблем с принтером минимум. Сняли видео-инструкцию как заправлять картридж, положили в тумбочку набор из «одноразовых» фартуков и перчаток и всё обслуживается само, раз в год просто расходники контора докупает.
*) есть варианты дешевле и проще, но остановились на этой «так как видели своими глазами»
Кушать кетанов при занозе это очень странно, по двум причинам: 1. чаще всего проще вынуть и без врача и она хотябы перестанет мешать дойти до врача и вызывать боль при прикосновении 2. есть местные антибиотики.
>> Дико туплю — это вы к чему?
Ваш комментарий про полевые условия как раз напомнил мне «те времена».
Поверьте, ожидание в приёмном покое у меня тоже было.
Я проклял всё. Но в принципе я уже потом всё обдумав понял что могло быть и хуже.
> Если вы верите, что исследования быстрее приведут сайт к работоспособности — исследуйте
Мой опыт потокового решения подобных проблем с популярными CMS (я думаю что это точно больше сотни кейсов только по WP) говорит о том, что диагностика важнее. Коллеги даже для SLA считали — в среднем 7 минут диагностика, полное решение 10 (разница небольшая, так как в основном даже правки по коду не нужны).
> И чем больше денег мы теряем на простое — тем лучше использование брутто-методов.
Не всё так однозначно.
Конечно, впилить костыль в результате которого закешируется страничка с админским айдишником сессии это намного лучше.
«Проблема решена — решена. А то что теперь рандомный пользователь может делать с сайтом что угодно, об этом в задаче не было.»
Я сейчас работаю с ресурсом(Alexa top 2k, alexa_RU top 100), где минутный простой стоит очень дорого, а косяк в результате которого будут слиты наружу пользовательские данные — ещё дороже.
Все такие истории это баланс скорости и рисков. Вот и всё.
ЗЫ ах эти времена с кнопочными телефонами и midp-ssh
А по сути дела тут важно примерно понимать где проблема. Ну вы же не пойдёте к стоматологу, если у вас болит нога или не будете заливаться анальгетиками при занозе в руке.
А с сайтом непонятно, он, к сожалению(или к счастью пока), не говорящий.
Я всё-таки настаиваю, что всегда стоит нормально делать диагностику(именно поэтому я и написал комментарий), а только потом чинить причину.
Также я исхожу из того, что главная задача — восстановить работу сайта минимально рисковыми телодвижениями. Ваше решение вполне вписывается в такую постановку (оно не лишено недостатков о большинстве вам рассказали выше).
Если причина конкретный функционал, проще всего выполнить его отключение штатными средствами. Это самый понятный для владельца сайта и для исполнителя путь.
>> Диагностика — это хорошо, но сколько бы заняло решение?
В 80% случаев 5-15 минут.
>> xhprof/xdebug — не на «живом» сайте в момент падения сервера все-таки.
Не соглашусь категорически.
На живом, и именно в момент падения (иначе как узнать реальную причину?). Оверхед если не писать каждый запрос около 2%(xhprof). Конечно, писать выборочно по куке/GET-параметру, собрать 10-20 образцов, отключить.
>> Изначально там не было (!) никаких плагинов кэширования. Ставить cron на файловый кэш — это тоже костыль.
Удаление заведомо просроченного кеша это правильный механизм. Кеш должен иметь TTL, но файловый кеш в условиях шаред хостинга, это не redis.
Удаление по крону это резервный механизм который много раз спасал. Кейс конкретный: плагин WP обновился, поменялись ключи кеширования и почему-то отключилась автоматическая очистка. Один из плагинов (я уже забыл название и версию) вообще никогда не чистил просроченные элементы по которым нет попаданий. Третий тёр файлы, но не тёр пустые папки.
Если бы все плагины имели корректно работающие механизмы очистки, это конечно же было бы лишним.
>> 2) Эти плагины нужно найти, затем понять зачем они и затем принять решение как пофиксить проблему.
Часто суть проблемы проще, чем кажется на первый взгляд.
В случае в внешними ресурсами даже часто править код не надо. Достаточно просто (на время до реализации нормального решения или отлипания внешнего ресурса*) через /etc/hosts сделать так чтобы проблемный внешний ресурс резолвился в, к примеру, 127.0.0.2, а соединение с ним быстро падало (а не после 10 секунд ожидания).
Конечно, отключение плагинов всегда согласовывается. У меня очень были случаи когда плагин реально несущий. Большинство поставщиков подобных проблем это плагины курсов валют, погоды, rss/twitter и прочая подобная ерунда. Особняком стоят биржи ссылок, но с этим добром отдельная история.
>> 3) Это и есть корень зла в данном конкретном случае
Да, такие проблемы иногда не решаются простыми способами. Но посмотрите внимательно на БД, вдруг после череды обновлений в таблицах нет в сравнении с новой чистой установкой нужных индексов или чего-то подобного?
Так или иначе, успехов в делах и новых интересных задач!
Нормальное решение:
Ставим xhprof/xdebug (strace, если хочется тёплого лампового свечения сисколов), рандомно включаем на 2-3 страницах, видим в чем проблема.
Обычно варианта три
1. Очень большие задержки от файловой системы. В 90% случаев не чистится файловый кеш(чистим, проверяем настройки плагинов кеширования и на всякий случай ставим соответствующий крон find… -delete раз в час для файлов старше CACHE_TIME*2)
2. Очень большие задержки по сети (конкретный плагин который делает запросы по сети, а удалённый ресурс тормозит). Обычно таких плагинов 1-2, после их отключения и/или впиливания кеширования конкретно в них всё работает.
3. Конкретный плагин который кладёт БД. Смотрим запросы в mysql -e 'show full processlist', проставляем индексы ну или запиливаем кеш где логически возможно.
4. Если ни одно из вышеперечисленных, убеждаемся что машине тупо не хватает процессора, добавляем немного ядер и спокойно изучаем проблему более детально.
Эти 4 пункта покрывают 99% случаев. Остальной 1% это самое интересное и выходит за рамки этого комментария.
Когда работал в хостинге решал такие проблемы десятки раз, на потоке диагностика занимала 5-10 минут. И что WP, что битрикс, что друпал всё одно примерно и проблемы одинаковые.
Честно говоря, это всё общетехнические методы, которые мне постоянно помогали и не только в php-приложениях.
PS шаг 0. Смотрим на htop и понимаем чем конкретно занимается машина и чего ждёт вообще.
Есть интересный кейс который я много где замечал, в т.ч. (и особенно!) не в IT:
Премию за сроки получает производство (применительно к ИТ — разработчики), а риски за эту скорость (скрытые дефекты) несёт эксплуатация у которой обычно никаких премий нет.
Просто из того, что эксплуатация это обычно операционные издержки с фиксированным бюджетом, а производство — нет (и тут может быть «недорасход бюджета»).
При этом у меня есть пример (это история не из ИТ) такая ситуация регулярно приводила к натуральному мордобою, когда премии уже распланированы, иногда даже потрачены, а приёмка изделия в эксплуатацию невозможна из-за наличия в изделии дефектов (ну или же полного отсутствия изделия как такового).
У 2IP база настолько древняя, что к примеру сеть моего провайдера, которой мы пользуемся уже лет 5 до сих пор числится со старыми данным.В whois корректно указаны lat/lon, country:, как у AS в которую она входит. Аналогично с контактами maintainer-ов. Более крупные inetnum-ы в whois отсутствуют.
Судя по всему, эта проблема растёт из того, что следующая /23 действительно относится к этому некорректному региону.
Плюсую. Аналогичная ситуация. Меня настолько это, а в последнее время ещё и невозможность открыть в новом окне часть интерфейса раздражает, что я принимаю решение лишний раз не заходить туда и платить условными Я-деньгами. Пытался использовать приложение, но это ад. в поле ввода суммы платежа не появляется клавиатура что бы я ни делал.
Такое впечатление что там вообще никто ничего последнее время не тестирует.
Причем юз-кейс стандартный. Платил себе платёж, и тут понял что упёрся в настроенный лимит на операции в ИБ. И у меня реально нет способа в отдельном окне открыть управление лимитами. Только в этом же, потеряв все заполненные реквизиты.
После того как на среднюю кнопку ИБ отреагировал сбросом реквизитов, я решил послать это всё нафиг и заплатить через яд.
Смотря на это всё, это худшая реклама инструмента. Не в смысле что инструмент плохой, а контекст.
хм.
Дамп зоны (как и whois) вполне легально раздаётся регистраторами своим клиентам. Правда, мне для этого потребовалось подписать несколько допников к договору (о том что я обязуюсь никому не передавать их).
Аналогично раздаются дампы .org (выдаётся по бумажному письму в pir.org) и некоторых других…
Я работал с ними.
Осень слабый антифрод и отсутивие 3d-secure / vbv(нет и не планируется).
Собственно, у меня всё. Если сервис не умеет критисные вещи, какая разница какое у него API.
Одно из худших (с т.з. стабильности) обновлений.
Все 2016.1+ при непонятных условиях(нет background tasks и чего-то подобного, отключены все плагины, IDE просто открыта) начинают просто съедать процессор. Помучился помучился и откатился на 9-10 версии.
Честно говоря, со стабильностью уже примерно год от версии к версии то появляются то исчезают подобные чудеса. Хочется уже найти стабильную fallback версию и остаться на ней и параллельно смотреть альтернативы…
Однажды обнаружил бесплатный «безабузный» хостинг, который парой скриптиков пёр честно спёртое его «пользователями». Причем, судя по контенту, довольно хорошо безабузный.
Жесткий диске этого «хостинга» случайно не был отформатирован сотрудниками ДЦ при установке в наш сервер. Почерпнул много интересного в ходе изучения остатков его файловой системы.
Уже известны некоторые параметры сервера: в частности, Zaius предназначен для установки в стойку с напряжением в 48В вместо обычных 12В
Ссылок на источник нет, так что прошу проверить может не 12V, а обычные для US 120V?
Хотя если тут нолик потеряли, может и не 48, а 480?
Логически понижение напряжения понятно (проще понижать на вводе в стойку/ДЦ, а не в сервер), но всё равно прошу проверить.
ну была бы условная вакансия под мидла, брали бы сразу мидла xD
>> ни рано или поздно уйду на позицию выше
и чем дальше в лес, тем быстрее это происходит (конкуренция растёт не только за нормальных, а просто за «из лужи не пьющих»)
1. 100+ резюме, 10+ собесов,…, взял джуна и естественно не кого попало
2. вырастил джуна (вероятность 1/2-3/4)
3. получаю уведомление что «рекрутёръ атакують», начинаю превентивный движ
4. затем оказывается, что денег на апгрейд ставки нет(а я же взял нормального, поэтому офферы уже естественно есть )
5. подписал ему заявление
6. «у вас же есть ставка джуна», goto 1.
эта музыка будет вечной.
Всё несколько сложнее.
В доках гугла и яндекса очень подробно написано что делать и как проверять user-agent их ботов. Быстро, просто, а если еще и кеширование результата проверки сделать…
… и разгадывать рекапчу ради цен N-месячной давности
0. подтверждаю тезис про «всё можно спарсить», просто вопрос борьбы брони и меча. И чтобы
гражданскиепокупатели не пострадали.1. Многие (>70%) парсеры берут партнёрские фиды полученные из адмитада(и прочих cpa) или по коммерческому api я.маркета и аналогов и с умным видом выдают за свои.
Проверялось так: завышаем в этих фидах цену на 10-20 товаров на 1-50 рублей и смотрим где всплывёт. Ответ: почти везде
2. В большом % случаев возможно точно определить бота и отдавать конкретно этому боту «немного кривые» цены.
Входные данные: условный конкурент закупается в том же месте, и пытается бороться за трафик маркета ценой, для чего мониторит цену на ресурсе А и автоматически управляет своей ценой.
Вычисляем боты этого конкурента и начинаем им и только им системно занижать. Результат: конкурент торугет в убыток и понимает это не сразу. Один раз меня встретили у промозоны и обещали в случае повторения подобного занижения сломать челюсть так как «это нечестно и нам надо кормить семьи». Даже без обещаний по IP вычислить. Ох уж эти маленькие локальные розничные конторки.
Угрозы на мыло за tarpit/delude в направлении чьей-то инфры парсинга на этом фоне кажутся мелочами.
3. Некоторые вполне отдают свои цены любому заинтересованному лицу. В HTML-коде сайта даже ссылку ставили куда писать чтобы получить фид с актуальными ценами, но таки нет, всё равно парсеры будут парсить, а получать фид официально никто не захочет, проще же по прекрасному упороться.
4. а ещё можно просто перестать конкурировать по цене и я уверен что мы это увидим в ближайшее время (сошлюсь на GFK: миграция массового покупателя от цены к ценности).
5. от ботов есть и польза: они делают искусственный прогрев кешей излишним и греют его для и вместо реальных посетителей. жму им их мужественный сетевой интерфейс за это.
немного аккуратных усилий по «борьбе» с ботами дают 80% результата. не точно так, но близко к истине. Если принято решение бороться, достаточно просто чуть поднять стоимость массового парсинга что в принципе должно полностью устраивать автора этого поста так и владельцев необходимой информации.
Предположим бота зовут Джо. Все помнят почему «неуловимый Джо такой неуловимый»?
От этого инцидента у меня остался памятный подарок и письмо-благодарность.
Больше всего в текущей истории мне интересно почему не было реакции на багрепорт и дошёл ли он вообще до ответственных, которые могут его интерпретировать. Бразильская система, конечно, порождает разные казусы, но способна до определенного момента быстро делать изменения(а тут этого не произошло).
Мой выбор — перезаправляемые картриджи(ПЗК). И я не понимаю почему производители не могут организовать нормальные ПЗК пусть даже с бутылками по кодам.
Почему:
— не нужно вандализма как при установке СНПЧ
— меньше изнашиваемых частей (гибкие трубки) разрыв которых фатaлен
— заправить картридж шприцом из стамиллилитровой банки всяко проще чем искать даже оригинальные картриджи которые нельзя закупить впрок, так как нельзя заранее знать оставшийся срок их годности (у эпсонов в оригинальном картридже батарейка, и если она за время пока картридж лежал на полке разрядилась, то увы).
— оригинальные картриджи кончаются до момента когда в них кончаются чернила (в том же моём эпсоне из картриджа с которым принтер отказывается работать я сливал примерно 3-5 мл чернил остатка)
Набор ПЗК для Epson 525WD я покупал за 10$, + 4 банки чернил по 100-150 р. каждая (одна заправка 6-8мл)
В ПЗК также есть батарейка, которую я также раз в 2-3 года меняю (rentata за 5$/блистер или трофи из фикспрайса за 1$).
Знакомые используют* эту же комбинацию в условиях «100 страниц в день» + резервный сканер + сотрудникам для печати чего угодно для личных целей в нерабочее время и проблем с принтером минимум. Сняли видео-инструкцию как заправлять картридж, положили в тумбочку набор из «одноразовых» фартуков и перчаток и всё обслуживается само, раз в год просто расходники контора докупает.
*) есть варианты дешевле и проще, но остановились на этой «так как видели своими глазами»
>> Дико туплю — это вы к чему?
Ваш комментарий про полевые условия как раз напомнил мне «те времена».
Я проклял всё. Но в принципе я уже потом всё обдумав понял что могло быть и хуже.
> Если вы верите, что исследования быстрее приведут сайт к работоспособности — исследуйте
Мой опыт потокового решения подобных проблем с популярными CMS (я думаю что это точно больше сотни кейсов только по WP) говорит о том, что диагностика важнее. Коллеги даже для SLA считали — в среднем 7 минут диагностика, полное решение 10 (разница небольшая, так как в основном даже правки по коду не нужны).
> И чем больше денег мы теряем на простое — тем лучше использование брутто-методов.
Не всё так однозначно.
Конечно, впилить костыль в результате которого закешируется страничка с админским айдишником сессии это намного лучше.
«Проблема решена — решена. А то что теперь рандомный пользователь может делать с сайтом что угодно, об этом в задаче не было.»
Я сейчас работаю с ресурсом(Alexa top 2k, alexa_RU top 100), где минутный простой стоит очень дорого, а косяк в результате которого будут слиты наружу пользовательские данные — ещё дороже.
Все такие истории это баланс скорости и рисков. Вот и всё.
ЗЫ ах эти времена с кнопочными телефонами и midp-ssh
А по сути дела тут важно примерно понимать где проблема. Ну вы же не пойдёте к стоматологу, если у вас болит нога или не будете заливаться анальгетиками при занозе в руке.
А с сайтом непонятно, он, к сожалению(или к счастью пока), не говорящий.
Я всё-таки настаиваю, что всегда стоит нормально делать диагностику(именно поэтому я и написал комментарий), а только потом чинить причину.
Также я исхожу из того, что главная задача — восстановить работу сайта минимально рисковыми телодвижениями. Ваше решение вполне вписывается в такую постановку (оно не лишено недостатков о большинстве вам рассказали выше).
Если причина конкретный функционал, проще всего выполнить его отключение штатными средствами. Это самый понятный для владельца сайта и для исполнителя путь.
>> Диагностика — это хорошо, но сколько бы заняло решение?
В 80% случаев 5-15 минут.
>> xhprof/xdebug — не на «живом» сайте в момент падения сервера все-таки.
Не соглашусь категорически.
На живом, и именно в момент падения (иначе как узнать реальную причину?). Оверхед если не писать каждый запрос около 2%(xhprof). Конечно, писать выборочно по куке/GET-параметру, собрать 10-20 образцов, отключить.
>> Изначально там не было (!) никаких плагинов кэширования. Ставить cron на файловый кэш — это тоже костыль.
Удаление заведомо просроченного кеша это правильный механизм. Кеш должен иметь TTL, но файловый кеш в условиях шаред хостинга, это не redis.
Удаление по крону это резервный механизм который много раз спасал. Кейс конкретный: плагин WP обновился, поменялись ключи кеширования и почему-то отключилась автоматическая очистка. Один из плагинов (я уже забыл название и версию) вообще никогда не чистил просроченные элементы по которым нет попаданий. Третий тёр файлы, но не тёр пустые папки.
Если бы все плагины имели корректно работающие механизмы очистки, это конечно же было бы лишним.
>> 2) Эти плагины нужно найти, затем понять зачем они и затем принять решение как пофиксить проблему.
Часто суть проблемы проще, чем кажется на первый взгляд.
В случае в внешними ресурсами даже часто править код не надо. Достаточно просто (на время до реализации нормального решения или отлипания внешнего ресурса*) через /etc/hosts сделать так чтобы проблемный внешний ресурс резолвился в, к примеру, 127.0.0.2, а соединение с ним быстро падало (а не после 10 секунд ожидания).
Конечно, отключение плагинов всегда согласовывается. У меня очень были случаи когда плагин реально несущий. Большинство поставщиков подобных проблем это плагины курсов валют, погоды, rss/twitter и прочая подобная ерунда. Особняком стоят биржи ссылок, но с этим добром отдельная история.
>> 3) Это и есть корень зла в данном конкретном случае
Да, такие проблемы иногда не решаются простыми способами. Но посмотрите внимательно на БД, вдруг после череды обновлений в таблицах нет в сравнении с новой чистой установкой нужных индексов или чего-то подобного?
Так или иначе, успехов в делах и новых интересных задач!
*) в зависимости от уровня перфекционизма.
Ставим xhprof/xdebug (strace, если хочется тёплого лампового свечения сисколов), рандомно включаем на 2-3 страницах, видим в чем проблема.
Обычно варианта три
1. Очень большие задержки от файловой системы. В 90% случаев не чистится файловый кеш(чистим, проверяем настройки плагинов кеширования и на всякий случай ставим соответствующий крон find… -delete раз в час для файлов старше CACHE_TIME*2)
2. Очень большие задержки по сети (конкретный плагин который делает запросы по сети, а удалённый ресурс тормозит). Обычно таких плагинов 1-2, после их отключения и/или впиливания кеширования конкретно в них всё работает.
3. Конкретный плагин который кладёт БД. Смотрим запросы в mysql -e 'show full processlist', проставляем индексы ну или запиливаем кеш где логически возможно.
4. Если ни одно из вышеперечисленных, убеждаемся что машине тупо не хватает процессора, добавляем немного ядер и спокойно изучаем проблему более детально.
Эти 4 пункта покрывают 99% случаев. Остальной 1% это самое интересное и выходит за рамки этого комментария.
Когда работал в хостинге решал такие проблемы десятки раз, на потоке диагностика занимала 5-10 минут. И что WP, что битрикс, что друпал всё одно примерно и проблемы одинаковые.
Честно говоря, это всё общетехнические методы, которые мне постоянно помогали и не только в php-приложениях.
PS шаг 0. Смотрим на htop и понимаем чем конкретно занимается машина и чего ждёт вообще.
Премию за сроки получает производство (применительно к ИТ — разработчики), а риски за эту скорость (скрытые дефекты) несёт эксплуатация у которой обычно никаких премий нет.
Просто из того, что эксплуатация это обычно операционные издержки с фиксированным бюджетом, а производство — нет (и тут может быть «недорасход бюджета»).
При этом у меня есть пример (это история не из ИТ) такая ситуация регулярно приводила к натуральному мордобою, когда премии уже распланированы, иногда даже потрачены, а приёмка изделия в эксплуатацию невозможна из-за наличия в изделии дефектов (ну или же полного отсутствия изделия как такового).
Судя по всему, эта проблема растёт из того, что следующая /23 действительно относится к этому некорректному региону.
Такое впечатление что там вообще никто ничего последнее время не тестирует.
Причем юз-кейс стандартный. Платил себе платёж, и тут понял что упёрся в настроенный лимит на операции в ИБ. И у меня реально нет способа в отдельном окне открыть управление лимитами. Только в этом же, потеряв все заполненные реквизиты.
После того как на среднюю кнопку ИБ отреагировал сбросом реквизитов, я решил послать это всё нафиг и заплатить через яд.
Смотря на это всё, это худшая реклама инструмента. Не в смысле что инструмент плохой, а контекст.
Дамп зоны (как и whois) вполне легально раздаётся регистраторами своим клиентам. Правда, мне для этого потребовалось подписать несколько допников к договору (о том что я обязуюсь никому не передавать их).
Аналогично раздаются дампы .org (выдаётся по бумажному письму в pir.org) и некоторых других…
Осень слабый антифрод и отсутивие 3d-secure / vbv(нет и не планируется).
Собственно, у меня всё. Если сервис не умеет критисные вещи, какая разница какое у него API.
Все 2016.1+ при непонятных условиях(нет background tasks и чего-то подобного, отключены все плагины, IDE просто открыта) начинают просто съедать процессор. Помучился помучился и откатился на 9-10 версии.
Честно говоря, со стабильностью уже примерно год от версии к версии то появляются то исчезают подобные чудеса. Хочется уже найти стабильную fallback версию и остаться на ней и параллельно смотреть альтернативы…
Жесткий диске этого «хостинга» случайно не был отформатирован сотрудниками ДЦ при установке в наш сервер. Почерпнул много интересного в ходе изучения остатков его файловой системы.
Ссылок на источник нет, так что прошу проверить может не 12V, а обычные для US 120V?
Хотя если тут нолик потеряли, может и не 48, а 480?
Логически понижение напряжения понятно (проще понижать на вводе в стойку/ДЦ, а не в сервер), но всё равно прошу проверить.