Какое железо брать по python?

xmoonlight, о том и речь)

Какое железо брать по python?

Да, как обычно, небось: взяли django, запилили сайт, забыли сделать select_related и prefetch_related, индексов в базе вообще нет, забыли про кеш. Все тормозит - значит, конечно, Питон медленный.

Нужно ли закрывать от индексации страницы без поискового спроса?

А почему нельзя эти страницы привести в порядок, чтобы получить и на них траф?

Как спроектировать БД для доски объявлений?

fmx500, по сериализованному массиву сложно организовать поиск (по json - тоже достаточно неудобно), а если свойства в отдельной таблице, можно, например, предлагать юзеру объявления, у которых значение какого-то свойства совпадает со значением свойства просматриваемого объявления - достаточно простой sql-запрос.

Как понять, почему сервер иногда долго отдает сайт?

freeeeez, в общем, есть вариант еще такой. Напиши скрипт, который будет запускаться кроном раз в 5 минут (например) и дергать какие-то урлы твоего сайта - и понаблюдай, сколько по времени он отвечает, в какие моменты подвисает и т.п. Можно даже несколько скриптов сделать: один будет страницы сайта дергать, а второй будет ходить в базу и делать запрос select 1 (например).

Как понять, почему сервер иногда долго отдает сайт?

freeeeez, вообще это все похоже на проблемы с сетью. А в логах Nginx и MariaDB нет ничего подозрительного?

Как понять, почему сервер иногда долго отдает сайт?

freeeeez, сделай логирование. Можешь фиксировать время, когда пришел запрос и время, когда сформировался ответ, вычитать из второго первое - и, если получилось более 30 секунд, писать в логи. Это чтобы все подряд не писать. Фиксируй по шагам, в какое время что происходило - тогда локализуешь проблему..

Как понять, почему сервер иногда долго отдает сайт?

freeeeez, не обязательно. Результат медленного запроса может писаться на час-полтора в кеш. Поэтому через час-полтора его результата в кеше уже нет - и делается вновь медленный запрос к базе.

Как понять, почему сервер иногда долго отдает сайт?

freeeeez,

1. Может тогда с сетью проблемы?
   
2. А кеш используется?
   

Как ускорить работу с API?

Вопросы, случаем, не через order by rand вытаскиваются из базы?

Как правильно интегрировать API mailgun в PHP?

Сергей Витринов, такое предупреждение возникает, когда расширения mbstring не хватает, если не ошибаюсь.

Хорошо ли хранить serialize в БД?

Barmunk, а разве в случае "один ко многим" целостность как-то гарантируется в такой ситуации? Ничего не мешает в таблице с параметрами указать не все. Уровень вложенности более одного так тоже хранить особо не получится.

Да и при этом как использовать нормально limit и offset, если мне нужно получить список сущностей с их параметрами? Можно, конечно, делать 2 запроса: первый к таблице сущностей (с лимитом и оффсетом), потом взять их id и вторым запросом к базе через IN (список id сущностей) вытащить и их параметры, после чего на уровне кода все связать - но так ли уж это удобно? И как быть, если вложенность большая?

Хорошо ли хранить serialize в БД?

stilic, да нет, совершенно нормальная практика решать, как обрабатывать данные и в каком виде хранить в своей же базе данных. Данные приходят в ваш сервис, ваш же сервис их пишет в вашу же базу. Вполне логично их как-либо обрабатывать для дальнейшего использования. Так можно и внешние ключи в базе не использовать - какая разница, какой id туда будут вписывать.

В общем, не вижу смысла спорить особо. Все равно каждый из нас останется при своем мнении, как я понимаю. Главное, что хранить данные в json, а не в php-шной сериализации. Вопрос изначально в этом ведь и заключался.

Хорошо ли хранить serialize в БД?

stilic

Тогда будет проверяться синтаксис JSON, а это не всегда надо. Исходные данные могут не строго стандарту соответствовать - намучаетесь. Знаем, проходили.

И это хорошо, в базе надо корректные данные держать потому что. Впервые слышу, если честно, чтобы json кто-то хранил не по стандарту. По крайней мере, за 10 лет разработки с таким не сталкивался ни разу. Такой json может же даже не декодироваться нормально, если не соответствует стандарту - и как его потом использовать? В таком случае, конечно, можно строкой хранить, но, честно говоря, появление таких вещей говорит о серьезных проблемах в проекте. Наверняка можно (да и нужно) исходные данные обрабатывать и превращать в валидный нормальный json.

Хорошо ли хранить serialize в БД?

stilic, ок, тогда не JSONB, а просто JSON (я изначально, кстати, про JSONB, вроде, даже и не писал).

Хорошо ли хранить serialize в БД?

Это позволяет получать нужную информацию одним запростом и обрабатывать миллионы срок без потери производительности. Что в миллион раз важнее лени "создавать дополнительную таблицу"

А насколько ты уверен, что получить нужные данные из таблицы, а потом декодировать значение json-филда в плане производительности хуже, чем операция join? Напомню, что данные, которые в json-поле хранят, обычно могут быть не только абсолютно разные для каждой записи, но и иметь древовидную структуру, которая у разных записей различна в плане глубины вложенности. Как ты собрался это решать дополнительными таблицами, сколько их будет и будет ли это работать быстрее?

Хорошо ли хранить serialize в БД?

stilic, насчет "автоматически" - чего-то не уверен. Спорить не буду - не знаю (вроде бы, gin-индекс для jsonb надо отдельно вручную вешать). Но в любом случае ничего не мешает использовать тип JSON вместо JSONB. Это куда правильнее, чем хранить php-сериализацию в базе.

Хорошо ли хранить serialize в БД?

FanatPHP, как бы там ни было, мой ответ полностью отвечает на поставленный вопрос: "нормальная ли это практика, стоит ли так делать и почему?".

Как избавиться от такого дублирования кода?

NubasLol, зато какова вероятность того, что ты в php коде забудешь поймать и обработать то или иное исключение? В гошке это ж сделать явно сложнее.

Как не запускать PHP код, если на сайт зашел бот?

Роман Вопроскин, три с половиной строки кода же) Куда уж легче-то...

use Jaybizzle\CrawlerDetect\CrawlerDetect;

$CrawlerDetect = new CrawlerDetect;

if($CrawlerDetect->isCrawler()) {
    // Это бот
}