Nazdar aj ja používam ISPCONFIG a zdá sa mi že občasne su niektoré moje weby dosť pomalé a dlho sa načítavajú, je možné že ispconig nema vsetko nastavené tak ako má mať.

2011/9/9 <community-list-request@lists.vpsfree.cz>
Send Community-list mailing list submissions to
       community-list@lists.vpsfree.cz

To subscribe or unsubscribe via the World Wide Web, visit
       http://lists.vpsfree.cz/listinfo/community-list
or, via email, send a message with subject or body 'help' to
       community-list-request@lists.vpsfree.cz

You can reach the person managing the list at
       community-list-owner@lists.vpsfree.cz

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Community-list digest..."


Today's Topics:

  1. Re: PHP - pomalé vyřízení Ajaxových odpovědí (zzzemfira89)
  2. Re: PHP - pomalé vyřízení Ajaxových odpovědí
     (Ladislav Blažek)
  3. Re: PHP - pomalé vyřízení Ajaxových odpovědí (zzzemfira89)
  4. Re: PHP - pomalé vyřízení Ajaxových odpovědí
     (Ladislav Blažek)


----------------------------------------------------------------------

Message: 1
Date: Fri, 9 Sep 2011 15:34:54 +0200
From: zzzemfira89 <zzzemfira89@gmail.com>
To: Jan Drábek <me@jandrabek.cz>
Cc: community-list@lists.vpsfree.cz
Subject: Re: [vpsFree.cz: community-list] PHP - pomalé vyřízení
       Ajaxových odpovědí
Message-ID:
       <CAJCP3Rh2RNuKUxkui8rVsGbTMeJo_2hqyfS7vm6ukp=Spu546A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Ahoj.

Ja som skratka nainstaloval cely ispconfig3 a len klikam :-).

Ale bezi to tusim ako su_php modul pre apache2. Tiez mam prefork.
Takze mam "klientov", konkretne unixove groups a kazdy z nich ma weby,
co su users.

PHP potom bezi s pravami user:group pre prislusny skript. Co je
ziadany efekt :-) .
Z /var/log/suphp/suphp.log :
[info] Executing "/var/www/clients/client4/web6/web/index.php" as UID
5009, GID 5010

Jedneho casu som mal aj mod_php, ale tam som mal problem nastavit
tieto opravnenia pre php. Podobne ani fast-cgi som nedokopal k tomuto.

Matej Snoha

2011/9/9 Jan Drábek <me@jandrabek.cz>:
> Také jsem chvílí použival google apps, ale vzhledem k drsným podmínkám,
> které vlastně říkají, že se vším co projde přes google si můžou dělat co
> chce...
> To mi přijde takového Kafkovské (to do jaké míry drží google kontrolu nad
> jednotlivými identitami... viz Proces).
>
> Uptime a load:
> 12:29:39 up 16 days,  3:55,  1 user,  load average: 0.02, 0.01, 0.00
>
> Apache mi používá apache2-mpm-prefork s tímto nastavením (nicméně ani 10x
> parametrů neukázalo výkonový rozdíl.
>
> <IfModule mpm_prefork_module>
>     StartServers          5
>     MinSpareServers       5
>     MaxSpareServers      10
>     MaxClients          150
>     MaxRequestsPerChild   0
> </IfModule>
>
> PHP akcelerátor nepoužívám.
>
> Suhoshin - Ano používám.
>
> V lodzích mám jen samé nezajímavé věci:
>
> Hlášení o nepovolených zvýšeních memory limitu
> Hlášení o nutnosti nastavit timezone (mám v php.ini?!)
>
> Používám PHP verze 5.3.8-1~dotdeb.2. Nicméně používám CGIčkové PHP což tuším
> bude asi hlavní zdroj problémů.
>
> Je to problém více aplikací (namátkou jsme zrovna dneska zkoušel i atMail a
> trpěl stejným problémem).
>
> Jak řešíte oddělení domén (účtů) vy? (Tzn, aby si PHP nemohlo číst celý
> adresářový strom, aby jste mohli mít různé php konfigurace pro různé domény
> atd...)
>
> Dík
>
> On Fri, 9 Sep 2011 12:01:46 +0200, zzzemfira89 wrote:
>
> Ahoj.
>
> No ja osobne mam google apps, takze tak :-) .
> Ale problem dakde bude. Mne ajaxove veci bezia rozumne (zlomok sekundy).
>
> Napis, co mas vlastne za konfiguraciu web servera. (# apache2ctl status |
> head)
> Keepalive zapnute a rozumne vysoke? Pocty procesov/threadov v
> apache.conf? Nie ze chudak Apache musi forknut novy proces pre kazdy
> novy ajax request a potom ho zabit.
>
> Pouzivas Suhoshin? Ked tak, on ma vlastny log (/var/log/user.log).
> Samozrejme pozri aj do apachovych logov, ci su nejake chyby v php a podobne.
> Pouzivas aj nejaky PHP accelerator (APC napr.,)? Ze by bol nejako
> divne nastaveny.
>
> A daj vediet aj load average, ked ten webmail budes trapit zo 5 minut.
> Ci sa tam fakt nieco narocne robi, alebo len vyvojari zabudli nejaky
> sleep() v kode :-).
>
> Matej Snoha
>
> PS: Sice off-topic, ale uz od rana ma DOSuju daki amici z DSLka. Co
> uz, pakety im zahadzuje fail2ban, ale ze nemaju nic lepsie na praci.
>
> 2011/9/9 Jan Drábek <me@jandrabek.cz>:
>
> Zdravím, netuším zda jsem si toho všiml až poslední dobou nebo se to
> vyskytovalo už dřív, ale zdá se mi, že AJAxové požadavky na Apache/PHP jsou
> dost pomalé. Nejvíc je problém vidět třeba v RoundCube, kde načtení seznamu
> zpráv, určité zprávy, přesun atd... trvá až desítku sekund. Potřeboval bych
> nakopnutí jak takový problém uchopit, kde můžou mít zakopaní psi atd. Díky
> Jan D. P.S. Neznáte nějaký webmail ve kterém vypadají konverzace stejně jako
> v Gmailu? _______________________________________________ Community-list
> mailing list Community-list@lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list


------------------------------

Message: 2
Date: Fri, 9 Sep 2011 15:39:47 +0200
From: Ladislav Blažek <lada@blazcata.cz>
To: zzzemfira89 <zzzemfira89@gmail.com>
Cc: community-list@lists.vpsfree.cz
Subject: Re: [vpsFree.cz: community-list] PHP - pomalé vyřízení
       Ajaxových odpovědí
Message-ID:
       <CANkn7ReY8FY+KekMQOrZbsqnuMNGPPxP4rsFKxVXf7Oo1Vos0A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

SuPHP je asi ten nejpomalejsi zpusob jak provozovat PHP. Doporucuji fcgi a
suexec.
Dne 9.9.2011 15:35 "zzzemfira89" <zzzemfira89@gmail.com> napsal(a):
> Ahoj.
>
> Ja som skratka nainstaloval cely ispconfig3 a len klikam :-).
>
> Ale bezi to tusim ako su_php modul pre apache2. Tiez mam prefork.
> Takze mam "klientov", konkretne unixove groups a kazdy z nich ma weby,
> co su users.
>
> PHP potom bezi s pravami user:group pre prislusny skript. Co je
> ziadany efekt :-) .
> Z /var/log/suphp/suphp.log :
> [info] Executing "/var/www/clients/client4/web6/web/index.php" as UID
> 5009, GID 5010
>
> Jedneho casu som mal aj mod_php, ale tam som mal problem nastavit
> tieto opravnenia pre php. Podobne ani fast-cgi som nedokopal k tomuto.
>
> Matej Snoha
>
> 2011/9/9 Jan Drábek <me@jandrabek.cz>:
>> Také jsem chvílí použival google apps, ale vzhledem k drsným podmínkám,
>> které vlastně říkají, že se vším co projde přes google si můžou dělat co
>> chce...
>> To mi přijde takového Kafkovské (to do jaké míry drží google kontrolu nad
>> jednotlivými identitami... viz Proces).
>>
>> Uptime a load:
>> 12:29:39 up 16 days,  3:55,  1 user,  load average: 0.02, 0.01, 0.00
>>
>> Apache mi používá apache2-mpm-prefork s tímto nastavením (nicméně ani 10x
>> parametrů neukázalo výkonový rozdíl.
>>
>> <IfModule mpm_prefork_module>
>>     StartServers          5
>>     MinSpareServers       5
>>     MaxSpareServers      10
>>     MaxClients          150
>>     MaxRequestsPerChild   0
>> </IfModule>
>>
>> PHP akcelerátor nepoužívám.
>>
>> Suhoshin - Ano používám.
>>
>> V lodzích mám jen samé nezajímavé věci:
>>
>> Hlášení o nepovolených zvýšeních memory limitu
>> Hlášení o nutnosti nastavit timezone (mám v php.ini?!)
>>
>> Používám PHP verze 5.3.8-1~dotdeb.2. Nicméně používám CGIčkové PHP což
tuším
>> bude asi hlavní zdroj problémů.
>>
>> Je to problém více aplikací (namátkou jsme zrovna dneska zkoušel i atMail
a
>> trpěl stejným problémem).
>>
>> Jak řešíte oddělení domén (účtů) vy? (Tzn, aby si PHP nemohlo číst celý
>> adresářový strom, aby jste mohli mít různé php konfigurace pro různé
domény
>> atd...)
>>
>> Dík
>>
>> On Fri, 9 Sep 2011 12:01:46 +0200, zzzemfira89 wrote:
>>
>> Ahoj.
>>
>> No ja osobne mam google apps, takze tak :-) .
>> Ale problem dakde bude. Mne ajaxove veci bezia rozumne (zlomok sekundy).
>>
>> Napis, co mas vlastne za konfiguraciu web servera. (# apache2ctl status |
>> head)
>> Keepalive zapnute a rozumne vysoke? Pocty procesov/threadov v
>> apache.conf? Nie ze chudak Apache musi forknut novy proces pre kazdy
>> novy ajax request a potom ho zabit.
>>
>> Pouzivas Suhoshin? Ked tak, on ma vlastny log (/var/log/user.log).
>> Samozrejme pozri aj do apachovych logov, ci su nejake chyby v php a
podobne.
>> Pouzivas aj nejaky PHP accelerator (APC napr.,)? Ze by bol nejako
>> divne nastaveny.
>>
>> A daj vediet aj load average, ked ten webmail budes trapit zo 5 minut.
>> Ci sa tam fakt nieco narocne robi, alebo len vyvojari zabudli nejaky
>> sleep() v kode :-).
>>
>> Matej Snoha
>>
>> PS: Sice off-topic, ale uz od rana ma DOSuju daki amici z DSLka. Co
>> uz, pakety im zahadzuje fail2ban, ale ze nemaju nic lepsie na praci.
>>
>> 2011/9/9 Jan Drábek <me@jandrabek.cz>:
>>
>> Zdravím, netuším zda jsem si toho všiml až poslední dobou nebo se to
>> vyskytovalo už dřív, ale zdá se mi, že AJAxové požadavky na Apache/PHP
jsou
>> dost pomalé. Nejvíc je problém vidět třeba v RoundCube, kde načtení
seznamu
>> zpráv, určité zprávy, přesun atd... trvá až desítku sekund. Potřeboval
bych
>> nakopnutí jak takový problém uchopit, kde můžou mít zakopaní psi atd.
Díky
>> Jan D. P.S. Neznáte nějaký webmail ve kterém vypadají konverzace stejně
jako
>> v Gmailu? _______________________________________________ Community-list
>> mailing list Community-list@lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list
> _______________________________________________
> Community-list mailing list
> Community-list@lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20110909/d11a3c86/attachment-0001.html>

------------------------------

Message: 3
Date: Fri, 9 Sep 2011 15:46:45 +0200
From: zzzemfira89 <zzzemfira89@gmail.com>
To: Ladislav Blažek <lada@blazcata.cz>
Cc: community-list@lists.vpsfree.cz
Subject: Re: [vpsFree.cz: community-list] PHP - pomalé vyřízení
       Ajaxových odpovědí
Message-ID:
       <CAJCP3RhcdEOMM_hBT2=6XXBt8XTPAFEbuaVi_+skq6Xyo+mjkA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

A mas realne taky web ze to aj citit? Pre mna par milisekund hore-dole
nezavazi. Co som robil par php benchmarkov, fcgi mi na VPS bezalo
podobne rychlo. Ale zas tak do hlbky som to neskumal.

Ale tak jasne, fast cgi bude asi najrychlejim riesenim. Len ja z
hladiska bezpecnosti preferujem SuPHP, mam s tym dobre skusenosti.

Matej Snoha

2011/9/9 Ladislav Blažek <lada@blazcata.cz>:
> SuPHP je asi ten nejpomalejsi zpusob jak provozovat PHP. Doporucuji fcgi a
> suexec.
>
> Dne 9.9.2011 15:35 "zzzemfira89" <zzzemfira89@gmail.com> napsal(a):
>> Ahoj.
>>
>> Ja som skratka nainstaloval cely ispconfig3 a len klikam :-).
>>
>> Ale bezi to tusim ako su_php modul pre apache2. Tiez mam prefork.
>> Takze mam "klientov", konkretne unixove groups a kazdy z nich ma weby,
>> co su users.
>>
>> PHP potom bezi s pravami user:group pre prislusny skript. Co je
>> ziadany efekt :-) .
>> Z /var/log/suphp/suphp.log :
>> [info] Executing "/var/www/clients/client4/web6/web/index.php" as UID
>> 5009, GID 5010
>>
>> Jedneho casu som mal aj mod_php, ale tam som mal problem nastavit
>> tieto opravnenia pre php. Podobne ani fast-cgi som nedokopal k tomuto.
>>
>> Matej Snoha
>>
>> 2011/9/9 Jan Drábek <me@jandrabek.cz>:
>>> Také jsem chvílí použival google apps, ale vzhledem k drsným podmínkám,
>>> které vlastně říkají, že se vším co projde přes google si můžou dělat co
>>> chce...
>>> To mi přijde takového Kafkovské (to do jaké míry drží google kontrolu nad
>>> jednotlivými identitami... viz Proces).
>>>
>>> Uptime a load:
>>> 12:29:39 up 16 days,  3:55,  1 user,  load average: 0.02, 0.01, 0.00
>>>
>>> Apache mi používá apache2-mpm-prefork s tímto nastavením (nicméně ani 10x
>>> parametrů neukázalo výkonový rozdíl.
>>>
>>> <IfModule mpm_prefork_module>
>>>     StartServers          5
>>>     MinSpareServers       5
>>>     MaxSpareServers      10
>>>     MaxClients          150
>>>     MaxRequestsPerChild   0
>>> </IfModule>
>>>
>>> PHP akcelerátor nepoužívám.
>>>
>>> Suhoshin - Ano používám.
>>>
>>> V lodzích mám jen samé nezajímavé věci:
>>>
>>> Hlášení o nepovolených zvýšeních memory limitu
>>> Hlášení o nutnosti nastavit timezone (mám v php.ini?!)
>>>
>>> Používám PHP verze 5.3.8-1~dotdeb.2. Nicméně používám CGIčkové PHP což
>>> tuším
>>> bude asi hlavní zdroj problémů.
>>>
>>> Je to problém více aplikací (namátkou jsme zrovna dneska zkoušel i atMail
>>> a
>>> trpěl stejným problémem).
>>>
>>> Jak řešíte oddělení domén (účtů) vy? (Tzn, aby si PHP nemohlo číst celý
>>> adresářový strom, aby jste mohli mít různé php konfigurace pro různé
>>> domény
>>> atd...)
>>>
>>> Dík
>>>
>>> On Fri, 9 Sep 2011 12:01:46 +0200, zzzemfira89 wrote:
>>>
>>> Ahoj.
>>>
>>> No ja osobne mam google apps, takze tak :-) .
>>> Ale problem dakde bude. Mne ajaxove veci bezia rozumne (zlomok sekundy).
>>>
>>> Napis, co mas vlastne za konfiguraciu web servera. (# apache2ctl status |
>>> head)
>>> Keepalive zapnute a rozumne vysoke? Pocty procesov/threadov v
>>> apache.conf? Nie ze chudak Apache musi forknut novy proces pre kazdy
>>> novy ajax request a potom ho zabit.
>>>
>>> Pouzivas Suhoshin? Ked tak, on ma vlastny log (/var/log/user.log).
>>> Samozrejme pozri aj do apachovych logov, ci su nejake chyby v php a
>>> podobne.
>>> Pouzivas aj nejaky PHP accelerator (APC napr.,)? Ze by bol nejako
>>> divne nastaveny.
>>>
>>> A daj vediet aj load average, ked ten webmail budes trapit zo 5 minut.
>>> Ci sa tam fakt nieco narocne robi, alebo len vyvojari zabudli nejaky
>>> sleep() v kode :-).
>>>
>>> Matej Snoha
>>>
>>> PS: Sice off-topic, ale uz od rana ma DOSuju daki amici z DSLka. Co
>>> uz, pakety im zahadzuje fail2ban, ale ze nemaju nic lepsie na praci.
>>>
>>> 2011/9/9 Jan Drábek <me@jandrabek.cz>:
>>>
>>> Zdravím, netuším zda jsem si toho všiml až poslední dobou nebo se to
>>> vyskytovalo už dřív, ale zdá se mi, že AJAxové požadavky na Apache/PHP
>>> jsou
>>> dost pomalé. Nejvíc je problém vidět třeba v RoundCube, kde načtení
>>> seznamu
>>> zpráv, určité zprávy, přesun atd... trvá až desítku sekund. Potřeboval
>>> bych
>>> nakopnutí jak takový problém uchopit, kde můžou mít zakopaní psi atd.
>>> Díky
>>> Jan D. P.S. Neznáte nějaký webmail ve kterém vypadají konverzace stejně
>>> jako
>>> v Gmailu? _______________________________________________ Community-list
>>> mailing list Community-list@lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list
>> _______________________________________________
>> Community-list mailing list
>> Community-list@lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list
>


------------------------------

Message: 4
Date: Fri, 9 Sep 2011 16:18:36 +0200
From: Ladislav Blažek <lada@blazcata.cz>
To: zzzemfira89 <zzzemfira89@gmail.com>
Cc: community-list@lists.vpsfree.cz
Subject: Re: [vpsFree.cz: community-list] PHP - pomalé vyřízení
       Ajaxových odpovědí
Message-ID:
       <CANkn7RfEPsxYSoORWEpsqWmCM6o6Wh0sJue=Ar=z0uz-CWxPVQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Prosel jsem cestou mod_php -> suphp -> mod_fcgi + suexec. Na suphp prave
kvuli bezpecnosti - mass virtual hosting. Na serveru s cca 50 weby byla
rezie suphp reseni znat. Fcgi se suexec umoznuje stejne zabezpeceni jako
suphp.
Dne 9.9.2011 15:47 "zzzemfira89" <zzzemfira89@gmail.com> napsal(a):
> A mas realne taky web ze to aj citit? Pre mna par milisekund hore-dole
> nezavazi. Co som robil par php benchmarkov, fcgi mi na VPS bezalo
> podobne rychlo. Ale zas tak do hlbky som to neskumal.
>
> Ale tak jasne, fast cgi bude asi najrychlejim riesenim. Len ja z
> hladiska bezpecnosti preferujem SuPHP, mam s tym dobre skusenosti.
>
> Matej Snoha
>
> 2011/9/9 Ladislav Blažek <lada@blazcata.cz>:
>> SuPHP je asi ten nejpomalejsi zpusob jak provozovat PHP. Doporucuji fcgi
a
>> suexec.
>>
>> Dne 9.9.2011 15:35 "zzzemfira89" <zzzemfira89@gmail.com> napsal(a):
>>> Ahoj.
>>>
>>> Ja som skratka nainstaloval cely ispconfig3 a len klikam :-).
>>>
>>> Ale bezi to tusim ako su_php modul pre apache2. Tiez mam prefork.
>>> Takze mam "klientov", konkretne unixove groups a kazdy z nich ma weby,
>>> co su users.
>>>
>>> PHP potom bezi s pravami user:group pre prislusny skript. Co je
>>> ziadany efekt :-) .
>>> Z /var/log/suphp/suphp.log :
>>> [info] Executing "/var/www/clients/client4/web6/web/index.php" as UID
>>> 5009, GID 5010
>>>
>>> Jedneho casu som mal aj mod_php, ale tam som mal problem nastavit
>>> tieto opravnenia pre php. Podobne ani fast-cgi som nedokopal k tomuto.
>>>
>>> Matej Snoha
>>>
>>> 2011/9/9 Jan Drábek <me@jandrabek.cz>:
>>>> Také jsem chvílí použival google apps, ale vzhledem k drsným podmínkám,
>>>> které vlastně říkají, že se vším co projde přes google si můžou dělat
co
>>>> chce...
>>>> To mi přijde takového Kafkovské (to do jaké míry drží google kontrolu
nad
>>>> jednotlivými identitami... viz Proces).
>>>>
>>>> Uptime a load:
>>>> 12:29:39 up 16 days,  3:55,  1 user,  load average: 0.02, 0.01, 0.00
>>>>
>>>> Apache mi používá apache2-mpm-prefork s tímto nastavením (nicméně ani
10x
>>>> parametrů neukázalo výkonový rozdíl.
>>>>
>>>> <IfModule mpm_prefork_module>
>>>>     StartServers          5
>>>>     MinSpareServers       5
>>>>     MaxSpareServers      10
>>>>     MaxClients          150
>>>>     MaxRequestsPerChild   0
>>>> </IfModule>
>>>>
>>>> PHP akcelerátor nepoužívám.
>>>>
>>>> Suhoshin - Ano používám.
>>>>
>>>> V lodzích mám jen samé nezajímavé věci:
>>>>
>>>> Hlášení o nepovolených zvýšeních memory limitu
>>>> Hlášení o nutnosti nastavit timezone (mám v php.ini?!)
>>>>
>>>> Používám PHP verze 5.3.8-1~dotdeb.2. Nicméně používám CGIčkové PHP což
>>>> tuším
>>>> bude asi hlavní zdroj problémů.
>>>>
>>>> Je to problém více aplikací (namátkou jsme zrovna dneska zkoušel i
atMail
>>>> a
>>>> trpěl stejným problémem).
>>>>
>>>> Jak řešíte oddělení domén (účtů) vy? (Tzn, aby si PHP nemohlo číst celý
>>>> adresářový strom, aby jste mohli mít různé php konfigurace pro různé
>>>> domény
>>>> atd...)
>>>>
>>>> Dík
>>>>
>>>> On Fri, 9 Sep 2011 12:01:46 +0200, zzzemfira89 wrote:
>>>>
>>>> Ahoj.
>>>>
>>>> No ja osobne mam google apps, takze tak :-) .
>>>> Ale problem dakde bude. Mne ajaxove veci bezia rozumne (zlomok
sekundy).
>>>>
>>>> Napis, co mas vlastne za konfiguraciu web servera. (# apache2ctl status
|
>>>> head)
>>>> Keepalive zapnute a rozumne vysoke? Pocty procesov/threadov v
>>>> apache.conf? Nie ze chudak Apache musi forknut novy proces pre kazdy
>>>> novy ajax request a potom ho zabit.
>>>>
>>>> Pouzivas Suhoshin? Ked tak, on ma vlastny log (/var/log/user.log).
>>>> Samozrejme pozri aj do apachovych logov, ci su nejake chyby v php a
>>>> podobne.
>>>> Pouzivas aj nejaky PHP accelerator (APC napr.,)? Ze by bol nejako
>>>> divne nastaveny.
>>>>
>>>> A daj vediet aj load average, ked ten webmail budes trapit zo 5 minut.
>>>> Ci sa tam fakt nieco narocne robi, alebo len vyvojari zabudli nejaky
>>>> sleep() v kode :-).
>>>>
>>>> Matej Snoha
>>>>
>>>> PS: Sice off-topic, ale uz od rana ma DOSuju daki amici z DSLka. Co
>>>> uz, pakety im zahadzuje fail2ban, ale ze nemaju nic lepsie na praci.
>>>>
>>>> 2011/9/9 Jan Drábek <me@jandrabek.cz>:
>>>>
>>>> Zdravím, netuším zda jsem si toho všiml až poslední dobou nebo se to
>>>> vyskytovalo už dřív, ale zdá se mi, že AJAxové požadavky na Apache/PHP
>>>> jsou
>>>> dost pomalé. Nejvíc je problém vidět třeba v RoundCube, kde načtení
>>>> seznamu
>>>> zpráv, určité zprávy, přesun atd... trvá až desítku sekund. Potřeboval
>>>> bych
>>>> nakopnutí jak takový problém uchopit, kde můžou mít zakopaní psi atd.
>>>> Díky
>>>> Jan D. P.S. Neznáte nějaký webmail ve kterém vypadají konverzace stejně
>>>> jako
>>>> v Gmailu? _______________________________________________
Community-list
>>>> mailing list Community-list@lists.vpsfree.cz
>>>> http://lists.vpsfree.cz/listinfo/community-list
>>> _______________________________________________
>>> Community-list mailing list
>>> Community-list@lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20110909/3510ae23/attachment.html>

------------------------------

_______________________________________________
Community-list mailing list
Community-list@lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list


End of Community-list Digest, Vol 2, Issue 13
*********************************************