Не существует универсального ответа. Зависит от специфики задачи, требований к нагрузкам, к безопасности, к ресурсу команды разработки... Опять же, если это уже прекрасно работает, не нужно это "чинить" ради неясной идеи.
В общем и целом - да, это вполне нормально для подавляющего большинства проектов.
mkone112, я привёл пример характеристик процессора, причём целых двух.
Пойми, без пояснения твоих реальных задач и реальных бенчмарков и показателей тебе никто ничего не посоветует, кроме общих объяснений, как бесполезно искать универсальный показатель.
Надо ещё учитывать, что ноутбук - это электроника для обычного потребителя, у которого не стоит задачи получать гарантированный уровень производительности, а просто некий комфорт в среднем при не очень высокой цене. Именно поэтому в "домашних" конфигурациях Linux многие параметры по умолчанию допускают, чтобы система могла слегка уйти в своп, слегка потупить на вводе-выводе итд итп - главное, чтобы можно было сочетать в среднем неплохую производительность или не очень высокое энерготребление (актуально для ноутбуков) с адекватной ценой. Это в кровавом энтерпрайзе 3 секунды небольших тормозов могут считаться аварией, ради избежания которой в сервера ставят огромные объёмы памяти, тысячеядерные процессоры итд итп, на ноутбуке же чуть тупит иногда - ну и ладно...
Вопрос "хорошей" соцсети не зависит от движка или ЯП. "Хорошесть" - это про функционал. Можно написать MVP на чём угодно. Можно даже написать узкую соцсеть для маленького круга лиц (уровня "все 300 туристов-каякеров своей области") на чём угодно.
Если разработка окажется вау, то что ни выберешь на старте, неизбежно придётся всё очень сильно переделывать. Возможно, и язык программирования тоже. Facebook и vk начинали с обычного стека php+mysql.
Виктор Кожухарь, я о том и говорю: инструмент используется тогда, когда чётко понимаешь, что он принесёт пользу, несмотря на свои сопутствующие недостатки. Например, при разработке стандартных сайтиков с простой структурой ORM очень даже удобно использовать, особенно если там мильон полей, которые будут только новые изредко добавляться. Ну и опять же, ORM можно совмещать с REST/CRUD.
Но основное против чего я выступал - это в ошибочном смешивании ORM и php. И на основе негативного отношения к php (скорее всего, больше эмоционального, чем практически осмысленного) отрицается и ORM.
mkone112, нельзя сказать, "сколько не хватает", потому что нельзя точно сказать, как повлияет частота процессора или размер кэша на выполнение конкретной задачи. Да и в чём узкое место тоже не всегда можно понять. Одно дело когда упирается в вычислительную сложность и другое - когда в context switch rate либо в iowait. Нельзя поставить процессор "в два раза лучше", потому что непонятно, как эти "в два раза" посчитать, по каким характеристикам.
mkone112, программа не может котролировать использование диска системой или другими приложениями. Ну запустился там trim без спросу, и что?
Кроме того, load может создаваться вообще чем угодно. Например, сетью. Вполне реально бывает, когда на сетевухе насыпается error rate или broadcast storm и системе становится нехорошо, причём это бывает ещё и сложно понять. Некоторые устройства могут вообще чисто на IRQ создавать нагрузку.
Именно поэтому нет универсального способа понять, где узкое место. Каждый случай уникален.
"Производительность" не бывает в вакууме, она бывает в конкретной задаче. А конкретная задача может сильно разниться. И в разных условиях будет разное поведение.
loadavg - это характеристика, которая, условно, отражает, сколько времени проведено в ожидании. При этом load может отражать загрузку совсем не процессора, а периферии (диски, сеть и другие устройства). Например, вполне жизненная ситуация, когда от диска прилетают hardware timeout, а в системе катастрофически растёт load. Даже если диск этот - raid в зеркале: пока система не догадается отстрелить проблемный диск и остаться на половинке зеркала, load будет высоким, всё будет тормозить. А это зачастую может занять далеко не одну минуту. Другой вариант: если на диске включена опция discard, то в моменты фонового trim он тоже может создавать внезапную нагрузку.
Ну вот, например, когда система тормозит - можно посмотреть: если в процессах высокое потребление процессора у kswapd или kcompactd, то это значит памяти не хватает и система начала свопаться слишком активно. Это тоже вызовет повышение load, но упираться это будет не в процессор вовсе.
Да, нужно через crs. В leaflet сильно ограничены возможности по работы с проекциями, простота и компактный размер библиотеки имеют обратной стороной ограничения по функциональности.
В качестве альтернативы можно использовать OpenLayers, Maplibre GL, NextGis Frontend.
John Bjornsen,
ORM это не свойство php. ORM это подход к работе с базой, причём даже важнее не то, что ORM позволяет вместо запросов оперировать объектами, а то, что ORM закрывает собой вопрос обслуживания и обновления базы, создания и изменения сущностей, и всё это с довольно небольшим количеством кода. Довольно неплохой подход, во многих языках и фреймворках применяется. Конечно, далеко не серебрянная пуля - иначе бы все переходили на ORM. Но всё же.
miner2100, прыгать с множеством древнийх версий - плохой путь. Лучше собрать новый сервер с нужным софтом, поднять там копию сайта и добиться её полной работоспособности. Потом переключиться.
