On Thu, Mar 20, 2003 at 07:28:53PM +0100, Magnus Manske wrote:
Lee Daniel Crocker wrote:
>>(Magnus Manske <magnus.manske(a)web.de>)e>):
>>1. Enhanced parser, probably in C++ (working on it)
>
>
>Waste of time. Parsing is clearly not a significant factor in
>the present CPU load, and even one written in C would spend most
>of its time looking up links in the database just as the PHP
>code does. And the overhead of linking the two would wipe out
>any savings.
I tentatively agree, the parsing of the data itself is not a bottleneck.
Something like the Zend Optimizer or PHPA (as suggested on meta) could
certainly be worth a shot, especially since they are free.
Most of the parser is already running in my offline
reader, and could be
adapted for "real" output. I'd like (some day) to write a "Phase
IV" in
C++, if I can figure out a nice way to link it with the web server
(e.g., how to read <form> content). Is there a tutorial or something on
the web?
This is generally done on a web server by web server basis.
You can read about:
Apache API (
http://httpd.apache.org/docs/misc/API.html)
ISAPI (
http://www.microsoft.com/iis)
NSAPI (
http://www.le-berre.com/nsapi/nsapi.htm)
Enjoy...
Caching known
links in groups is indeed someting I will try, but
in their own table to reduce lock contention.
OTOH, we're reading the article data from the database anyway;
transmitting another field with it won't do much harm, I think.
Another thing I want
to look into is caching link lookups in a separate process outside
the page rendering, so the cache can be persistent across pages.
Sounds like trouble to me :-)