German Jet

Изучил весь httpd.conf, перекопал кучу гайдов по highload (они старые и с сомнительными советами типа "отключить лишние модули"

Один из первых модулей, который стоит отключить у Apache'а, для скорости - это поддержку файлов .htaccess, сама эта поддержка производительности не добавляет, а наличие этих файлов - уж и подавно.

1) Это у всех VPS так называемый "мощный" процессор медленнее, чем на каком-то жалком хостинге, пусть и с VIP-тарифом?

Нет, возможно это у Вас, персонально, какой-то дрянной VPS-хостер, или того хуже, тариф аки "OpenVZ, мы не перепродаём проданные ресурсы... ну разве что раз 10, но больше не перепродаём"

2) Поможет ли в такой ситуации FastCGI?

FastCGI - это режим работы PHP, напрямую, на производительность в значительной степени он не влияет, более того, сама логика работы FCGI (если сравнивать Apache-FCGI и Apache-mod_php) будет медленнее, по тому как для взаимодействия FastCGI будет использоваться сокет ("обычный" или unix-сокет), что подразумевает сетевое взаимодействие, вместо непосредственной работы интерпретатора PHP "внутри" сервера. Думаю, Вам поможет несколько другое (постараюсь описать ниже).

3) Почему не популярны фишки типа eAccelerator (кеширование AST и т.п.)?

Понятия не имею, почему они не популярны и откуда у Вас такая статистика... Но, возможно, дело в том, что eAccelerator морально и физически устарел, и если верить например, вот такой банальной статье (нет, я не работаю с такой "шедевральной" CMS как "Битрикс", просто это первое упоминание про eAccelerator, которое пришло мне в голову) - с версиями PHP выше 5.3 не работает.

Я знаю, что многие из них заброшены, но это не причина, а следствие.

Не могу прокомментировать это, так как Вы не указали следствие - чего именно. Другими словами, я не совсем понимаю, что Вы хотели этим сказать.

4) Что еще может помочь?

Ну так, сходу, по памяти (варианты могут быть не связаны между собой):
1. Отказ от поддержки .htaccess в Apache или хотя бы сокращение их количества
2. Установка Nginx в качестве фронтального сервера, для отдачи статики
3. Полный отказ от Apache вообще и переход на Nginx+FCGI (только не подумайте, я очень люблю Apache за его гибкость в настройке и широкие возможности, другой вопрос, что мало кому эта гибкость фактически нужна и мало кто способен его грамотно, качественно и полноценно настроить... Nginx в этом плане будет куда попроще). Почему FCGI? По тому, что другой приемлемый способ взаимодействия Nginx'а с PHP мне не известен. Настройка FCGI-пула - обязательна.
4. OpCache - с версии 5.5 встроено "искаропки", к включению и настройке - настоятельно рекомендуется. Я не знаю, как обстоят дела с CMS и используете ли Вы CMS на сайте, но из моей практики, скорость работы PHP-фреймворков возрастает в среднем 8-20 раз.
5. HHVM, как альтернатива
6. Проверка:
а) Того, что дело действительно в PHP. В частности, стоит собрать все логи сервера, например, сколько длились запросы, в БД, их количество и так далее.
б) Проверка скорости работы дисковой подсистемы... Не буду "тыкать пальцем", но одно время я арендовал довольно большое кол-во VPS'ок у одного популярного хостера, и в какой-то момент, я заметил, что средняя скорость работы дисковой подсистемы - 1.4Кбайт/сек., при этом "отказы" (аки "невозможно записать блок") были примерно в 50% случаев... это продлилось не очень долго, но и через несколько месяцев, у этого же хостера, тарифы с "обычным HDD", почему-то обладали более быстрой дисковой подсистемой, нежели тарифы с "быстрыми SSD"... можно сделать выводы...
в) Проверить реальную скорость работы процессора, не редко она отличается от завяленной достаточно сильно.

P.S. Если Вы сформулируете вопрос(ы) более точно - я смогу дать более точные рекомендации, если конечно они Вам нужны :)

P.P.S. Есть вариант решения проблемы вообще "в лоб", самый наверное сложный и пожалуй самый производительный в ряде случаев. Это Varnish + тонкая настройка оного, позволяет выдавать большую часть страниц из кэша (оперативной памяти) за наносекунды, иногда позволяет обслуживать очень много тысяч запросов в минуту, при этом, это не просто кэширование кода или что-то подобное... это кэширование целиком страниц и/или ответов сервера. Среди прочего - позволяет "не трогать бэкенд вообще", т.е. при запросе страницы, может не быть ни обращений к БД, ни выполнения того же PHP (или любого другого) кода, на стороне сервера. Требует довольно тонкой настройки, не очень подходит для сайтов "на CMS", для сайтов на фреймворках - требует изначально корректного подхода к разработке и продумывания того, что и как будет/должно кэшироваться. При некорректном подходе - наиболее вероятный результат - работать будет, но не так быстро как хотелось бы, а часть сайта вообще может перестать нормально функционировать. Есть так же другие решения, но с учётом довольно общих формулировок вопроса - говорить о них довольно сложно.

Ах, да, забыл важную деталь... Почему "хостинги" используют Apache и не откажутся от него (совсем)? В большей степени по тому, что Apache позволяет делегировать часть настроек пользователю через .htaccess. При этом, для статики не редко стоит всё тот же Nginx, который, как Вы понимаете, подобным образом делегировать часть настроек пользователю не позволяет, в виду чего для этих задач не подходит и не "буксует" на этом (в отличии от Apache'а). В т.ч. и по этому, мы на 99% отказались от "хостингов" (по причине наличие Apache'а, и невозможности от него избавиться или самостоятельно настроить, и как следствие "тормозов" которые приходят вместе с подобным подходом).

>

MikroTik-CRS125-24G-1S-RM

Не надо использовать Switch как роутер. Тем более слабый, тем более с bonding.
Все ресурсы у него будут уходить на CPU. Это Switch !!!
Посмотрите на его блог диаграмму. Вы уже не первый кого я встречаю, кто из 125 делает роутер.



Вот буквально в этом месяце в мерседес центре видел. При этом у них есть в наличие 2011.

https://github.com/django/django/blob/master/.gitignore

В папки окружения что-либо вносить - плохая идея. К примеру вашу модель User чудесно можно переопределить или наследовать не трогая окружение django.

Используйте concerns
Пример

Wordpress:
Advanced Custom Fields - Управление кастомными полями, важнейшая штука. Даже купил PRO версию с developer лицензией
Akismet - фильтр спама для форм на фронтэнде
Custom Post Types UI - Удобное управление кастомными типами записей и таксономиями
Duplicator - Удобнейший плагин для бекапов
Cyr to Lat - автоконвертация ссылок в латынницу
FakerPress - генерация "рыбного" наполнения сайта. Важно для тестов пагинации и т.п.
Regenerate Thumbnails - Плагин, который принудительно пересоздает нужные размеры картинок по запросу. Важнейшая штука при создании темы.
Reveal Template - Полезный плаг, который показывает текущий используемый файл шаблона во время разработки темы.
WPML - универсальная платформа для внедрения мультиязычности в сайт. Платный.
Contact Form 7 - самый лучший плагин для контактных форм на фронтэнде.
Ну и WooCommerce, если это магазин.

Из полезных сайтов:
https://codex.wordpress.org/ - официальная документация по Wordpress
https://css-tricks.com/snippets/wordpress - хорошая подборка полезных сниппетов
https://generatewp.com/ - полезнейший сервис генерации кода для вставки в тему. Избавляет от изнурительного процесса гугления рутинных штук.

class Category(models.Model):
    parent = models.ForeignKey('self', null=True)
    title = models.CharField(...)

class Product(models.Model):
    title = models.CharField(...)

Яблоко Гольден, это товар категории Фрукт, подкатегории Яблоко, подподкатегории Гольден.
Гибрид, это подкатегория имеющая две родительские категории. Следовательно: parent = models.ManyToManyField('self', null=True)

Лучший сорт - это просто булевое значение ->

# in class Category
is_best = models.Boolean(default=False)

Решал пару подобных задач на ruby on rails + passenger, для одной из них было создано грубо говоря 5 rails приложений размещенных на одном сервере (у каждого свой домен), одно из них было "главным" сайтом с личным кабинетом из которого происходило обновление контента на других 4 сайтах, суть была такая: все взаимодействия происходили по API, какие-либо изменения отслеживались с помощью websocket (необходимо было в реальном времени мониторить все активности). Это, если в кратце. Думаю на django построить подобную архитектуру не составит труда. Для другой задачи, необходимо было построить веб-приложение на одном домене, но должен был быть функционал создания n-го кол-ва "отдельных" сайтов с общим личным кабинетом. В этом случае задача была решена с помощью маршрутизации (routes), грубо говоря:

//это был роут на основной сайт
scope module: :mainClient do
    root to: 'index#home'
end

//роуты на остальные "подсайты"
namespace :subSite_1 do
    root to: 'index#home'
end

namespace :subSite_2 do
    root to: 'index#home'
end

в данном случае, каждый "подсайт" включая "главный" имели свои view, style, script. На django не писал но думаю логика от этого сильно не поменяется.

У обоих вариантов есть свои плюсы и минусы.

На Swift можно комфортно писать только под экосистему Apple. Xamarin же позволяет сделать кроссплатформенное приложение, но только с элементарным интерфейсом. Шаг в сторону от предложенных вариантов - и приложение начинает обрастать уродливыми проверками с платформозависимым кодом. Кроме того, бывают случаи, когда Apple выпускает обновление iOS, которое ломает совместимость с Xamarin и пока в Microsoft не выпустят патч, ваше приложение работать на новой операционке не будет.

Так что всё зависит от ваших предпочтений. Если знаете C# - то порог вхождения в Xamarin однозначно ниже. Но более применимой на практике технологией мне все равно кажется Swift.

Кроме того, для публикации приложений под iOS в обоих случаях потребуется физический Mac (или обходные пути для его получения) и платная лицензия разработчика.

Это чисто по Шарпу.
.Net. Сетевое программирование для профессионалов.
И тут посоветовали эту книжку. Она правда не для Шарпа, но тоже интересно прочесть.
Эффективное программирование TCP IP.
Ну и знание самого Шарпа:)

в начале 2000-ых, я открывала notepad и писала там html-код. жесткий.
потом открывала другой notepad и писала там css-код.
потом это соединяла воедино.

Потом был шаблон наипростейшего форума на PHP со своей БД. Но шаблон форума был как черный ящик.
Потом через БД я научилась делать менее жесткие html- страницы. К примеру, запрос возвращал ссылку на картинку, в зависимости от вводимого значения.

Потом были сайты с FLASH-анимацией.

Прошло много лет.

Сейчас я пишу на питоне. Использую все возможные фрэймворки, какие только найду. Если не нахожу, то пишу сама. Сейчас я ненавижу веб-разработку, и все что с ней связано.
Пишу дэсктопные приложения, скрипты для работы с дэсктопными приложениями и для работы с БД.
Не нужно не использовать фрэймворки. Это не совсем правильно.
Для фана - да. Как некоторые художники сейчас сами делают акварель, а не покупают в магазине. Для понимания работы - не самый лучший вариант. Нужно двигаться вперед. Понимание черного ящика придет само со временем.

Расскажу свою историю становления программистом 1С и что из этого получилось.
Решил я несколько лет назад войти в сферу 1С. Для этого я целый год по вечерам после работы, несколько раз в неделю изучал самостоятельно по книгам программирование 1С. И в течение года я сдал три экзамена на сертификаты по 1С (чё то там про Предприятие и УТ). Занимался как раз по курсу Радченко. Только там было Предприятие 8.2 а не 8.3. И ещё несколько хороших книг по 1С.
В общем через год меня взяли стажёром в контору, которая занималась внедрением 1С. Взяли благодаря сертификатам, я думаю. В описании вакансии было что-то написано про помощь наставников во время работы. Но по факту тебе просто ставят простейшую задачу и интернет в помощь. К коллегам особо с вопросами не по пристаёшь, так как люди мы все взрослые, и несколько раз задавать один вопрос "не комильфо". Просидел я так за компом, втупляя, три дня и нихрена не сделал. Глаза устали здорово за эти 24 часа. Я опупел.
Помощь была со стороны руководителя несколько раз. Это было описание алгоритма решения задачи. Алгоритм я и сам в принципе знал. Просто не смог его переписать в код. Вот и всё. Отношение было благожелательное, нареканий нет. Не знаю в чём тут дело. Такой вот у меня опыт вхождения в 1С. Тут я понял что такое быть программистом. Если бы я знал программирование 1С, наверное было бы проще.
Так я сам инженер-машиностроитель. После того раза опять ушёл в свою область. Но попытки "войти вайти" не прекращаю. Сейчас изучаю C#. Скорее как хобби, потому что это всё-таки трудно без специального образования.

Не делаю и не использую сервисы, требующие такой "верификации".
Особенно злостно, когда это даже не на сайте просят загрузить, а в оффлайне используют для "верификации клиента", к примеру, курьеры банков "Открытие", ТКС и других, фотографируя клиента с паспортом, паспорт отдельно и клиента отдельно на свой смартфон. Вот это ещё хуже чем "предоставьте селфи с паспортом". Такое себе всё из себя сертифицированное средство криптозащиты персональных данных, млин. Смартфон Prestigio. Тьфу!