- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Прошу сильно тряпками не кидать, признаюсь, в этих вопросах пока не очень понимаю, поэтому буду благодарен за подробные ответы.
Есть мобильное приложение и к нему сервер, к которому это мобильное приложение постоянно обращается (передача данных двусторонняя, т.е. приложение передает на сервер информацию, которая сохраняется в базу и получает с сервера информацию - селекты из базы). Скрипты на сервере все написаны на PHP, база данных используется MySQL.
Сейчас это всё хозяйство размещается на обычном серваке (Intel Xeon E3-1270 3.40 GHz 4ядра/8потоков, 8Гб оперативки, Debian-7.0-x86_64-minimal), но долго это продолжаться не сможет, т.к. нагрузка будет расти (будет расти количество одновременных запросов). Надо как-то это дело развивать.
В связи с этим вопрос, что лучше, накупить отдельных серваков, сделать балансировщик нагрузки на nginx, базу данных реплицировать на все сервера и жить спокойно, или же есть какие-то современные решения? Например облако? Я просто пока не совсем понимаю принцип работы облака...
Возможно так, чтобы при увеличении нагрузки ресурсы автоматически расширялись и потом после спада нагрузки так же автоматически уменьшались?
Ну и с базой данных как в облаке. Она, я так понял, одна. А если в пик нагрузки к ней количество запросов возрастает, есть ли какой-то лимит? Или в облаке тоже надо создавать несколько слэйвов базы?
В общем, помогите правильно подобрать решение. Пока нагрузка маленькая, справляется один сервер, но она плавно растет изо дня в день в связи с увеличением числа пользователей.
> Debian-7.0-x86_64-minimal
Поддержка - законилась (End of life).
https://wiki.debian.org/LTS
Купите два сервера с новым процессором (от 8 ядер/ 16 потоков).
Первый для nginx, php. Второй - mysql (ssd диски). Соедините в локальную сеть.
Если растет нагрузка на базу - сначала стоит смотреть в сторону оптимизации (настройка mysql, анализ статистики/ запросов, кеширование).
Посмотрите в сторону http://jelastic.cloud/ или иных облачных решений.
Из того, что вы описали предоставляет mirhosting.com
Но скорее всего в вашем случае лучше взять просто помощнее сервер и так в итоге выйдет дешевле.
Несколько серверов объединять в кластер и делать что-то наподобии своего облака нужно, наверное, если проект с более серьезной нагрузкой. Сервер у вас сейчас реально слабый, по современным меркам, не стесняйтесь брать с большим запасом ресурсов.
У нас для таких проектов предоставляется IaaS . Если нагрузка не растет скачками за день - то в самый раз. Берем сначала ресурсов сколько надо и добавляем по мере роста. Внутри логически можно организовать любую архитектуру, один, два или группу серверов. Все они связываются внутри по 10Gbit. В мир облако смотри через NAT. Управляется через VMware Vcloud Director.
mClouds, а если нагрузка "рваная"? Вот пришел пуш в приложение всем пользователям, они его открыли - приложение у всех пошло на сервер за информацией, скачок в нагрузке. Пользователи новости прочитали и дальше "притихли" до следующего пуша. Т.е. нагрузка будет волнами.
с учетом какой у вас сервер сейчас.. мне кажется вам стоит взять какой нибудь Е5 двух процессорный с 10-14 ядер на каждом cpu (40-48 потоков на сервер) и ssd накопителями и забыть о проблеме расширения на долгое время.
с учетом какой у вас сервер сейчас.. мне кажется вам стоит взять какой нибудь Е5 двух процессорный с 10-14 ядер на каждом cpu (40-48 потоков на сервер) и ssd накопителями и забыть о проблеме расширения на долгое время.
Ну вот, скажем, в пик будет 10 000 запросов входящих одновременно. Выдержит это один сервер? Где-то читал, что есть некие ограничения у сетевых карт, что не будет столько запросов проходить за раз (более подробно не могу объяснить, речь была о каких-то прерываниях).
Ну вот, скажем, в пик будет 10 000 запросов входящих одновременно. Выдержит это один сервер? Где-то читал, что есть некие ограничения у сетевых карт, что не будет столько запросов проходить за раз (более подробно не могу объяснить, речь была о каких-то прерываниях).
это очень мало. у нас на намного более слабых серверах по 180-200 тысяч Tcp коннектов.
и сетевые карты есть разные, посмотрите разброс цен. Вам нужен сервер с сетевыми минимум intel 82576(8 очередей на прием и 8 на отправку) а лучше intel 82599 (63 очереди на прием и столько же на отправку)
е3 - сервера начального уровня, в них вендоры как правило ставят однопоточные сетевые.
если у вас при конфиге "Intel Xeon E3-1270 3.40 GHz 4ядра/8потоков, 8Гб оперативки" - уже есть какие то подозрения и Вы пишите что долго так продолжаться не будет, то самое первое, что нужно делать, убрать php и скорее всего mysql.
Как пример можете попробовать посмотреть в сторону такой связки например:
https://vertx.io/docs/#microservices + докер + aws, тогда добавить железок можно будет 2 кликами
Ну вот, скажем, в пик будет 10 000 запросов входящих одновременно. Выдержит это один сервер?
mysql это не выдрежит
во первых ТС говорит о 10к коннектов к веб части а не к БД, к БД столько конечно же не будет.
Во вторых скорее загнется php составляющая чем mysql (а еще точнее mariaDB)