Во-первых, клиенту, да еще и чайнику настолько по барабану на документацию, потому что он вряд ли программист и будет пилить приложение.
Во вторых, то что вы привели не является реалием дел. Как много интернет магазинов на C++ вы видели? А знаете сколько нужно человек на проект чтоб его поддерживать?
Ваша картинка имеет место быть внутри компании яндекса, так как боты и существенная часть ПО у Яндекса исторически на С++, JavaScript на интерфейсах всех сервисов, далее по убыванию: Java - для тестирования и мобильных приложений, Python - для аналитических алгоритмов (в питоне богатая библиотека математическая и различные научные либы, ведь не зря питон это ЯП ученых), Perl - разбирает по полочкам большие массивы текстовых данных ( удобнее для этой задачи конечно же пока не нашлось языка, так как perl как не крути написан лингвистом ).
Вопрос: что из всего этого требуется заказчику интернет магазина например? :))
А картинки лучше брать из спец источников, например:
http://githut.info/
http://redmonk.com/sogrady/2016/02/19/language-rankings-1-16/
ну и далее по списку коих много на самом деле---------- Добавлено 08.04.2016 в 16:44 ----------
Тут не совсем понятен вопрос.
Заказчику в большинстве своем требуется конечный продукт, для реализации каких то бизнес процессов. По-этому, если он обратился к команде которые пишут на python, то они напишут ему на нём, если к вордпрессклепателям, то ему на вордпрессе систему управление кинотеатром построят, не то что там ИМ.
Технологии и популярны и активны, по этому разницы, как правило нет. Да, питон разработчики дороже, но шанс получить в результате шлак намного меньше. Исторически сложилось так, что со школьной скамьи изучают PHP, а в питоне сообщество более квалифицированное, чем PHP, но я не говорю, что там нет крутых спецов, просто в общей массе, в процентном соотношении, их намного меньше ))
Я тут подумал. Вы можете вставить результат работы скрипта через iframe. Или пользовательскую логику сделать через ajax, а обработчик будет на php, но как страницы существовать не будет.
Уже давали эту ссылочку или еще нет? https://habrahabr.ru/post/262623/
Там у людей 38 млн в час и 95% запись, на одном сервере. Так что БД как правило не причем, очень часто причиной становится кривая архитектура приложения.
Да вы кстати посмотрите еще в сторону aws rds
Если хотите, я могу посмотреть вашу проблему напрямую на сервере.
Просто вы явно копаете не туда.
Даже настроить сервер помочь могу.
В личку напишите
Гипотетически (историй может быть много).
Например вам понадобится сделать форму, в которую можно крепить платежку об оплате услуг с отметкой банка. Банк клиент возвращает платежку в html формате.
Вы попросите программиста, допилить вам этот функционал, программист не будет в курсе, что html файлы у вас могут выполнять php код ( ну это не логично, как минимум ), вы конечно про это благополучно забыли и не сказали программисту, ведь уже год прошел с того момента.
И вот через некоторое время, ваш хостер блочит ваш акк за спам... :)
Я не говорю, что это дыра ежеминутная, как только вы это сделали, ваш сайт сразу же ломанут. Эта та дыра, которая расчитана на человеческий фактор. Я опять повторюсь, сценариев развития много, просто нет смысла вносить такие ошибки изначально, это грабли на которых многие наступали. Конкретно вы, возможно и не наступите, но зачем изначально стрелять себе в ногу.
Файлы с html должны быть html, а файлы с php кодом должны быть с расширение php, тип должен соответствовать своему обработчику, тогда такие приложения более предсказуемы. Тем более мы же не знаем, что там в будущем будет, по этому и придуманы стандарты :)
Потому что на uploader'ы файлов стоят ограничение по расширениям скриптовых языков и html к ним не относится. Плюс в папочке с upload может лежать .htaccess (он в принципе должен лежать там) со значением:
AddType "text/html" .php .cgi .pl .fcgi .fpl .phtml .shtml .php2 .php3 .php4 .php5 .asp .jsp
В случае если вы добавите своё расширение, то тут оно уже не отработает.
Вообщем схем много, лучше не делать своими руками бреши в безопасности на будущее.
PS. Я видел сервера, где модуль php был типом по умолчанию, там можно было даже вставить код php в картинку и он отработал бы как надо.---------- Добавлено 04.04.2016 в 15:43 ----------
А еще можно стать параноиком и запретить прямой доступ к файлам с расширением .php :) Тем более если вы знаете, что на вашем сайте таких файлов быть не должно.
В том, что когда либо вам в папочку положат файл backdore.html и он отработает на ура, а в фильтре расширений не будет запрета на html, потому что html файлы лезут много от куда, включая счета на оплату и так далее.---------- Добавлено 04.04.2016 в 15:23 ----------
Через RewriteRule например. Проверить что файла page123.html не существует и перенаправить запрос на page123.php
На сколько я знаю, php функции подключаются к базе через mysql-client, а что слушает сервер mysql настраивается в файле my.conf и вы никак не настроите в функциях php tcp соединение к базе, если база его не слушает даже.
начните с этого
Это выявит источник спама.
Такую надстройку можно сделать как правило через .htaccess
php_value mail.add_x_header 1 php_value mail.log /path/to/site/mail.log
Я описал всё выше.
Это из разряда "из пушки по воробьям", серверные SSD имеют IOPS более 120 000, то есть 120 000 операций чтения/записи в секунду, это много так ведь? На практики скажу, что не используя оперативку, на сервере со статическим кешем (перегонять результат выборки в файл), у меня виртуалочка на 1 гиг выдерживает 5500 запросов в секунду ( более 120 000 номенклатуры ), при том для разогрева кэша требуется более 30 минут, при том обновление кеша практически не требуется. Я могу сейчас ресурс вместе с кешем перенести на другой сервер и его не придется перестраивать.
Да к чему я это, если бы вы хранили кэш на диске, вы бы не заметили разницы ))) Мемкеш работает на кластере серверов с горячей заменой, где оперативки неприлично много для рядового проекта.
НО, вы можете использовать мэмкэш, просто я хочу сказать, что это не панацея и всем рекомендовать это не надо :) На слабых машинах мемкэш во вред, есть более продуктивные схемы кэширования, где прирост будет 500%, а не 20-25%. Да и топик не про это )))
