Menu
▾
▴
naviserver-devel — Developer discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(53) |
Mar
(62) |
Apr
(88) |
May
(55) |
Jun
(204) |
Jul
(52) |
Aug
|
Sep
(1) |
Oct
(94) |
Nov
(15) |
Dec
(68) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(130) |
Feb
(105) |
Mar
(34) |
Apr
(61) |
May
(41) |
Jun
(92) |
Jul
(176) |
Aug
(102) |
Sep
(247) |
Oct
(69) |
Nov
(32) |
Dec
(140) |
| 2007 |
Jan
(58) |
Feb
(51) |
Mar
(11) |
Apr
(20) |
May
(34) |
Jun
(37) |
Jul
(18) |
Aug
(60) |
Sep
(41) |
Oct
(105) |
Nov
(19) |
Dec
(14) |
| 2008 |
Jan
(3) |
Feb
|
Mar
(7) |
Apr
(5) |
May
(123) |
Jun
(5) |
Jul
(1) |
Aug
(29) |
Sep
(15) |
Oct
(21) |
Nov
(51) |
Dec
(3) |
| 2009 |
Jan
|
Feb
(36) |
Mar
(29) |
Apr
|
May
|
Jun
(7) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(13) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(9) |
Apr
(11) |
May
(16) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(92) |
Nov
(28) |
Dec
(16) |
| 2013 |
Jan
(9) |
Feb
(2) |
Mar
|
Apr
(4) |
May
(4) |
Jun
(6) |
Jul
(14) |
Aug
(12) |
Sep
(4) |
Oct
(13) |
Nov
(1) |
Dec
(6) |
| 2014 |
Jan
(23) |
Feb
(19) |
Mar
(10) |
Apr
(14) |
May
(11) |
Jun
(6) |
Jul
(11) |
Aug
(15) |
Sep
(41) |
Oct
(95) |
Nov
(23) |
Dec
(11) |
| 2015 |
Jan
(3) |
Feb
(9) |
Mar
(19) |
Apr
(3) |
May
(1) |
Jun
(3) |
Jul
(11) |
Aug
(1) |
Sep
(15) |
Oct
(5) |
Nov
(2) |
Dec
|
| 2016 |
Jan
(7) |
Feb
(11) |
Mar
(8) |
Apr
(1) |
May
(3) |
Jun
(17) |
Jul
(12) |
Aug
(3) |
Sep
(5) |
Oct
(19) |
Nov
(12) |
Dec
(6) |
| 2017 |
Jan
(30) |
Feb
(23) |
Mar
(12) |
Apr
(32) |
May
(27) |
Jun
(7) |
Jul
(13) |
Aug
(16) |
Sep
(6) |
Oct
(11) |
Nov
|
Dec
(12) |
| 2018 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(7) |
May
(23) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(6) |
Oct
(6) |
Nov
(10) |
Dec
(3) |
| 2019 |
Jan
(26) |
Feb
(15) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(14) |
Jul
(10) |
Aug
(10) |
Sep
(4) |
Oct
(2) |
Nov
(20) |
Dec
(10) |
| 2020 |
Jan
(10) |
Feb
(14) |
Mar
(29) |
Apr
(11) |
May
(25) |
Jun
(21) |
Jul
(23) |
Aug
(12) |
Sep
(19) |
Oct
(6) |
Nov
(8) |
Dec
(12) |
| 2021 |
Jan
(29) |
Feb
(9) |
Mar
(8) |
Apr
(8) |
May
(2) |
Jun
(2) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(4) |
Nov
(12) |
Dec
(13) |
| 2022 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
(12) |
May
(15) |
Jun
(7) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(8) |
Dec
|
| 2023 |
Jan
(15) |
Feb
|
Mar
(23) |
Apr
(1) |
May
(2) |
Jun
(10) |
Jul
|
Aug
(22) |
Sep
(19) |
Oct
(2) |
Nov
(20) |
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
(16) |
Apr
(15) |
May
(6) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(18) |
Dec
(6) |
| 2025 |
Jan
(12) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
(5) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bernd E. <eid...@we...> - 2006-12-12 16:12:14
|
> I tried Zend Optimizer, still same speed, i guess there could PHP tricks
> to speed up things i am not aware of
Maybe putting PHP for loop into a function? :-)))
============================
<BODY>
Test list <?php print date; ?><P>
<UL>
<?php
function foo($n) {
for ($i = 0; $i < $n; ++$i) {
print $i;
}
}
foo(50);
?>
</UL>
</BODY>
|
|
From: Vlad S. <vl...@cr...> - 2006-12-12 15:45:59
|
I tried Zend Optimizer, still same speed, i guess there could PHP tricks to speed up things i am not aware of Bernd Eidenschink wrote: >> How do i install Zend optimizer? > > In order to download it, you have to create an account on their website. > > See http://www.zend.com/downloads > "Zend Optimizer" (right column). > > The latest should be ZendOptimizer-3.2.0 (For PHP 5.2.x). > There's an install script which you run as root. It asks you where to install > the software and where your PHP.ini is located. > Then, if you are running Apache or not. After that some lines are appended to > your PHP.ini. Works with Apache and NaviServer, you can verify it > when running > > <?php > phpinfo(); > ?> > > There's a logo "Zend Engine 2" and a line "Zend Optimizer 3.2.0...". > > That's it. > > Bernd. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Vlad S. <vl...@cr...> - 2006-12-12 15:45:12
|
Right, i got lost in the logic :-))) .tcl files needs to be improved but overall i am back on track with my old belief that NS is faster than apache/PHP :-))) Zoran Vasiljevic wrote: > On 12.12.2006, at 16:27, Vlad Seryakov wrote: > >> Not sure what is the problem? > > :-)) > > You said: NS/ADP slower than Apache/PHP > You tested test.adp2 with 6000 req/sec and said > its faster that Apache (even static files) > > So the assumption: NS/ADP slower than Apache PHP > does not stand anymore, as far as I can see. > therefore I asked: what IS the problem? IOW, we > do not have any speed problem. Rather usage pattern. > Right? > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-12-12 15:35:43
|
On 12.12.2006, at 16:27, Vlad Seryakov wrote: > Not sure what is the problem? :-)) You said: NS/ADP slower than Apache/PHP You tested test.adp2 with 6000 req/sec and said its faster that Apache (even static files) So the assumption: NS/ADP slower than Apache PHP does not stand anymore, as far as I can see. therefore I asked: what IS the problem? IOW, we do not have any speed problem. Rather usage pattern. Right? |
|
From: Vlad S. <vl...@cr...> - 2006-12-12 15:30:56
|
Not sure what is the problem? Zoran Vasiljevic wrote: > On 12.12.2006, at 16:18, Vlad Seryakov wrote: > >> Yes, i called it test2.adp. It runs as fast as apache serves static >> files, ok, i just reran tests, it runs FASTER than apache serves >> test.html file. i used > > Well, what IS the problem then??? > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Vlad S. <vl...@cr...> - 2006-12-12 15:26:49
|
Right, but current implementation of file.tcl does cache compile the whole .tcl file into proc and still runs on my machine at 1550 req/sec while compiled .adp page at 6000 req/sec. not sure why, may be because file.tcl is pure Tcl and ADP is in C. Andrew Piskorski wrote: > On Tue, Dec 12, 2006 at 10:03:09AM -0500, Vlad Seryakov wrote: >>>> Von: Gustaf Neumann <ne...@wu...> >>>> what happens, if you try byte-compiled code, e.g.: > >> This runs at rate around 6000 req/sec, blows away Tcl .files and PHP, >> same speed as Apache static files > > Interesting! And so that suggests that a newer version of the old Tcl > page bytecode cacheing feature listed below (perhaps integrated with > the ADP stuff as Stephen Deasey has discussed in the past), would > still be quite valuable? > > http://sourceforge.net/tracker/?func=detail&aid=689515&group_id=3152&atid=353152 > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-12-12 15:26:20
|
On 12.12.2006, at 16:18, Vlad Seryakov wrote: > Yes, i called it test2.adp. It runs as fast as apache serves static > files, ok, i just reran tests, it runs FASTER than apache serves > test.html file. i used Well, what IS the problem then??? |
|
From: Vlad S. <vl...@cr...> - 2006-12-12 15:21:45
|
Yes, i called it test2.adp. It runs as fast as apache serves static files, ok, i just reran tests, it runs FASTER than apache serves test.html file. i used ab -c 50 -n 5000 http://localhost:8080/test/test.html ab -c 50 -n 5000 http://localhost/test/test2.adp for all my tests, run each at least 5-10 times, on the same machine. I have no swapping, plenty of available memory. Zoran Vasiljevic wrote: > On 12.12.2006, at 16:03, Vlad Seryakov wrote: > >> This runs at rate around 6000 req/sec, blows away Tcl .files and PHP, >> same speed as Apache static files > > You mean, the test.adp with pre-cached proc works that fast? > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Vlad S. <vl...@cr...> - 2006-12-12 15:19:05
|
yes, i played with all those settings, not significant, i start with 10 threads, then i tried with 30 threads, usually first run is slow but after that it runs at full speed. I checked nsstats.conf for lock contention and even tried to disable some for testing purposes, no big difference, i would say not difference at all. The only thing which slowed down a little bit are filter, i have framework that installed several filters for security and templating, this took about 50 req/sec once activated. Bernd Eidenschink wrote: > Does "ab" use keepalive (guess not...)? > NaviServer should start with all 10 threads from the beginning (at least with > the same number your Apache does pre-fork). > Turn all kind of stats off that may be on by default. > > ========================================================== > > ns_section ns/server/$server > ns_param connsperthread 0 > ns_param minthreads 10 > ns_param maxthreads 100 > > # Max connections to put on queue (100) > ns_param maxconnections 100 > > # Max connections to put on queue (100) > ns_param maxconnections 100 > > # Number of pending connections > # There is a system wide limit and a limit per application. > # The system wide can be displayed on Linux with: > # sysctl -a| grep max_syn_backlog > # The settings can be changed (e.g. to 1024): > # Solaris: /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 1024 > # Linux: /sbin/sysctl -w net.ipv4.tcp_max_syn_backlog=1024 > ns_param listenbacklog 32 > > ns_param keepalivetimeout 30 > ns_param maxkeepalive 100 > > ns_param globalstats false > ns_param urlstats false > > ns_section ns/server/stats > ns_param enabled 0 > > ns_section ns/threads > ns_param mutexmeter false > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Bernd E. <eid...@we...> - 2006-12-12 15:18:57
|
> How do i install Zend optimizer? In order to download it, you have to create an account on their website. See http://www.zend.com/downloads "Zend Optimizer" (right column). The latest should be ZendOptimizer-3.2.0 (For PHP 5.2.x). There's an install script which you run as root. It asks you where to install the software and where your PHP.ini is located. Then, if you are running Apache or not. After that some lines are appended to your PHP.ini. Works with Apache and NaviServer, you can verify it when running <?php phpinfo(); ?> There's a logo "Zend Engine 2" and a line "Zend Optimizer 3.2.0...". That's it. Bernd. |
|
From: Vlad S. <vl...@cr...> - 2006-12-12 15:15:47
|
Yes, i tried setting it to 1024 with maxqueuesize 1024 and it does not make noticeable difference, with 10 and 1024 it runs at the same rate. I guess it will depend on the application, this knob can be useful tuning thing and it is not universal Stephen Deasey wrote: > On 12/12/06, Vlad Seryakov <vl...@cr...> wrote: >> but only when acceptsize is >> greater than 1, i tested with 5, results are exactly as php, around >> 1540-1560 req/sec, when i set acceptsize to 10, i constantly got results >> 1600-1610. > > Did you try it such that it would accept all pending connections, up > to the limit of available sock structures? Does this help, hurt? > > If it doesn't hurt, it would be nice to get rid of yet another tuning knob. > > > Take a look at man tcp(7) and search for TCP_DEFER_ACCEPT. With this > option, poll() will not wake up when a new connection arrives, but > only when some bytes have also arrived on that connection, so that > once we accept() we can also read() straight away. One less trip > through the poll loop for each new connection. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Andrew P. <at...@pi...> - 2006-12-12 15:13:53
|
On Tue, Dec 12, 2006 at 10:03:09AM -0500, Vlad Seryakov wrote: > >> Von: Gustaf Neumann <ne...@wu...> > >> what happens, if you try byte-compiled code, e.g.: > This runs at rate around 6000 req/sec, blows away Tcl .files and PHP, > same speed as Apache static files Interesting! And so that suggests that a newer version of the old Tcl page bytecode cacheing feature listed below (perhaps integrated with the ADP stuff as Stephen Deasey has discussed in the past), would still be quite valuable? http://sourceforge.net/tracker/?func=detail&aid=689515&group_id=3152&atid=353152 -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Zoran V. <zv...@ar...> - 2006-12-12 15:13:16
|
On 12.12.2006, at 16:03, Vlad Seryakov wrote: > This runs at rate around 6000 req/sec, blows away Tcl .files and PHP, > same speed as Apache static files You mean, the test.adp with pre-cached proc works that fast? |
|
From: Vlad S. <vl...@cr...> - 2006-12-12 15:06:40
|
This runs at rate around 6000 req/sec, blows away Tcl .files and PHP,
same speed as Apache static files
Zoran Vasiljevic wrote:
> On the behalf of Gustaf, as his email didn't
> reach the list (for some obscure reason):
>
> Begin forwarded message:
>
>> -------- Original-Nachricht --------
>> Betreff: Re: [naviserver-devel] Benchmarks
>> Datum: Mon, 11 Dec 2006 19:12:33 +0100
>> Von: Gustaf Neumann <ne...@wu...>
>> An: nav...@li...
>> Referenzen: <457...@cr...>
>>
>>
>>
>> what happens, if you try byte-compiled code, e.g.:
>>
>> test.adp
>> ------------------------------------
>>
>> <BODY>
>> Test list <%=[ns_fmttime [ns_time]]%>
>> <P>
>> <UL>
>>
>> <%
>> proc foo {n} { for { set i 0 } { $i < $n } { incr i }
>> { ns_adp_puts $i }}
>> foo 50
>> %>
>>
>> </UL>
>> </BODY>
>>
>>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Vlad S. <vl...@cr...> - 2006-12-12 15:00:48
|
How do i install Zend optimizer? Bernd Eidenschink wrote: >> Then i disabled .tcl caching, results are constantly around 1500 req/sec >> and i checked PHP source, it does compile file with every request, so >> PHP compiler is little bit faster than Tcl compiler. > > when you install the Zend Optimizer (with default optimization levels), how > much does that speed up your PHP example compared to the TCL with caching? > > Bernd. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Bernd E. <eid...@we...> - 2006-12-12 14:36:57
|
Does "ab" use keepalive (guess not...)? NaviServer should start with all 10 threads from the beginning (at least with the same number your Apache does pre-fork). Turn all kind of stats off that may be on by default. ========================================================== ns_section ns/server/$server ns_param connsperthread 0 ns_param minthreads 10 ns_param maxthreads 100 # Max connections to put on queue (100) ns_param maxconnections 100 # Max connections to put on queue (100) ns_param maxconnections 100 # Number of pending connections # There is a system wide limit and a limit per application. # The system wide can be displayed on Linux with: # sysctl -a| grep max_syn_backlog # The settings can be changed (e.g. to 1024): # Solaris: /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 1024 # Linux: /sbin/sysctl -w net.ipv4.tcp_max_syn_backlog=1024 ns_param listenbacklog 32 ns_param keepalivetimeout 30 ns_param maxkeepalive 100 ns_param globalstats false ns_param urlstats false ns_section ns/server/stats ns_param enabled 0 ns_section ns/threads ns_param mutexmeter false |
|
From: Stephen D. <sd...@gm...> - 2006-12-12 13:48:12
|
On 12/12/06, Vlad Seryakov <vl...@cr...> wrote: > > but only when acceptsize is > greater than 1, i tested with 5, results are exactly as php, around > 1540-1560 req/sec, when i set acceptsize to 10, i constantly got results > 1600-1610. Did you try it such that it would accept all pending connections, up to the limit of available sock structures? Does this help, hurt? If it doesn't hurt, it would be nice to get rid of yet another tuning knob. Take a look at man tcp(7) and search for TCP_DEFER_ACCEPT. With this option, poll() will not wake up when a new connection arrives, but only when some bytes have also arrived on that connection, so that once we accept() we can also read() straight away. One less trip through the poll loop for each new connection. |
|
From: Stephen D. <sd...@gm...> - 2006-12-12 13:17:10
|
On 12/12/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> On the behalf of Gustaf, as his email didn't
> reach the list (for some obscure reason):
>
> Begin forwarded message:
>
> > -------- Original-Nachricht --------
> > Betreff: Re: [naviserver-devel] Benchmarks
> > Datum: Mon, 11 Dec 2006 19:12:33 +0100
> > Von: Gustaf Neumann <ne...@wu...>
> > An: nav...@li...
> > Referenzen: <457...@cr...>
> >
> >
> >
> > what happens, if you try byte-compiled code, e.g.:
> >
> > test.adp
> > ------------------------------------
> >
> > <BODY>
> > Test list <%=[ns_fmttime [ns_time]]%>
> > <P>
> > <UL>
> >
> > <%
> > proc foo {n} { for { set i 0 } { $i < $n } { incr i }
> > { ns_adp_puts $i }}
> > foo 50
> > %>
> >
> > </UL>
> > </BODY>
ADP Tcl fragments should be byte compiled. The system goes out of it's
way to store the fragments in thread-local caches so that the Tcl
byte-code which is generated after the first call to 'eval' can be
reused for future requests.
Couple of things to keep in mind:
The Tcl compiler would often optimize proc bodys more aggressively
than bare code passed to eval. Would be good to try Tcl 8.5 here,
which after 5 years looks like it's almost done... :-)
The ADP being tested has two Tcl fragments, the .tcl file is compiled
to a single proc.
A nice optimisation would be to combine the Tcl fragments together
into a single blob/proc to run, which would append the result of each
fragment to the same output buffer, noting the start and end position.
ADP would then use vectored io to dump the string chunks interleaved
with the result buffer segments. The advantage here would be on more
realistic pages with large chunks of text, which now would not need to
be copied around, and in amortizing all the little buffer appends for
the Tcl results into a single buffer.
Another simple optimisation would be to not stat the .adp on disk for
each request. Not something we're doing worse than anyone else here,
although I'm sure they have the option to turn stat off, but would be
relatively easy to put e.g. a 5 sec delay on each stat (checked
against the connection start time to avoid an extra call to
gettimeofday).
Oh, and turn off atime updates for the directory containing your web
pages, and additionally turn off mtime updates for your log files.
Free and easy.
|
|
From: Zoran V. <zv...@ar...> - 2006-12-12 08:54:42
|
On the behalf of Gustaf, as his email didn't
reach the list (for some obscure reason):
Begin forwarded message:
> -------- Original-Nachricht --------
> Betreff: Re: [naviserver-devel] Benchmarks
> Datum: Mon, 11 Dec 2006 19:12:33 +0100
> Von: Gustaf Neumann <ne...@wu...>
> An: nav...@li...
> Referenzen: <457...@cr...>
>
>
>
> what happens, if you try byte-compiled code, e.g.:
>
> test.adp
> ------------------------------------
>
> <BODY>
> Test list <%=[ns_fmttime [ns_time]]%>
> <P>
> <UL>
>
> <%
> proc foo {n} { for { set i 0 } { $i < $n } { incr i }
> { ns_adp_puts $i }}
> foo 50
> %>
>
> </UL>
> </BODY>
>
>
|
|
From: Bernd E. <eid...@we...> - 2006-12-12 06:56:09
|
>Then i disabled .tcl caching, results are constantly around 1500 req/sec >and i checked PHP source, it does compile file with every request, so >PHP compiler is little bit faster than Tcl compiler. when you install the Zend Optimizer (with default optimization levels), how much does that speed up your PHP example compared to the TCL with caching? Bernd. |
|
From: Vlad S. <vl...@cr...> - 2006-12-12 06:22:06
|
Actually i was wrong, when using .tcl file and caching enabled it works
faster than apache/php, not significantly but only when acceptsize is
greater than 1, i tested with 5, results are exactly as php, around
1540-1560 req/sec, when i set acceptsize to 10, i constantly got results
1600-1610.
So, adp parser and caching is much slower than Tcl parser and caching,
at least twice slower.
Then i disabled .tcl caching, results are constantly around 1500 req/sec
and i checked PHP source, it does compile file with every request, so
PHP compiler is little bit faster than Tcl compiler.
set data "
<BODY>
Test list [clock format [clock seconds]]<P>
<UL>
"
for { set i 0 } { $i < 500 } { incr i } {
append data $i
}
ns_return 200 text.html "
</UL>
</BODY>
"
Zoran Vasiljevic wrote:
> On 11.12.2006, at 23:21, Vlad Seryakov wrote:
>
>> Getting to C language every time i need to do stuff is not an option
>
> Did yu try ns_return as Stephen suggested?
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Vlad S. <vl...@cr...> - 2006-12-11 22:34:33
|
yes, it is slower than from .adp page Zoran Vasiljevic wrote: > On 11.12.2006, at 23:21, Vlad Seryakov wrote: > >> Getting to C language every time i need to do stuff is not an option > > Did yu try ns_return as Stephen suggested? > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-12-11 22:32:21
|
On 11.12.2006, at 23:21, Vlad Seryakov wrote: > Getting to C language every time i need to do stuff is not an option Did yu try ns_return as Stephen suggested? |
|
From: Vlad S. <vl...@cr...> - 2006-12-11 22:25:28
|
No i am not moving to PHP, i am just trying to to justify the reason for some people why i am still using Naviserver/Tcl and do not want to switch to more "modern" or popular platforms like PHP, Java, Python or Ruby. If nothing else, the problem only arise when comparing speed, not overall system performance or ability to scale it, just pure speed and argument that if scripting language A can do this thing twice as fast as Tcl, that means roughly that Tcl will require more hardware and money to fulfill the same tasks and because both using same DB which means access to DB almost identical in speed, the language engine will be the slowest point. In case of hundreds and thousands requests at the same time, all those extra CPU cycles will build up and Tcl based system will process less requests than other and etc..... Until i ran benchmarks i somehow got answers on all problems, but Tcl speed somehow made me wonder. Also the language shootout page http://shootout.alioth.debian.org/ shows that Tcl is second from the end, Ruby is slower only from popular languages and it looks like there is a lot of hype around it and Ruby's VM will be improved. Getting to C language every time i need to do stuff is not an option, if i need to process several lists in the Tcl in memory, as it occurred it will be much slower than in PHP, if i got 100 records from DB, then another 100 from another DB, now i need to scan 2 lists and do something, not complex, it is just 2 different DBs, so i cannot join the tables in one SQL. Real world example is not a problem to find. I actually even tried to test PHP inside Naviserver, same file, it was much slower than under Apache and .adp. I specifically chose simple examples and no DB, i wanted to see how simple web pages are served. I always though that Apache/PHP is slower than Aolserver/Naviserver, looks like it is already history. Stephen Deasey wrote: > On 12/11/06, Vlad Seryakov <vl...@cr...> wrote: >> I can sqeeze something from C maybe, but Tcl is a bottleneck, making >> "for" loop bigger than over 200-500 iterations makes it crawl comparing >> to PHP, even with Tcl files cached, still it is 2-3 times slower. I am >> evaluating stuff for high performance web site and it looks like Tcl >> alone makes requirements for hardware tougher as oppose to PHP to be >> able reach same level of req/sec. Of course there is DB which make >> things much slower, but having same DB in both environments still if >> page requires some logic processing scripting language speed is important. > > > It would be interesting to see result of a registered proc: > > ns_return 200 text/plain 0123456789 > > and the equivalent in C, just to get a baseline. I mean, is it basic, > raw Tcl byte-code execution speed that sucks compared to PHP? It would > also be nice to see PHP with one of the byte-code caches. No reason > you wouldn't use one in production, right? > > > I created a db command: > > dbi_format {selct name, age from people where age > 18} {<li>%s: %d</li>} > > It's ~ 20% faster than running Tcl code in the loop to interpolate the > value and build up the result. It calls the underlying Tcl 'format' > implementation, which isn't quite flexible enough to use only a single > dstring, so at the moment it constructs a row then copies it into the > result. It could be better. > > This test was with a null driver -- the SQL query would actually be > something like {ROWS 2 2}, which means this is a command returning > rows, not DML, and give me 2 columns, 2 rows. Very low overhead. As I > recall, the biggest difference in execution times was the number of > rows returned. Plugging in a real Postgres driver increased execution > time, but not much. A query to Postgres for a couple of rows was > quicker than the null driver with ~ 50 rows constructed in Tcl. > > You could also imagine '-pre' and '-post' switches which you would use > to prepend '<ul>' and append '</ul>' to the above example, which would > save the extra malloc and copys. > > Further, you'd also want to specialise for ADP, appending straight to > the ADP output buffer rather than returning the result in the Tcl > interp, and then redundantly copying it into the buffer. > > > Anyway, I realise your looping example was just that, an example, but > one way to speed things up is to move them to C. OK, kinda obvious, > and in this case maybe feels a bit like cheating. What, I'm not > allowed to loop!? But it's not the biggest surprise in the world to > learn that people want to pull stuff from a data store and pump it out > as a web page. Probably 80% of what you do, in general, could be > covered by a half a dozen well tuned subsystems. > > I guess it depends what you're building. You say high-performance. Is > it also complex? Is the tricky bit going to be getting high > performance and/or scaling it, or do you have a mountain of code to > write? PHP seems like such a sideways move... :-/ > > It would be really cool if you could do a couple of runs with sysprof, > say one with a simple registered C proc, and one with the ADP loop > above, and post the data files. You know, if you're not busy... :-) > > > http://live.gnome.org/Sysprof > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Stephen D. <sd...@gm...> - 2006-12-11 22:00:41
|
On 12/11/06, Vlad Seryakov <vl...@cr...> wrote:
> I can sqeeze something from C maybe, but Tcl is a bottleneck, making
> "for" loop bigger than over 200-500 iterations makes it crawl comparing
> to PHP, even with Tcl files cached, still it is 2-3 times slower. I am
> evaluating stuff for high performance web site and it looks like Tcl
> alone makes requirements for hardware tougher as oppose to PHP to be
> able reach same level of req/sec. Of course there is DB which make
> things much slower, but having same DB in both environments still if
> page requires some logic processing scripting language speed is important.
It would be interesting to see result of a registered proc:
ns_return 200 text/plain 0123456789
and the equivalent in C, just to get a baseline. I mean, is it basic,
raw Tcl byte-code execution speed that sucks compared to PHP? It would
also be nice to see PHP with one of the byte-code caches. No reason
you wouldn't use one in production, right?
I created a db command:
dbi_format {selct name, age from people where age > 18} {<li>%s: %d</li>}
It's ~ 20% faster than running Tcl code in the loop to interpolate the
value and build up the result. It calls the underlying Tcl 'format'
implementation, which isn't quite flexible enough to use only a single
dstring, so at the moment it constructs a row then copies it into the
result. It could be better.
This test was with a null driver -- the SQL query would actually be
something like {ROWS 2 2}, which means this is a command returning
rows, not DML, and give me 2 columns, 2 rows. Very low overhead. As I
recall, the biggest difference in execution times was the number of
rows returned. Plugging in a real Postgres driver increased execution
time, but not much. A query to Postgres for a couple of rows was
quicker than the null driver with ~ 50 rows constructed in Tcl.
You could also imagine '-pre' and '-post' switches which you would use
to prepend '<ul>' and append '</ul>' to the above example, which would
save the extra malloc and copys.
Further, you'd also want to specialise for ADP, appending straight to
the ADP output buffer rather than returning the result in the Tcl
interp, and then redundantly copying it into the buffer.
Anyway, I realise your looping example was just that, an example, but
one way to speed things up is to move them to C. OK, kinda obvious,
and in this case maybe feels a bit like cheating. What, I'm not
allowed to loop!? But it's not the biggest surprise in the world to
learn that people want to pull stuff from a data store and pump it out
as a web page. Probably 80% of what you do, in general, could be
covered by a half a dozen well tuned subsystems.
I guess it depends what you're building. You say high-performance. Is
it also complex? Is the tricky bit going to be getting high
performance and/or scaling it, or do you have a mountain of code to
write? PHP seems like such a sideways move... :-/
It would be really cool if you could do a couple of runs with sysprof,
say one with a simple registered C proc, and one with the ADP loop
above, and post the data files. You know, if you're not busy... :-)
http://live.gnome.org/Sysprof
|
14 messages has been excluded from this view by a project administrator.
