Linux за българи: Форуми

И ако искате може и да коментирате  :)

Трябваше да има опция само Nginx. Поне за php+mysql е най-добрата опция според мен, а със fastcgi можеш да кешираш, също nginx има microcache ама то може да причини малко неудобства. С apache обаче може лесно да добавяш модули, и не е нужно да компилираш всичко отново.

Всичко зависи от ситуацията, но като знам, че питаш за WordPress мисля, че Nginx+phpfastgi е добра комбинация. Ама да знаеш, че има няколко подводни камъка :)

Apache + SSD disk

Тотално няма значение. Сървърът няма толкова голямо значение, всичко зависи от това какво и как прави приложението. Съвсем извън това, дори и това е ирелевантно, понеже днес скалирането е евтино и лесно и пак опираме до приложението, което може и да не може да се скалира лесно и евтино. Иначе има една стара дилема изкристализирала под формата на драмата с C10K проблема - и случаите и решенията са доволно много и доволно различни за да може отговорът да опре до "ползвам apache+varnish" или "ползваме nginx който reverse-проксира и балансира няколко инстанции на tornado приложение". Апропо където има значение, и в общия случай когато трябва просто да си хостнеш блога някъде, няма никакво значение, но все пак - когато това вече има значение, трябва да си доволно малоумен за да довериш избора на хора, за които всичко опира до сценариите описани в анкетата, без никакви негативни помисли. Така че спокойно, когато такива решения трябва да се вземат, то обикновено последните хора, които биват запитани са същите тези хора, които спорят за дистрибуции, графични среди или уеб сървъри защото нещо им се струвалo по-удобнo и по-приятнo.

Та накратко въпросът е горе-долу от сорта на какъв производител на превозни средства бихте избрали ако искахте да стигнете от София до Лондон - обаче без да се уточнява точно колко и какъв багаж ще се носи, дали има значение колко бързо ще се стигне дотам и дали цената е критерий.

Абсолютно некоректно зададен въпрос... Ама гейта е дал уникален пример :). Има и нещо друго - огромно значение има и СУБД дето дава дейтата отзад. Та така...

Има и нещо друго - огромно значение има и СУБД дето дава дейтата отзад. Та така...

Ъъъ, какво общо има субд-то с уеб сървъра?

Иначе няма голямо значение, имаше един пич дето му беше писнало да обясняват че nginx бил не знам колко пъти по-бърз от Apache, хвана се, направи една камара бенчове и в крайна сметка стигна до извода че двата са на практика с еднакъв performance, с лек превес за nginx при сервиране на статично съдържание. Така че май отговорът е "който те кефи повече".

Аз преди ползвах само Apache. После ми се наложи да свикна с nginx, две седмици го псувах, после ми се видя по-лесно даже и от Apache.

Иначе добавете и lighttpd в отговорите  :)

Цитат на: BRADATA в Aug 22, 2015, 07:14

Има и нещо друго - огромно значение има и СУБД дето дава дейтата отзад. Та така...

Ъъъ, какво общо има субд-то с уеб сървъра?

...

Ми от контекста на писанките от Били става ясно, че той иска да ползва распбери за да хоства уордпрес сайтове и разни други динамични неща, ползващи СУБД. Та за това има общо...

Има грубо три подхода при писане не само на уеб приложение/уеб сървър, но и на какъвто и да е сървър. Най-тривиалният е с pool от worker процеси, всяка клиентска връзка се обслужва от един такъв - това е най-лесният за реализиране, защото се избягват разни криви проблеми. Но от гледна точка на производителност също и най-неоптималния - защото е ресурсоемък и защото има огромен overhead от превключвания на контексти, интерпроцесна комуникация, латентност при форкване на нови процеси когато се налага и т.н. Но това е начина по който се случват в масовия случай нещата с apache/mod_php.

Вторият подход е сходен с първия - само че worker-ите не са процеси, а нишки. Това позволява по-малки разхищения на памет, по-евтино превключване между контексти, споделената памет лесно се използва за бърза комуникация между нишките и като цяло позволява по-висок брой обслужени паралелни заявки за същото време. Обаче това създава и проблеми - уеб приложението трябва да е thread-safe, а специално PHP много дълго време имаше проблеми с това и дори не знам дали към днешно време са решени изцяло. Което е по-криво, проблемите се случват в PHP интерпретатора и не винаги са очевидни. Apache го подържа, просто трябва да се използва друг mpm модел, не mpm_prefork.

Третият подход е радикално различен - там нямаме отделни worker процеси и нишки за всяка заявка, вместо това всички използвани сокети се вкарват в един fd set и се ползва select()/poll()/epoll()/etc за да се poll-ва set-а за събития - когато на някой файлов дескриптор се появи събитие, съответно заявката се обслужва. Това е едновременно и благодат и проклятие - ако всичко е написано като хората, резултатите са с порядъци по-добри от подхода с worker-ите, ако обаче не е - тогава резултатите са плачевни. Проблемът е че това е до известна степен друга парадигма - приложението трябва да се напише така че да работи по този начин и писането на такива приложения е тотално различно и доста досадно. И всичко трябва да е направено с идеята да работи така - например handler-ите за заявките ти може да са асинхронни, но ако правят синхронни заявки към базата, това означава че докато тече тази заявка, сървърът не може да обслужва нищо друго и останалите клиенти стоят и чакат. Така че файловите дескриптори ползвани при достъпване на базата също трябва да се вкарат във fd set-а и да минават през polling механизъма.

Като цяло, PHP като език и като имплементация е тотално непригоден за да се пишат такива приложения и затова при такива случаи се ползват разни по-екзотични неща като node.js или пък tornado. В apache имаше някакъв експериментален event-базиран mpm модел доколкото помня - въпреки че е абсолютно непригоден за използване с PHP приложения изпълнявани през mod_php, просто смисълът се губи.

Асинхронния/event-базиран подход също сам по себе си не е перфектен, защото когато всичко се обслужва в рамките на един процес, сървърът с приложението не може да утилизира многоядрена/многопроцесорна машина. Затова съответно има хибридни изпълнения - няколко worker-а с poll-ване на отделни множества от файлови дескриптори.

И най-накрая, тези неща като цяло в последно време не са толкова важни, откакто се появиха облаците и стана лесно да си вдигнеш като ти кефне нова инстанция. Като цяло това кара хората да се замислят повече за лесното скалиране на приложението, отколкото за оптималното изтискване на ресурсите. Като това не винаги е прост проблем, лесен за решаване.

Мериш с рулетката и преценяш кое да ползваш може и исс сървър да е

Обаче това създава и проблеми - уеб приложението трябва да е thread-safe, а специално PHP много дълго време имаше проблеми с това и дори не знам дали към днешно време са решени изцяло.

Хм, последно като гледах имаше един списък с 6-7 extensions, които не бяха thread-safe, останалото беше ОК. Едни колеги бяха тръгнали да пишат нещо по този тертип, не съм ги чувал да се оплакват от езика.

Третият подход е радикално различен - там нямаме отделни worker процеси и нишки за всяка заявка, вместо това всички използвани сокети се вкарват в един fd set и се ползва select()/poll()/epoll()/etc за да се poll-ва set-а за събития

Не бях чувал за това :) Можеш ли да пратиш линк към някое гитхъбско репо писано така да разгледам, че ми стана интересно?

И най-накрая, тези неща като цяло в последно време не са толкова важни, откакто се появиха облаците и стана лесно да си вдигнеш като ти кефне нова инстанция. Като цяло това кара хората да се замислят повече за лесното скалиране на приложението, отколкото за оптималното изтискване на ресурсите. Като това не винаги е прост проблем, лесен за решаване.

Е това е нормално, никой няма да си играе да пише оптимизации при положение че може просто да налее още малко долари на месец и да си вдигне параметрите на чарколяка който наема. Стига да не стигнеш момента когато тези пари ще станат неприятно големи, и тогава щеш не щеш ще ти се наложи да правиш магии  ;D

Не бях чувал за това :) Можеш ли да пратиш линк към някое гитхъбско репо писано така да разгледам, че ми стана интересно?

Мммм произволно node.js приложение предполагам. Макар че аз поне node.js никога не съм пипал, javascript нещо не ми е от любимите неща, такива неща съм правил на питон с tornado фреймуърка. Та предполагам из github ще има доста tornado неща също, за тях бих могъл да коментирам повече какво и как го правят :)

P.S всъщност торнадо-то си идва с доста демо примери, може да хвърлиш едно око:

https://github.com/tornadoweb/tornado/tree/master/demos

Добре де аз кой подход съм правил ??? ??? Преди се опитвах да правя на PHP сървер... и го направих и ми върши работа.

Общо взето в тази последователност:
socket_create()
socket_bind()
socket_listen()

след това с socket_select() се определят сокетите на които има движение, а чрез socket_accept() се приема нова клиентска конекция ако има такава и се добавят в $client_socks[].
правят се два масива:
$client_socks[] с всички активни клиентски сокети и масива
$read[], които са тези сокети сред активните на които е детекнато движение.
След това по този списък се облужват(четат) един по-един тези на които преди това е детекното движението.
е това е кода дето успях да скалъпя...Орязъл съм го за пригледност така че може да има и несъответсвия.

GeSHi (PHP):
#!/usr/bin/php -Cq
<?php
 
// test
// nc localhost 8181
// ncat localhost 8181
//
// monitor
// netstat -ntc
 
$address = '127.0.0.1';
// '0.0.0.0' слуша на всички интерфейси
$address = '0.0.0.0';
$port = 8181;
 
$max_clients = 3;
 
 
 
function socket_init($address, $port)
{
// създава TCP мастер сокет който да слуша на  $address:$port и връща този сокет
// при грешка се връща false
 
// Create a TCP Stream socket
if (false === ($sock = socket_create(AF_INET, SOCK_STREAM, SOL_TCP)))
	{
	fwrite(STDERR, "socket_create() failed: reason: ".socket_strerror(socket_last_error())."\n");
	return false;
	}
 
// Bind the socket to an address/port
if (false === @socket_bind($sock, $address, $port))
	{
	fwrite(STDERR, "socket_bind() failed: reason: ".socket_strerror(socket_last_error($sock))."\n");
	return false;
	}
 
// Start listening for connections
// man 2 listen
// http://fixunix.com/unix/379049-server-socket-how-limit-number-connections.html
// http://stackoverflow.com/questions/5111040/listen-ignores-the-backlog-argument
//
// вторият параметър на socket_listen() се нарича 'backlog' и няма никакъв ефект за ограничаването
// на броя конекции. Той е само консултативен и посочва по някакъв вътрешен алгоритъм на OS-а
// колко ще бъде голяма опашката на чакащите конекции.
//
// The backlog argument to listen() is only advisory.
//
// POSIX says:
//	The backlog argument provides a hint to the implementation which the implementation shall use
//	to limit the number of outstanding connections in the socket's listen queue.
// Current versions of the Linux kernel round it up to the next highest power of two,
// with a minimum of 16. The revelant code is in reqsk_queue_alloc().
//
if (false === socket_listen($sock, 0))
	{
	fwrite(STDERR, "socket_listen() failed: reason: ".socket_strerror(socket_last_error($sock))."\n");
	return false;
	}
 
return $sock;
}
 
 
//////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////// Начало инициализация ////////////////////////////////////////////
 
/////////// Инициализация Сокети //////////////
// http://php.net/manual/en/sockets.examples.php
 
// http://www.binarytides.com/php-socket-programming-tutorial/
// http://bg2.php.net/manual/en/function.socket-select.php
 
if (false === ($master_sock = socket_init($address, $port))) die;
 
fwrite(STDERR, "Listen on port $port.\n");
 
 
//////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////// Главна програма ////////////////////////////////////////////
 
 
// масив с клиенските сокети, който реално ще се обслужват -- резултатите от $msg_sock = socket_accept($master_sock)
$client_socks = array();
 
// масив от сокети, които ще се проверяват за нови конекции от socket_select()
// и това ще са върнатите сокети от  socket_select(), които са кандидатите за обработка защото в тях вече има постъпили данни
// ако се приеме конекцията за обработка от read[] масива то тя ще се добави в $client_socks[]
$read = array();
 
 
// main loop
while (true)
{
// main loop подготовка на клиенските сокети за обработка - приемане отказване
//////////////////////////////////////////////////////////////////////////////
 
 
      // prepare array of readable client sockets
      $read = array();
      // за да работи правилно socket_select() трябва първият в списъка който ще се подаде де е master сокета
      $read[0] = $master_sock;
 
      // прехвъляне на списъка с активните сокети $client_socks[] в $read[] масива за проверка
      // т.е. правим копие на $client_socks[] в $read[] защото след socket_select() §$read[] масива ще е променен
      for ($i = 0, $size=count($client_socks); $i < $max_clients and $i < $size; $i++)
      {
	    if($client_socks[$i] !== null)
		$read[$i+1] = $client_socks[$i];
      }
 
    // чака блокиращо докато се появи някъде, че има постъпили данни на някой сокет.
    // последният параметър NULL показва блокиращо чакане.
    // А другите два параметъра за следене по запис и  exceptions $w= NULL, $e= NULL са забраннени да не се ползват.
    //
    // при изход socket_select() връща броя сокети в които има постъпили данни. и масива $read (по адрес), който
    // е списък на сокетите в които има постъпили данни.
    //
    // когато във върнатият масив се съдържа и $master_sock това означава и че има и новопостъпила конекция. 
    // ??? една нова конекция или няколко. всички примери обслужват само една - може би точно така действа socket_select()
    if(socket_select($read, $w= NULL, $e= NULL, NULL) === false)
    {
	fwrite(STDERR, "socket_select() failed: reason: "
		       . socket_strerror(socket_last_error())."\n");
	fwrite(STDERR, "The Server can NOT service the incommning connection.\n");
	socket_clear_error();
	break;
    }
 
 
 
    // if $read contains the master socket, then a new connection has come in
    // намираме първият свободен слот в $client_socks[] и там записваме конекцията
    // първият свободен слот може да е както в средата на масива така и накрая, след запълнените елементи
    if (in_array($master_sock, $read, true))
    {
	$accepted=false;
        for ($i = 0, $size=count($client_socks); $i < $max_clients; $i++)
        {
	    // може и само if ($client_socks[$i] === null)
	    // тази допълнителна проверка $i>=$size се прави само да няма Notice:  Undefined variable за  $client_socks[$i]
	    // когато се отработва ситуацията когато се добава сокет в края на масива
	    // (т.е $client_socks все още е по-малък от максималният си размер - $max_clients и $i излиза отвън) 
            if ($i>=$size OR $client_socks[$i] === null)
            {
	    // Тази функция чака (блокиращо) за осъществяване на връзката от отдалеченият клиент.
	    // (В случая не чака а връща веднага защото конекцията е приготвена от преди от socket_select())
	    // Когато клиента осъществи връзка socket_accept() връща нов 'клиентски' сокет за комунукация за точно
	    // тази конекция.
	    //
	    // If there are no pending connections, socket_accept() will block until a connection becomes present.
	    // this function will accept incoming connections on that socket. Once a successful connection is made,
	    // a new socket resource is returned, which may be used for communication.
	    // If there are multiple connections queued on the socket, the first will be used. 
	    // винаги да се ползва socket_clear_error() защото socket_last_error() не чисти грешката.
	    if (( $client_socks[$i] = $msg_sock = socket_accept($master_sock)) === false)
		  {
			fwrite(STDERR, "socket_accept() failed: reason: ".
				socket_strerror(socket_last_error($master_sock))."\n");
			fwrite(STDERR, "The Server can NOT service the incommning connection.\n");
			socket_clear_error($master_sock);
		  break 2;
		  }
 
	    socket_getpeername($msg_sock, $client_ip, $client_port);
	    fwrite(STDERR, "($i) Connection established. $client_ip:$client_port\n");
 
	    // Винаги точно 3 реда съобщение - това ще позволи на автомата който се вързва към сървера
	    // лесно да отдели тези 3 реда.
	    socket_write($msg_sock, "Добре дошли в сървера.\n");
	    socket_write($msg_sock, "\n");
	    // край на цикъла, защото е вече намерен слота и е осъществена връзката
 
 
	    $accepted=true;
            break;
            } //if
        } // for ($i = 0; $i < $max_clients; $i++)
 
	if (!$accepted)
	  {
	  // имало е индикация за нова конекция защото сме вътре в проверката if (in_array($master_sock, $read))
	  // но е нямало свободен слот. Затваря се конкцията към клиента
	  // единственият начин за затваряне на (пендиг) конекцията е тя да се приеме да се изпише кратко съобщение на клиента
	  // и да се затвори. Така няма да може да се предаде по нататък на тежката обработка.
		  if (( $msg_sock_denited = socket_accept($master_sock)) === false)
		  {
			fwrite(STDERR, "socket_accept() failed: reason: ".
				socket_strerror(socket_last_error($master_sock))."\n");
			fwrite(STDERR, "The Server can NOT service the incommning connection.\n");
			socket_clear_error($master_sock);
		  break 1;
		  }
		  socket_getpeername($msg_sock_denited, $client_ip, $client_port);
 
		  fwrite(STDERR, "Connection denied. $client_ip:$client_port\n");
 
		  socket_write($msg_sock_denited, "Welcome to the Server.\n");
		  socket_write($msg_sock_denited, "Server busy. Too many connections. Try again later.\n");
		  socket_write($msg_sock_denited, "\n");
		  socket_close($msg_sock_denited);
	  } // if (!$accepted)
 
    } //if (in_array($master_sock, $read))
 
// main loop край на подготовката на клиенските сокети за обработка - приемане отказване
////////////////////////////////////////////////////////////////////////////////////////
 
 
//fwrite(STDERR, "Loop start.\n");
// loop - обслужване на клиентски сокети
//////////////////////////////////////// 
	for ($i = 0, $size=count($client_socks); $i < $max_clients and $i < $size; $i++)
	{
	if (in_array($client_socks[$i] , $read, true))
        {
 
	$msg_sock=$client_socks[$i];
	// fwrite(STDERR, "\n\n(start)\n");
 
	// socket_read() чака
	// и връща false при следните ситуации:
	// 1. error
	// 2. connection closed
	if ( false === ($input_line = socket_get_data($msg_sock,$error,$error_str)) )
		{
		if(104 == $error) { fwrite(STDERR, "($i) Connection closed.\n");
				    socket_close($msg_sock);
				    $client_socks[$i]=NULL; 
				    continue; }
		else { fwrite(STDERR,  "socket_read() failed: reason: $error_str\n");  break 2; }
		}
 
 
	/////////////////////////////////////////////////////////////////////////////////////////////////////
	/////// оснавната част на скрипта ////////////////////////////////////////////////
	/////////////////////////////////////////////////////////////////////////////////////////////////////
	// !!! към това което се пише обратно ($input_line), не трябва да се добавя \n накрая защото и си има 
 
 
	$translated_line = $input_line;
	// връща го обратно по нета
	socket_write($msg_sock, $translated_line);
 
 
	////////////////////////////////////////////////////////////////////////////////////////////////////
	/////// основната част на скрипта ////////////////////////////////////////////////
	////////////////////////////////////////////////////////////////////////////////////////////////////
 
	}
	}
// fwrite(STDERR, "Loop end.\n");
// loop - край на обслужване на клиентски сокети
////////////////////////////////////////////////
 
} // end of main loop
socket_close($master_sock);
 
?>
 

Обаче въпроса който ме мъчи е как може да се ограничи броя на приеманите конекции? например разрешени са три едновременни конекции и искам на четвъртият клиент да му се откаже конекциятя? да му се върне нещо то рода на Server busy, access denied..... Това не можах да разбера как се прави и дали изобщо е възможно с tcp?


в socket_listen() има параметър дето се нарича 'backlog' той е някакъв кърнелси стек? за броя конекции но изобщо не оказва влияние на броя конекции.

Едиственото което успях да измисля е като дойде 4-та конекция да я приема да изпиша нещо към клиента от рода на Server busy и веднага да затворя съответният клиентски сокет?

Не точно, backlog-а е по-скоро максималния брой на клиентските връзки които чакат да ги accept-неш, а като удариш тази бройка на клиентите им се връща обикновено грешка при connect() и вече си е тяхна работа дали да върнат грешка или да пробват отново.

Няма нещо наготово, което да те лимитира колко клиентски връзки да приемеш - това си зависи от теб. Може примерно да пазиш броя на клиентските връзки и като стигнеш до максимума отворени, да не accept-ваш нови.

Добре де аз кой подход съм правил ??? ??? Преди се опитвах да правя на PHP сървер... и го направих и ми върши работа.

Ами третия, само че не оптимално.

Апропо, нещата са описани доста по-детайлно тук: http://www.kegel.com/c10k.html

Ами третия, само че не оптимално.

В смисъл? че третият подход не е оптимален или че греша някъде в постановката. Скорост и ниска латенция изобщо не ми е нужна, защото процеса който обслужва е хиляди пъти по бавен. Единствено ме интересува постановката да е правилна, защото все имам неприятно усещане че нещо греша със сокетите.

Може примерно да пазиш броя на клиентските връзки и като стигнеш до максимума отворени, да не accept-ваш нови.

Да но те се трупат в опашката точно заради backlog-а. например клиентите 4,5,6,7,..... седят и чакат и по никакъв начин не могът да разберат че немогат да се вържат. Едва когато се затвори някоя от активните конекции от 1,2,3 тогава на някой от чакащите му идва реда. А аз това не искам да се случва.

В смисъл че не ползваш неблокиращо IO и че select е бавно и лимитирано откъм максимален брой дескриптори в сета. Но ако производителността не е критична, значи няма значение.

А иначе, backlog-а няма отношение към това дали затваряш активни конекции. Можеш да затвориш всички, но да не викаш accept и тогава ще продължат да се трупат там, просто ако искаш да сложиш твърд лимит на активните клиенти го прави преди accept и да не ти пука толкова за опашката чакащи - това така или иначе е работа на операционната система, ти единствено можеш да кажеш колко да се трупат там преди да почне да им се връща грешка.

 :D Колкото и да се мъчих да го направя неблокиращо не ми се получаваше!!! Едва когато ги направих в blocking-mode тогава тръгна както трябва.

Вярно е, кочината много бързо става пълна с неблокиращи сокети. Особено като ги poll-ваш и почнат нон-стоп да ти се връщат "фалшиви" събития.