Yoda

Что мне ещё нужно сделать? Кстати смею заметить, мой пост был адресован не вам. А также не услышал вашего ответа на мое предложение. Давайте дальше либо конкретику и подтвердите ваши высказывания действием, либо не засоряейте эфир.

https://github.com/ocStore/ocStore/blob/ocstore-3-0-2-0/upload/system/library/seopro.php Мне мерещится? А считаете вы проблемой, то что при отсутствии уникализации ссылки бот может зайти на порядок большее количество страниц, вызвав излишнюю нагрузку на ресурс. А также значительно реже будет ходить на качественные страницы, занимаясь холостой работой, тем самым снижая скорость индексации?

Не смешите пожалуйста. Я понимаю, что мощь отзывов на сторонних ресурсах давит на грудь. Но к делу отношения это все не имеет. Хотите можем поспорить на приличную денежную сумму, что мои рекомендации решат проблемы топик стартера и лишат его пустых финансовых потерь на оплату специалистов с отзывами на сторонних ресурсах.

Не увидел в постах специалистов нормальной экспертизы ситуации. К сожалению. Отзывы видимо пишут сами себе. Ваша проблема очень простая попросите саппорт перевести режим работы php-fpm в ondemand и сделать swap 2gb. А также снизьте размер памяти на поток php до 128мб. На этом ваши проблемы закончатся. Все эти манипуляции может выполнить любой специалист саппорта хостинга. Также не лишним будет выключить и убрать из автозагрузки демон Apache. Слушать советы советчиков, которые только что их нагуглили в stack overflow себе дороже.

Подскажите а в чем именно проблема? Собираюсь делать магазин, тоже задался вопросом выбора версии.

Memcache - зло. Так как очень любит в самый ненужный момент падать, и сбрасывает все данные при перезагрузке демона/сервера. Лучше уже в базу.

Что вы этим хотели сказать? Я не совсем понимаю.

@chukcha, @SooR, @nikifalex, спасибо за обсуждение. На самом деле. Если бы на прошлой неделе мне трижды на разных проектах не пришлось настраивать экстремально длинные сесии, я бы в жизни не догадался куда копать. Все оказалось до боли просто. В mod-tmp обнаружились полсотни тысяч дескрипторов, которые при gc_divisor 1000 где то раз в 250 посещений проходил garbage collector. Хоть и быстрый VPS, винт общий и виртуализацию никуда не деть, даже скан подобного набора фалов - это ад. Вобщем по итогу все решилось сменой хранилища. В целом это очень показательная история, когда можно все знать, иметь быстрый магазин но уперется в банальную архитектурную проблему операционной системы и искать проблему месяцами, виня во всем техподдержку хостинга и разрботчиков вместе с Линусом Торвальдом за компанию.

Самое главное react и vuejs. Ваш этот опыпнкорд устарел и работае только с ябаскрибтом.

Актуально для ситуаций, когда есть линейная зависимость. У нас рандомные фризы.

Внешних запросов а основных потоках нет. Все расчеты доставок реализованы выделенными потоками. В свое время очень много этим вопросам было уделено внимания. Яндекс почты нет. Почта на сервере ходит как пулемет. Айпи спам базах не замечен. Не понял. Если честно.

Вопрос для специалистов. Есть магазин 80 000 товаров. 3500 посетителей в день. 3-5 глубина просмотра. порядка 20-30к посещений ботов в сутки. Время генерации страниц без каких-то левых модулей кеширования, "на холодную" в рамках 100-300мс. Нагрузка на сервере на процессор в пределах допустимого, пик не более 30%. Расход памяти в пик до 70%. Медленных запросов в базу - 0. Поиск реализован на sphinx - тоже нагрузки создавать не может. Потенциальные дыры для ддоса закрыты. Настроено даже ограничение на всплески посещений с одного айпи средствами nginx. Кеш в redis. В рабочее время нет никаких кронов, генераций фидов и чего-либо еще что может создавать всплески нагрузки. При этом регулярно, а особенно в моменты когда покупатели активно добавляют корзины/оформляют заказы, либо менеджеры залогиненные в админке работают с обработкой заказов наблюдаются нелинейные фризы на 7-10 секунд. В ночное время, когда нет активности покуапетелей, подобные зависания практически отсутсвуют. Еще раз подчеркну - медленных запросов нет. Тоесть ни к базе ни к серверу, ни к настройкам окружения нет претензий. Что бы вы делали в этой ситуации?

2800 это очень мало. Вам скорее всего надо ещё паразитных ботов отбить. И правильную индексацию настроить.

Я не это имел ввиду. То что за сервером надо чтобы было кому присмотреть это неоспоримый факт. Я о другом. О возможностях.

Не верить в сказки про "я таким не занимаюсь" и это не я положил вам бекдор. Это на 300% удар в удар ситуация, которую я описывал пару месяцев назад. Источником подобной ситуации может быть а) платный модуль, взятый на просторах интернета типа бесплатно. б) пароли типа admin admin в) протечка на хостинге, когда взломали не вас, а весь сервер хостера г) протечка на соседнем сайте, если у вас есть какой нить wordpress или Joomla/ д) недобросовестные авторы платных дополнений е) определенное стечение обстоятельств, которое позволяет получить доступ к базе данных магазина. Пытаться выяснять откуда что и как - бесполезно. Платить деньги вымогателю, тоже бесполезно. Нужно не реагировать. По идее, если это схожая ситуация, с которой мы сталкивались, сейчас начнется нытье и сбивание цены, до "дайте хоть что нибудь". За то время пока упырь будет ныть и слать вам гневные письма с заувалированными угрозами, необходимо сменить окружение (хостинг) и перенести магазин в заведомо безопасное окружение с максимально закрытыми возможностями для атак. Ну и поставить логгирование post-get запросов к серверу, для того чтобы попытаться понять, что же такого интересного он у вас нашел. Попробуйте потыкать @spectre - если он свободен может возьмется вам помочь.

Очень много слов не по делу. Ваше мнение про то где вы стояли, оставляйте при себе, оно здесь ни к чему. По факту уязвимость от админера ровно такая же как у незакрытой админки, открытого 22 порта, включенного фтп и активированного вывода ошибок. Открытых phpmyadmin в мир на доброй половине хостингов и так далее. Если бы речь шла о том что к многих лежит backup.zip в корне, db.sql info.php. Я бы поддержал. А так... Это сотрясение воздуха.

Завидуйте молча!

Да ладно, давайте я вам дам тестовый проект и админер. Ну и подожду лет десять пока вы его взломаете. Что за бред?

Слушайте, ну это же был оксюморон. Я с уважением отношусь к @maksilo1401, и его попыткам оттянуть аудиторию у коммьюнити. Но надо же смотреть на вещи реально.

Извините, Артем, я не понимаю ваших намеков, не могли бы вы объяснить внятнее. О чем вы сейчас.

даже 8 символов. Сколько у нас доступных значений? Сколько у нас вероятных символов? Сколько серверов живет под ISP у которых phpmyadmin открыто и никикаких проблем? Правда, поучите матчасть. Это немножко сложнее, чем быть невнятным модером в свою пользу. Но в конце концов вы получите результат, и узнаете что вам лично нужно делать, прежде чем что-то подобное советовать другим! Спасибо!

Банально, Артем не знаком с теорией вероятности. Как правило логин и пароль в базу минимум 10 символов. Даже 20в256 степени подобрать перебором невозможно. И даже если у нас только символы и цифры и большие маленькие буквы - это на три года большой хеш ферме. А еще раньше сервер будет плакать от подобного брутфорса, что будет видно в логах и это бесполезная тема! Все остальное домыслы. Артем, может стоит поучить математику ?

Друзья, набрел вот на такой глупый текст: И у меня возник ряд вопросов.... 1. Непонятно кто его написал и перед кем нести ответственность, в тексте нет реквизитов автора. Аж ни одного. А даже если появится. Ник на форуме - это что? Это человек, физическое лицо, юридическое лицо? Перед кем если что вдруг нести ответственность. 2. Любая подобная оферта. Коим является подобный текст, ну по крайней мере он похож. Кроме ответсвенности контрагентов. Подразумевает ответсвенность третьих лиц. И просто предположим. Что я купил подобное дополнение. И выложил его публично для независимого pen-testа. Скажем меня очень волнует, что там может быть под кубом. Что в принципе может быть уязвимого в этом дополнении. 3. С чего это вдруг авторы, которые даже не удосужились представиться, не несут ответсвенности. Они ставят себя выше УК? Это почему? Во первых у меня создается впечатление, что подобный текст заведомо вводит пользователей в заблуждение вот в этом пункте про ответственность. Во вторых, мне очень интересно, какая может быть моя ответсвенность и перед кем, если я выложу в свободном доступе подобное дополнение для публичного pen-test. А также. Если вдруг в мои руки попадут раскодированные скрипты из под ioncube, являются ли они предметом авторского права или чего-то еще, или они не соответсвуют код дополнения и это будет мой авторский код, на который я полноценно могу оформить авторские права? Прошу не разводить хайп и срач. А отвечать конструктивно. Если вам нечего сказать по теме, пожалуйста воздержитесь.

Любить Варез ещё больше.

Это не значит) что VPS не нужен. Я уже несколько раз описывал ситуацию. В чем разница между хорошим шаред и VPS. на шареде вы стоите на водопой в очереди. А VPS - это ваш личный колодец. Плохонький с виртуализацией. Но колодец. Просто если вы переехали и захостились как есть. Вы получаете такое же окружение как на шареде. Но чуток стабильней. Но есть возможность поставить MariaDB 10 или Mysql 8. Включить Nginx+php-fpm. (иногда +300-400мс прироста, когда нет проблем с кешем и базой) Заюзать jpegoptim и optipng без модулей. В два счета наставить любые необходимые допы и тонкие настройки для PHP. (иногда +200-300мс прироста и стабильность, когда нет проблем с кешем и базой) Добавить ресурсы для Opcache. (добаляет стабильности при выполнениии скриптов нет дерганий то секунда то полторы) Если нужны долгие сессии или большое количество файлов кеша заюзать Redis. Про сфинксы эластики я молчу. И это неполный список того что можно использовать исключительно в качестве серверных тюнячек, без оптимизиации кода и базы данных. Но если возвращаться к любым клаудам. Поверх KVM или OpenVZ виртуализации, поверх hyperThreading, который тоже очень сильно отжирает производительность процессора, добавляется еще лаг на синхронизации данных на диске, а это особенность файловой системы, которую используют облачные сервисы. И тут начинаются проблемы уже от 1000-2000 файлов в папке. И это печаль.