Нет смысла переписывать сайт с WordPress на джангу только потому, что у кого-то начал тормозить сайт. Любой блог на WordPress будет достаточно быстрым, если не превращать его в социальную сеть с интернет-магазином, аукционом, погодой и криптовалютной биржей одновременно.
Алгоритм поиска тормозов обычно такой:
- находим место, которое тормозит
- воспроизводим тормоза
- делаем профайлинг, смотрим что именно тормозит
- определяем причину
- лечим
А не такой:
- переписываем на джангу
Тем более, сама по себе джанга достаточно тормозная. Фишка джанги - скорость разработки, а не производительность.
Не смотря на то, что автор уже определился с выбором, там на самом деле ещё бы конфиг MySQL глянуть, потому что если там есть query_cache, он может довольно таки хорошо убивать производительность, если запросы летят в разные части индекса, и есть запросы на вставку.
Я сталкивался с багом, когда на двух почти идентичных VPSках (2 гб, и 1 ядро), с одинаковыми данными, с одинаковыми конфигами, на одной VPS планировщик выбирал эффективный план, а на другой - медленный. Помог логический дамп, и пересоздание базы и таблиц.
длина будет n байт + 1, а не 32 байта.
Нет, достаточно одного запроса, но чтобы планировщик имел статистику по запросам. Т.е., желательно дать рабочую нагрузку на таблицу, а потом профайлинг.
Попробуйте ANALYZE TABLE; сделать, если это не прод, можно так-же попробовать OPTIMIZE TABLE сделать. У вас mysql больше думает над тем, как выполнить запрос, чем над выборкой самих данных. Насколько критично наличие констрейнта на уникальность? Если в вашем стеке уже есть PostgreSQL, и версия 10 или выше, можете попробовать сделать таблицу с полем TEXT, но вместо PRIMARY KEY сделать так:
CREATE INDEX some_index_name ON your_table USING HASH(your_field);
Но тогда не будет уникального констрейнта (возможно появление дублей, если будете просто делать INSERT).
Хеш индексы чуть быстрее будут (должно быть O(1) вместо O(logn), но не уверен что в pg честная константа).---------- Добавлено 28.03.2020 в 12:33 ----------
Memory это ещё более жалкое поделие, чем MyISAM :)
Смена языка может сэкономить деньги на больших проектах, может ускорить разработку, но саму нагрузку держит именно shared-nothing архитектура. То что на нагруженных проектах где-то используют джангу, это не значит, что джангу выбрали потому что она хорошо подходит под нагрузки. Этот выбор был историческим.
PostgreSQL почти всегда быстрее. Просто его нужно уметь готовить.
Я не думаю что там просто так char(32), скорее всего md5 хранят.
Solmyr, если данные в таблицы выбираются только по ключу (т.е. нет range запросов), можете вынести все в Redis. В InnoDB для PK иногда используются adaptive hash index. Чем обусловлен выбор таблицы MyISAM?
А вообще, сделайте пожалуйста
EXPLAIN FORMAT=JSON SELECT ...
и ещё вот это через CLI
SET profiling = 1;SELECT ...-- это ваш запрос, в конце ;SET profiling = 0;SHOW PROFILE FOR QUERY 1;
Вангую что больше всего времени уходит на sending data, но тем не менее.
Покажите ваш сайт, чтобы понимать масштабы катастрофы. Может у вас там скрипты блокируют отрисовку страницы. Или хотя бы Time To First Byte скажите.
Сам по себе Python медленнее PHP, если не использовать всякие транспайлеры PyPy/CPython или JIT/LLVM. На WordPress можно легко просадить производительность, установив кучу мусора, + в базе там хранятся драфты постов, и дизайн таблиц немного убогий.
Не обязательно менять язык, чтобы сайт работал быстро. Нужно искать проблему в самом коде.
Штош.
Посмотрел You. Что-то вроде триллера с элементами романтики. Ощущения от сериала напомнили ощущения от просмотра фильма "Не дыши", главный герой то и дело в шаге от разоблачения. Оценочка 7 из 10. Второй сезон говорят по лучше.
Вышел второй сезон Американский вандал. Первый понравился, второй сделан в том же духе, но про другой случай: обосралипсис. Пока смотрю, оценку поставлю потом.
<!--WEB-->, бога нет.
miketomlin, какую задачу вы решаете? Для чего это все?
