Евгений Вольф

Что лучше использовать SVG или PNG для Логотипа ?

Лучше, подозреваю, что SVG. Так как SVG - это векторный формат и он хорошо выглядит на любом разрешении, в т.ч. на телефонах, у которых разрешение физическое может быть очень высоким, а фактическое - в несколько раз меньше.

К тому же, SVG обычно меньше занимает и т.д.

Но, не забывайте, что это два диаметрально противоположенных формата, и далеко не всё можно перевести в SVG-формат. Но то, что можно сделать - обычно делают именно в формате SVG.

То бишь текст "рыба" должен растянуться по ширине блока "рыбак".

Либо задать одинаковую ширину обоим блокам, одинаковую - в буквальном смысле.

Либо родительский блок должен быть нужной ширины, тогда вложенный блок будет 100% ширины родительского.

Либо, через JS.

Поддерживает ли Ubuntu видеокарту GTX 1050? Если да, то где взять драйвера?

Как Вы понимаете, за поддержку устройств отвечает в большей степени не дистрибутив, а ядро и его составляющие. Иначе говоря, если что-то поддерживает дистрибутив "A", с большей вероятностью такую поддержку можно сделать и в дистрибутиве "Б".

Конкретно по Вашему вопросу:
Если судить по сайту производителя - поддерживает, если у вас 64-битная версия, в чем Вы можете убедиться лично, пройдя по этой ссылке, раздел "поддерживаемые продукты". Там же есть и кнопка "Загрузить сейчас".

Вот уже неделю страдаю над авторизацией на сайте

Вы завязывайте с этим, так и нервный срыв получить можно :D

Что этот парсер должен делать? что найти? и как потом использовать то что он нашел? и когда он должен запускаться?

Что именно происходит в JS-коде - Вы можете посмотреть в своём собственном браузере, нажав F12 и открыв отладчик JS. Детально проанализировав полученную информацию, Вы сможете понять, что там происходит...

Другой (или дополнительный вариант) - Вам нужно будет детально изучить HTTP-заголовки которые отправляет Ваш браузер и сравнить их с заголовками, которые отправляет Ваш парсер...

Ещё как вариант, рекомендую Вам ознакомиться с PhantomJS, среди прочих применений - он так же применяется вместе с PHP (который вы указали в тегах) для тестирования проектов на уровне "эмуляция браузера/пользователя".

По мнению некоторых участников дискуссии подключений не может быть более 65536

Насколько я помню - всего TCP-портов 65536 (порт 0 зарезервирован), а максимальное количество соединений на один порт, не припоминаю, что бы чем-то ограничивалось (ну кроме ресурсов машины). Вы же понимаете, как в общей сложности всё это работает? Сервер хранит где-то в недрах памяти информацию по каждому соединению, при этом Вы можете подключаться многократно на один и тот же порт, с одного и того же IP к тому же самому серверу...

Не знаю, с какой именно стороны Вас данный вопрос интересует больше, с теоретической или практической... когда-то давно, возникла проблема "мирового масштаба", под названием C10k, которая впоследствии была успешно решена в ряде программ, в т.ч. Nginx (который создавался в т.ч. с прямым расчётом решения этой проблемы). Если Вы перейдете по последней ссылке, там Вы можете встретить следующую фразу:

По состоянию на середину 2010-х годов серверный аппаратный узел среднего уровня способен обрабатывать до 10 млн соединений

, т.е. 2010-й год, 10млн. соединений, одновременно. Думаю, этой цифры более чем достаточно практически для любого современного и даже очень нагруженного проекта, к тому же, как Вы могли заметить, про ограничения протокола TCP/IP, даже гипотетические - ничего не сказано.

В принципе, наиболее вероятную причину происходящего (а в большинстве случаев и единственную) Вам уже описал предыдущий автор, но от себя хотелось бы добавить вот что:

Для FireFox, есть очень полезный инструмент, отображающий страницу в формате 3Д, на котором можно отследить какой слой под/над каким находится и так далее. Иногда - очень выручает. Начиная с версии FireFox-47 он доступен в виде отдельного модуля. Подробности, ссылки, скриншоты и т.п.

*В Вашем случае, эта шутка наверняка сможет показать, какой слой физически перекрывает тот, что Вам нужен.

Почему include, require возвращает 1?

Думаю, по тому, что файл удалось подключить. В ином случае, оно бы вернуло вам "0" (т.е. false). Если Вам нужно содержимое файла, а не подключение куска PHP-кода, для этого есть функция file_get_contents() например.

Изучил весь 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'а, и невозможности от него избавиться или самостоятельно настроить, и как следствие "тормозов" которые приходят вместе с подобным подходом).

Почему на php криво выводит из файла?

Думаю, что это не PHP так криво выводит, а Ваш браузер так криво отображает, т.к. русские буквы не той кодировке, в которой работает браузер. Попробуйте изменить кодировку в браузере на ту, в которой сохранен файл, который Вы читаете с помощью PHP.

P.S. Так же, если у Вас в качестве веб-сервера, на котором это тестируется - Apache - в нем можно задать кодировку через файл .htaccess, расположенный в корне сайта (создать новый или добавить эту строчку в уже существующий), подробности описаны тут.

А так же можно воспользоваться PHP-заголовком, или попробовать отправить в браузер мета-тег с кодировкой, как обсуждалось тут.

Какой-то "Расширенный раздел" (объясните плз что это)

Тут подробно написано, что это

Пробовал форматировать sdb5, не получилось.

Отформатировать не получилось?

Подкачка (я так понимаю что-то необходимое)

Это раздел в который сливаются данные из оперативной памяти при нехватке оной, условно говоря, кусок диска который используется как оперативная память когда её не хватает. В новых версиях Ubuntu'ы собирались перенести этот раздел в файл, без создания отдельного раздела (как в винде). Касательно его необходимости - вопрос риторический и философский (с учётом того, что уже на телефонах по 16+ Гб оперативки стоит иной раз).

Вопрос как избавиться от не нужного дистрибутива?

Вам от дистрибутива нужно избавиться или от меню в загрузчике? Если от дистрибутива, насколько я понимаю, он должен быть способен загрузиться. Это так? Если да - просто удалите раздел (совсем) на котором стоял этот дистрибутив и дело с концом. Если же речь идёт про меню загрузчика - довольно хорошо про него расписано здесь.

Как сформировать 1 запрос UPDATE с тысячей значений?

Вот так, и так до 1000 (или сколько Вам будет нужно):

UPDATE table1
	SET val = CASE
		WHEN id = 1 THEN 10
		WHEN id = 2 THEN 20
		WHEN id = 3 THEN 30
	END
  -- тут ещё можно дописать условие, типа WHERE id IN (1,2,3)

По одному запросу посылать не вариант.

По моему, Вы пытаетесь вывернуть бедного дельфина наизнанку через за... Можно посылать много запросов за 1 раз, разделяя их ";" (точкой с запятой). Более того, их так же можно обернуть в транзакцию (как много запросов по одному, так и много запросов через ";").

P.S. Пример таблицы над которой проводились эксперименты: (на всякий случай)

Как видите в provider имя банка в кавычках и из-за этого рушится JSON Как быть?

а) Оптимально - Попросить того, кто писал удалённый сервис - исправить столь явный баг кодирования в JSON и намекнуть ему, что если он сам не может сделать нормально - пусть воспользуется готовыми библиотеками.
б) Костыль - примерно такой:

$json_string = str_replace ('""', '\"\"', $json_string)