c/c++ shared modules as plugins

M

Marcus

Well-Known Member
#1
#1
Hi,

Have you thought about allowing people to develop their own c/c++ shared modules that they could plug-in to your server? You could create an appropriate API for creating shared modules, perhaps by creating a set of standard c/c++ structures that programmers program to and include some header files provided by you.

Shared modules could be run by using external app/context settings, or perhaps there could be a new s. This would allow much faster processing of optimized code, whilst not compromising your closed-source code. Also, it would remove the advantage that open-source web servers have over LSWS wrt development of highly-optimized code in shared-modules.

Just and idea, but I think it would be popular, and knowing your track record for creating excellent code, I'm sure it would be done well.
 
M

mistwang

LiteSpeed Staff
#2
#2
We may implement something like ISAPI or NSAPI as the internal API. Only need one, will investigate which one is better.
Right now, we have LSAPI similar to FastCGI as external application API. We can even implement something like LSAPI-ISAPI bridge to load ISAPI app into a external process, so the server reliability wont be affect by the third party application, once the application is stable, can load it to the web server internal for maximum performance.

What do you think?
 
M

Marcus

Well-Known Member
#3
#3
Having an isolated sandbox sounds like a good idea. You could possibly include some sort of reporting functions/tools that could give feedback on mem usage / execution time etc - for debugging purposes. Not sure if that would be easy to include or not, though.

You might want to also look at tntnet (tntnet.org) - this creates a nice structure for embedding C++ code in pages that use tags like <$ ...> and <% ... >. It generalizes some coding for easier web development.
 
M

mistwang

LiteSpeed Staff
#4
#4
Thanks for the tip on tntnet.org, do you have any experience with it? easy to work with fastCGI? A toolkit written in C is preferred, it could be a headache when user try to load the module into web server due to stdc++ library conflicts, out of process should not be a problem.

If put a application in its own process, it is very easy to get information like memory usage and execution time. At API level, execution time can be tracked easily, memory usage will be hard to track.
 
M

Marcus

Well-Known Member
#5
#5
I've done a little benchmarking for tntnet, and it's better than PHP with lsapi (that's without using Litespeed at all). On the system I'm using, some calls doing a few things that generate code from an imported file and with changing / printing various variables (generating a few KB of data) typically serve at a rate of about 35-55% of the rate that Litespeed serves a 14KB static file, and about 25-35% of a static file of around 3KB.

I've not tried FastCGI with it - just the webserver on its own - but I think it's possible (I've seen CGI-labeled files in the source).

Personally, I'm not totally happy with this rate - I think it could be much better. I think part of the reason is the webserver layer that they use, partly the linking mechanism for compiled code, partly the code that's generated and partly because it's C++ and not C. I think that improvements of 50% or more might be possible by doing a tight C-based toolkit.

Partly because of a project I'm working on that will potentially have high load with a high number of requests which will have to be dynamic, and partly for interest, I'm probably going to develop a module for NginX that will be able to dynamically link in compiled C code, which will be able to be included directly or generated from a new high-level programming language I've designed.

I've chosen NginX because my experience of it is very good - generally not far behind Litespeed (that's without any tweaking on my part), and because of it's flexible licensing. I'll be designing the framework in such a way that it should be fairly portable to other web-servers, though, with a fairly slim API. The aim of this framework would be to make it an enterprise-class, super-high-performance development framework not just for NginX, but for any server. I'm not sure about the licensing I'll use yet.

I won't be writing this until 2009, since I have other projects to complete before then, however if you might be interested, I can let you know about it when I've made some inroads into the development process.
 
Last edited:
M

mistwang

LiteSpeed Staff
#6
#6
Maybe you can try our SSI implementation in 4.0 beta, see how it holds up, it should be very close to the performance of a internal API.

Along with the cache module, it could deliver the highest performance for well designed web application.

We are trying to push the 4.0b3 out today.
 
M

Marcus

Well-Known Member
#8
#8
I'll check it out - though it still wouldn't have the same kind of functionality to it that I'd want (unless you're allowing for the inclusion of C code in your SSI implementation, which I doubt). :)
 
M

Marcus

Well-Known Member
#10
#10
Is your SSI implementation a read-once implementation (i.e. it only reads an SSI page once if the file hasn't changed), storing a cached version in memory, so that the SSI code doesn't need to be read on each request?
 
M

Marcus

Well-Known Member
#12
#12
Is SSI going to be available in the standard version of LSWS or just the Enterprise version?

Can you list which SSI features are currently available please (e.g. include virtual="...", set var="...")? Thanks.

Also, what variables are automatically available in SSI - i.e. ones that can be used in <!--# echo ...> declarations? (e.g. request_uri, server_ip...).
 
Last edited:
M

mistwang

LiteSpeed Staff
#13
#13
SSI is available in standard edition. Cache is Enterprise 2-CPU and above.
Our SSI implementation should be up to the spec of Apache mod_ssi.
 
M

Marcus

Well-Known Member
#16
#16
We may implement something like ISAPI or NSAPI as the internal API. Only need one, will investigate which one is better.
Right now, we have LSAPI similar to FastCGI as external application API. We can even implement something like LSAPI-ISAPI bridge to load ISAPI app into a external process, so the server reliability wont be affect by the third party application, once the application is stable, can load it to the web server internal for maximum performance.
Click to expand...
Any idea of timeframe for implementing an ISAPI or LSAPI-ISAPI bridge? I think it could be a really useful feature, especially for the larger websites.
 
You must log in or register to reply here.
Top