Не утверждаю, что идеально и грамотно, но для себя рецепт выработал такой:
Очень мало клиентов (десятки) и сайтов (несколько сотен максимум) на сервер. Это во-первых низкие нагрузки. Во-вторых можно использовать малоядерные и высокочастотные cpu. Недорогой сервер сильно дешевле апгрейдить или запускать новый, чем 100+ ядерную махину с сотнями гб памяти и терабайтами ssd.
Плюс малая плотность клиентов дает возможность не экономить память, выделять каждому его личные процессы веб-сервера, php и mysql. Получается почти как на vps, но без лишнего оверхеда, без жестких лимитов на количество ядер, память, диск.
Ну и плюс открытость - можно выбирать конкретный сервер, где размещаться. Видеть его характеристики, количество соседей и графики нагрузки.
Очевидно, что такое врядли работоспособно при крупных масштабах. Там все наоборот - лучше поддерживать один мега-сервер вместо целой стойки мелких серверов. Там есть бюджеты на мега-сервер. Там проще сразу всех урезать лимитами, чем вручную решать вопрос с превышающими. Там плевать если кого-то что-то не будет устраивать - толпы других клиентов будут продолжать платить.
Это как спрашивать универсальный/правильный рецепт хлеба/пива/чего-угодно...
Завод делает по своему рецепту, мелкая пекарня по своему. Вероятней всего более вкусно получается у вторых, но это не значит что их рецепт подойдет первым. Т.к. радикально отличаются экономики.
Самое печальное тут - клиенты. Они очень далеки от производства и им плевать на рецепты. Максимум где-то слышали пару названий/брендов и когда нужно, то выбирают их. Будут продолжать покупать что-то низкосортное и считать что это "стандартно". Пытаться донести до них, что может быть сильно лучше за ту же или незначительно выше цену - тяжелая задача. Они твердо уверены, что везде одинаково и поэтому у них выбор только из топ-3, а зачастую даже только топ-1 и больше никого не существует.
Но лишь до тех пор пока случайно (или по принуждению :] ) не попробуют пиво из бочки, свежеиспеченную булку или кофе из только что перемолотых зерен. После этого дороги обратно к бутылированному, пакетированному или растворимому не будет...
десятки тысяч сайтов и пользователей находящихся под управлением одного сервера.
На самом деле такой хостинг очень плохой. Если смотреть с точки зрения клиента, а не владельца.
Очевидно лучше всего ехать на своем авто (или мото, чтоб еще быстрей), но для многих слишком дорого. Потому или автобус, или такси. Но одно дело когда автобус перевозит не больше, чем есть сидячих мест и совсем другое - когда даже войти/выйти в него проблема из-за толпы "соседей".
Причем оплату с тебя требуют еще на улице. Не давая информации что за автобус, сколько его вместимость, как быстро может ехать и уж тем более скрывая сколько уже сейчас перевозится народу.
например нельзя скрыть от пользователя число ядер или название процессора
Вот это желание скрыть явно ничего общего с безопасностью не имеет, а вот о хитросделанности владельца говорит.
Не принято (не у всех, но у 99%) показывать всем загруженность серверов, количество соседей, не давать клиентам самим выбирать сервер где размещаться именно по причине что чаще всего все сильно перегружено и на деле сайты работают не так хорошо как обещалось в рекламе. В рекламе обещают какие-нть 4-5ггц, а на деле ближе к 2ггц т.к. для десятков тысяч сайтов/клиентов нужны очень многоядерные cpu, которые под нагрузкой сильно просаживаются частотами. В рекламе обещают быстрые nvme диски, а на деле получаем забитые под крышку диски (надо ли напоминать о просадке производительности в таком режиме?). Плюс к этому халтура на уровни архитектуры - общие apache/php, общая mysql на все те десятки тысяч сайтов. Какая например капля кэша запросов mysql достанется вашему микро-сайтику? Ведь в следующую же секунду весь кэш перезапишется запросами соседей.
И ведь не обязательно иметь vps, на shared хостинге тоже может быть все организовано хорошо. Без толкучки с соседями, без борьбы за ram-кэши и без падений частот процессора в 2 раза.
но что делать если, предположим возвращаясь, вы приняли на грудь, устроили драку в самолете, из которого вас высадили и принудительно продолжили вам отпуск еще суток на 15, без никаких телефонов и интернетов. у кота есть тревожная кнопка?
Еще не смотрел, но надеюсь оно хоть в инсталляторе спрашивает, мол сделать /tmp в tmpfs и какого размера, или не надо. Сам давно практикую, но только когда все под контролем и точно уверен что можно.
Бывают же ситуации когда к примеру vps с 0.5гб памяти... ну куда там tmpfs еще? Хотя бывало что даже там делал /tmp около 100мб размером. Правда apt upgrade почти гарантированно обломается на пол пути. На такой случай был свой скрипт, который делал на время /tmp обычным, потом apt update/upgrade и в конце снова возвращал в tmpfs.
А еще /var/log полезно делать так же в tmpfs для все той же цели - снизить износ ssd или заметно увеличить общую отзывчивость если hdd используется. Но опять же надо держать под контролем размеры логов и их архивацию/удаление.
А с cookie какая проблема? Ведь были же нормальные люди, жили себе спокойно... А теперь на любой сайт зайдешь и рефлекторно смотришь где закрыть окошко про куки и подобную чепуху.
Однажды тут появится статья с ключевыми словами: госдума, ии, ркн, штраф.
Не утверждаю, что идеально и грамотно, но для себя рецепт выработал такой:
Очень мало клиентов (десятки) и сайтов (несколько сотен максимум) на сервер. Это во-первых низкие нагрузки. Во-вторых можно использовать малоядерные и высокочастотные cpu. Недорогой сервер сильно дешевле апгрейдить или запускать новый, чем 100+ ядерную махину с сотнями гб памяти и терабайтами ssd.
Плюс малая плотность клиентов дает возможность не экономить память, выделять каждому его личные процессы веб-сервера, php и mysql. Получается почти как на vps, но без лишнего оверхеда, без жестких лимитов на количество ядер, память, диск.
Ну и плюс открытость - можно выбирать конкретный сервер, где размещаться. Видеть его характеристики, количество соседей и графики нагрузки.
Очевидно, что такое врядли работоспособно при крупных масштабах. Там все наоборот - лучше поддерживать один мега-сервер вместо целой стойки мелких серверов. Там есть бюджеты на мега-сервер. Там проще сразу всех урезать лимитами, чем вручную решать вопрос с превышающими. Там плевать если кого-то что-то не будет устраивать - толпы других клиентов будут продолжать платить.
Это как спрашивать универсальный/правильный рецепт хлеба/пива/чего-угодно...
Завод делает по своему рецепту, мелкая пекарня по своему. Вероятней всего более вкусно получается у вторых, но это не значит что их рецепт подойдет первым. Т.к. радикально отличаются экономики.
Самое печальное тут - клиенты. Они очень далеки от производства и им плевать на рецепты. Максимум где-то слышали пару названий/брендов и когда нужно, то выбирают их. Будут продолжать покупать что-то низкосортное и считать что это "стандартно". Пытаться донести до них, что может быть сильно лучше за ту же или незначительно выше цену - тяжелая задача. Они твердо уверены, что везде одинаково и поэтому у них выбор только из топ-3, а зачастую даже только топ-1 и больше никого не существует.
Но лишь до тех пор пока случайно (или по принуждению :] ) не попробуют пиво из бочки, свежеиспеченную булку или кофе из только что перемолотых зерен. После этого дороги обратно к бутылированному, пакетированному или растворимому не будет...
а это сбор персданных?
На самом деле такой хостинг очень плохой. Если смотреть с точки зрения клиента, а не владельца.
Очевидно лучше всего ехать на своем авто (или мото, чтоб еще быстрей), но для многих слишком дорого. Потому или автобус, или такси. Но одно дело когда автобус перевозит не больше, чем есть сидячих мест и совсем другое - когда даже войти/выйти в него проблема из-за толпы "соседей".
Причем оплату с тебя требуют еще на улице. Не давая информации что за автобус, сколько его вместимость, как быстро может ехать и уж тем более скрывая сколько уже сейчас перевозится народу.
Вот это желание скрыть явно ничего общего с безопасностью не имеет, а вот о хитросделанности владельца говорит.
Не принято (не у всех, но у 99%) показывать всем загруженность серверов, количество соседей, не давать клиентам самим выбирать сервер где размещаться именно по причине что чаще всего все сильно перегружено и на деле сайты работают не так хорошо как обещалось в рекламе. В рекламе обещают какие-нть 4-5ггц, а на деле ближе к 2ггц т.к. для десятков тысяч сайтов/клиентов нужны очень многоядерные cpu, которые под нагрузкой сильно просаживаются частотами. В рекламе обещают быстрые nvme диски, а на деле получаем забитые под крышку диски (надо ли напоминать о просадке производительности в таком режиме?). Плюс к этому халтура на уровни архитектуры - общие apache/php, общая mysql на все те десятки тысяч сайтов. Какая например капля кэша запросов mysql достанется вашему микро-сайтику? Ведь в следующую же секунду весь кэш перезапишется запросами соседей.
И ведь не обязательно иметь vps, на shared хостинге тоже может быть все организовано хорошо. Без толкучки с соседями, без борьбы за ram-кэши и без падений частот процессора в 2 раза.
а кто не продляет подписку - фото получившейся мебели
А справа некий мессенджер... но он пока не придумал как в эту схему себя вклинить тоже
Тем временем в другом мессенджере: это не баг, а фича.
идите в бизнес (с)
Помню времена, когда видео для сайта прямо на сайте и размещалось.
Смотря конечно какие объемы, но чаще лучше именно так и делать. Не заставлять посетителей своих смотреть как зомби рекламу всякого 💩
жесть... а как это в топе оказалось тогда. теперь увидел, что 24й год
А ничего, что у них тоже есть с 5.7ghz? Только не 7950x а даже новей 9950x.
С каких соображений был выбран менее быстрый 12900k, чтоб потом в результате заявить, что у другого быстрей :-?
И я уж молчу, что у 12900k есть быстрые и медленные ядра. На которое ядро вас хоть поселили, что там были за частоты?
видимо брат вас не любит, раз вместо того чтоб выручать вас, он будет котом заниматься.
есть мнение, что это кошка...
но что делать если, предположим возвращаясь, вы приняли на грудь, устроили драку в самолете, из которого вас высадили и принудительно продолжили вам отпуск еще суток на 15, без никаких телефонов и интернетов. у кота есть тревожная кнопка?
Нельзя. Иначе по какому поводу еще столько всего запрещать дальше? Или, что ужаснее, разрешать ранее запрещенное...
Еще не смотрел, но надеюсь оно хоть в инсталляторе спрашивает, мол сделать /tmp в tmpfs и какого размера, или не надо. Сам давно практикую, но только когда все под контролем и точно уверен что можно.
Бывают же ситуации когда к примеру vps с 0.5гб памяти... ну куда там tmpfs еще? Хотя бывало что даже там делал /tmp около 100мб размером. Правда apt upgrade почти гарантированно обломается на пол пути. На такой случай был свой скрипт, который делал на время /tmp обычным, потом apt update/upgrade и в конце снова возвращал в tmpfs.
А еще /var/log полезно делать так же в tmpfs для все той же цели - снизить износ ssd или заметно увеличить общую отзывчивость если hdd используется. Но опять же надо держать под контролем размеры логов и их архивацию/удаление.
Даже если у кого-то и нет, то не значит что не будут именно у вас.
На 12 помнится переходил к версии 12.2 или типа того. Так и тут не торопился б до пары след. обновлений.
Это получается и Михалкову в ВК такие вопросы приходят про ваши фотки...
А с cookie какая проблема? Ведь были же нормальные люди, жили себе спокойно... А теперь на любой сайт зайдешь и рефлекторно смотришь где закрыть окошко про куки и подобную чепуху.
Однажды тут появится статья с ключевыми словами: госдума, ии, ркн, штраф.
Запомните этот твит (с)
Нужно на лампах и свинцовой акб.